Bagikan melalui


Fork

Layanan Azure DevOps | Azure DevOps Server 2022 - Azure DevOps Server 2019

Visual Studio 2019 | Visual Studio 2022

Fork repositori Git berguna ketika orang ingin membuat perubahan eksperimental, berisiko, atau rahasia pada basis kode, tetapi perubahan tersebut perlu diisolasi dari basis kode dalam repositori asli. Fork baru pada dasarnya adalah klon repositori asli yang didorong ke repositori jarak jauh baru. Fork tidak bergantung pada repositori asli, dan merupakan salinan lengkap kecuali Anda menentukan satu cabang.

Sebagai salinan independen, perubahan yang Anda buat pada fork Anda, seperti menambahkan penerapan atau cabang, tidak dibagikan dengan repositori asli. Jika Anda ingin menggabungkan perubahan basis kode ke dalam repositori asli, Anda harus membuat permintaan pull (PR) untuk meminta peninjauan dan persetujuan perubahan tersebut.

Proses forking tidak mentransfer izin, kebijakan, atau alur build apa pun dari repositori asli ke fork Anda.

Artikel ini membahas bekerja dengan fork di repositori Azure Repos Git, dan menyediakan tautan ke konten GitHub yang membahas cara mengelola Fork di repositori GitHub.

Di artikel ini, Anda akan mempelajari cara:

  • Membagikan kode antar fork
  • Memilih antara cabang dan fork
  • Aktifkan fork repositori
  • Membuat fork
  • Mengkloning fork Anda secara lokal
  • Mendorong perubahan lokal ke fork Anda
  • Membuat dan menyelesaikan PR
  • Sinkronkan fork Anda

Prasyarat untuk akses ke Azure Repos

  • Repositori harus diaktifkan di pengaturan proyek Azure DevOps Anda. Jika hub Repos dan halaman terkait tidak ditampilkan, lihat Mengaktifkan atau menonaktifkan layanan Azure DevOps untuk mengaktifkan kembali Repositori.

  • Untuk melihat kode dalam proyek privat, Anda harus menjadi anggota proyek Azure DevOps dengan tingkat akses Dasar atau yang lebih tinggi. Untuk proyek publik, semua orang dapat melihat kode.

  • Untuk mengkloning atau berkontribusi pada kode untuk proyek privat, Anda harus menjadi anggota grup keamanan Kontributor atau memiliki izin yang sesuai yang ditetapkan. Untuk proyek publik, siapa pun dapat mengkloning dan menyumbang kode. Untuk mempelajari selengkapnya, lihat Apa itu proyek publik?

    Catatan

    Untuk proyek publik, pengguna yang diberikan akses Pemangku Kepentingan memiliki akses penuh ke Azure Repos.

  • Repositori harus diaktifkan di pengaturan proyek Azure DevOps Anda. Jika hub Repos dan halaman terkait tidak ditampilkan, lihat Mengaktifkan atau menonaktifkan layanan Azure DevOps untuk mengaktifkan kembali Repositori.

  • Untuk melihat kode, Anda harus menjadi anggota proyek Azure DevOps dengan akses Dasar atau yang lebih tinggi. Jika Anda bukan anggota proyek, tambahkan.

  • Untuk mengkloning atau berkontribusi pada kode, Anda harus menjadi anggota grup keamanan Kontributor , atau memiliki izin yang sesuai, dalam proyek yang ingin Anda ubah.

Membagikan kode antar fork

Repositori asli sering disebut sebagai repositori hulu . Anda dapat membuat PR untuk menggabungkan perubahan ke kedua arah: dari fork ke upstram, atau upstram ke fork. Arah yang paling umum adalah dari fork ke hulu. Izin, kebijakan, build, dan item kerja repositori tujuan akan berlaku untuk PR.

Memilih antara cabang dan fork

Untuk tim kecil yang terdiri dari 2-5 pengembang, alur kerja forking mungkin tidak diperlukan karena semua orang dapat bekerja di cabang fitur dan kebijakan cabang dapat melindungi cabang default. Namun, jika tim Anda memperluas dan melampaui pengaturan ini, mereka dapat beralih ke alur kerja forking.

Jika repositori Anda memiliki sejumlah besar komitter biasa atau jarang, seperti proyek sumber terbuka mungkin, kami merekomendasikan alur kerja forking. Biasanya, hanya kontributor inti untuk proyek Anda yang harus memiliki hak penerapan langsung ke repositori asli Anda. Kolaborator lain harus menggunakan alur kerja forking untuk mengisolasi perubahan yang diusulkan sampai kontributor inti memiliki kesempatan untuk meninjau pekerjaan mereka.

Aktifkan fork repositori

Untuk mengaktifkan fork untuk repositori Azure Repos Git, lihat mengaktifkan Forks.

Untuk mengaktifkan fork untuk repositori GitHub, lihat Mengelola kebijakan forking untuk organisasi Anda.

Alur kerja forking

Alur kerja forking terdiri dari lima langkah yang dijelaskan di bagian berikut.

  1. Membuat fork
  2. Mengkloning fork Anda secara lokal
  3. Mendorong perubahan lokal ke fork Anda
  4. Membuat dan menyelesaikan PR
  5. Sinkronkan fork Anda

Membuat fork

Langkah-langkah berikut menjelaskan cara membuat fork repositori Azure Repos Git.

Catatan

Untuk membuat fork repositori dalam proyek Azure DevOps, Anda harus memiliki izin Buat Repositori untuk proyek tersebut. Pemilik repositori harus mempertimbangkan untuk membuat proyek khusus untuk fork dan menetapkan izin Buat Repositori ke semua kontributor. Untuk informasi selengkapnya tentang mengatur izin, lihat Mengatur izin repositori Git.

  1. Dari browser web Anda, navigasikan ke repositori Azure Repos Git yang ingin Anda fork. Pilih Repositori > File lalu pilih Fork dari menu elipsis untuk membuka dialog Fork .

    Cuplikan layar item menu Fork di menu Tindakan lainnya di halaman File Repositori di Azure Repos.

  2. Dalam dialog Fork, beri nama repositori fork, pilih proyek tempat Anda ingin fork dibuat, pilih cabang yang akan disertakan dalam fork, lalu pilih Fork. Anda dapat menentukan apakah fork akan berisi semua cabang atau hanya cabang default. Jika repositori berisi beberapa cabang topik, maka pertimbangkan hanya menyertakan cabang default di fork Anda.

    Cuplikan layar dialog Fork di halaman File Repo di Azure Repos.

Untuk informasi tentang cara membuat fork repositori GitHub, lihat Fork repositori.

Mengkloning fork Anda secara lokal

Setelah Anda membuat fork repositori, kloning fork Anda untuk membuat salinan lokal di folder di komputer Anda. Anda dapat mengkloning dari baris perintah atau dengan menggunakan IDE seperti Visual Studio. Untuk informasi selengkapnya tentang mengkloning repositori, lihat Mengkloning repositori Git yang ada.

Saat Anda mengkloning repositori jarak jauh, Git menetapkan alias origin sebagai singkatan untuk URL repositori jarak jauh yang Anda kloning. Untuk kenyamanan, tambahkan alias lain bernama upstream untuk repositori yang Anda fork, yang disebut sebagai repositori upstream. Langkah-langkah berikut menjelaskan cara menambahkan upstream alias.

Tip

Untuk kenyamanan, Anda dapat menggunakan origin alias dan upstream alih-alih URL yang sesuai dalam perintah Git Anda.

Untuk menambahkan upstream alias di Visual Studio, ikuti langkah-langkah berikut:

  1. Pilih Opsi Alat > dari bilah menu untuk membuka jendela Opsi. Pilih Repositori Git Kontrol > Sumber Pengaturan > Jarak Jauh, lalu pilih Tambahkan untuk membuka dialog Tambahkan Jarak Jauh.

    Cuplikan layar tombol Tambahkan di panel Jarak Jauh dari submenu Repositori Git Pengaturan menu Kontrol Sumber di Visual Studio 2019.

  2. Dalam dialog Tambahkan Jarak Jauh, tambahkan remote baru yang disebut upstream dan masukkan URL klon Git dari repositori yang Anda fork. Lalu, pilih Simpan.

    Cuplikan layar kotak dialog Tambahkan Jarak Jauh di Visual Studio 2019.

Mendorong perubahan lokal ke fork Anda

Saat anda fork, Anda membuat salinan pribadi dan independen dari repositori jarak jauh. Jadi, tidak ada yang mencegah Anda bekerja langsung di main cabang klon lokal dan kemudian mendorong pekerjaan itu ke main cabang fork Anda. Namun, umumnya lebih baik menggunakan cabang fitur untuk pekerjaan Anda. Dengan menggunakan cabang fitur:

  • Anda dapat mempertahankan beberapa aliran kerja independen secara bersamaan.

  • Anda mempermudah orang lain untuk memahami pekerjaan yang Anda bagikan karena pekerjaan tersebut diatur ke dalam alur kerja yang berbeda menurut cabang.

Alur kerja Git yang khas mencakup langkah-langkah berikut:

  1. Buat fitur lokal atau cabang perbaikan bug.

  2. Buat perubahan di cabang baru dan terapkan pekerjaan Anda. Biasanya, orang membuat beberapa penerapan saat mengerjakan fitur atau perbaikan bug.

  3. Dorong fitur atau cabang perbaikan bug ke fork Anda. Fork Anda memiliki alias origin.

Untuk informasi tentang cara mendorong perubahan Anda, lihat Berbagi kode dengan pendorongan.

Membuat dan menyelesaikan PR

Di Azure Repos, untuk menggabungkan ke dalam repositori asli, perubahan yang Anda dorong ke fork, Anda dapat:

  1. Buat PR untuk meminta peninjauan dan persetujuan perubahan Anda. Saat Anda membuka PR, atur cabang sumber PR ke fitur atau cabang bugfix di fork Anda. Cabang target PR biasanya main merupakan cabang repositori yang Anda fork. Repositori itu disebut sebagai repositori hulu dan memiliki alias upstream.

    Cuplikan layar berikut menunjukkan repositori sumber dan cabang serta repositori target dan cabang PR yang dibuat di Azure Repos.

    Cuplikan layar opsi sumber PR dan cabang target di Azure Repos.

    Untuk informasi selengkapnya tentang cara membuat PR menggunakan browser, Visual Studio, atau Azure DevOps CLI, lihat Membuat PR.

    Penting

    Siapa pun dengan izin Baca pada repositori upstram dapat membuka PR untuk itu. Jika repo upstream memiliki alur build PR yang dikonfigurasi untuk berjalan pada pembuatan PR, build akan berjalan pada perubahan yang diperkenalkan oleh PR Anda.

  2. Agar PR Anda selesai, semua peninjau yang diperlukan harus menyetujui perubahan PR dan semua kebijakan cabang target harus dipenuhi. Pada persetujuan dan penyelesaian PR, perubahan di cabang sumber PR akan bergabung ke cabang target PR.

Untuk informasi tentang cara membuat dan menyelesaikan PR GitHub, lihat Membuat permintaan pull dan Menggabungkan permintaan pull.

Sinkronkan fork Anda

Setelah PR menggabungkan perubahan dari fork Anda ke cabang target repositori upstream, Anda dapat menarik dari cabang target repositori upstream untuk memperbarui cabang lokal yang sesuai dengan perubahan Anda dan perubahan apa pun yang dibuat oleh kontributor lain. Kemudian Anda siap untuk:

  • Buat fitur baru atau cabang perbaikan bug dari cabang lokal yang diperbarui.

  • Perbarui fork Anda dengan mendorong dari cabang lokal Anda yang diperbarui ke origin.

Biasanya, cabang target repositori hulu adalah main. Jika Anda tidak langsung mengedit cabang lokal main Anda (Anda bekerja di cabang fitur), maka menarik dari cabang upstream/main hulu akan memperbarui cabang lokal main Anda tanpa konflik penggabungan.

Langkah berikutnya