Mengubah cabang default

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

Cabang default adalah cabang pertama yang akan diperiksa Git pada kloning baru. Selain itu, permintaan pull menargetkan cabang ini secara default.

Kita akan menelusuri proses perubahan cabang default. Kami juga akan membahas hal-hal lain yang harus Anda pertimbangkan dan perbarui saat membuat perubahan ini. Terakhir, kita akan melihat alat untuk meringankan transisi.

Mengatur cabang default baru

Anda dapat menggunakan cabang selain main untuk perubahan baru atau mengubah lini pengembangan utama Anda di repositori Anda. Untuk mengubah nama cabang default untuk repositori baru, lihat Semua pengaturan dan kebijakan repositori.

Untuk mengubah cabang default repo Anda untuk menggabungkan permintaan pull baru, Anda memerlukan setidaknya dua cabang. Jika hanya ada satu cabang, itu sudah menjadi default. Anda harus membuat cabang kedua untuk mengubah default.

Catatan

Mengubah cabang default mengharuskan Anda memiliki izin Edit kebijakan . Untuk informasi selengkapnya, lihat Mengatur izin repositori Git.

1. Di bawah repositori proyek Anda, pilih Cabang.

2. Pada halaman Cabang , pilih Opsi lainnya di samping cabang default baru yang Anda inginkan, dan pilih Atur sebagai cabang default.

   

3. Setelah mengatur cabang default baru, Anda dapat menghapus default sebelumnya jika diinginkan.

Ada aspek lain yang harus Anda pertimbangkan sebelum membuat perubahan ini.

Pilih nama

Git 2.28 menambahkan kemampuan untuk memilih nama cabang awal. Pada saat yang sama, Azure Repos, GitHub, dan penyedia hosting Git lainnya menambahkan kemampuan untuk memilih nama cabang awal yang berbeda. Sebelumnya, cabang default hampir selalu diberi nama master. Nama alternatif yang paling populer adalah main. Opsi yang kurang umum termasuk trunk dan development. Tidak ada batasan apa pun dari alat yang Anda gunakan atau tim tempat Anda berada, nama cabang apa pun yang valid akan berfungsi.

Memperbarui sistem lain

Saat Anda mengubah ke cabang default yang berbeda, bagian lain dari alur kerja Anda mungkin terpengaruh. Anda harus memperhitungkan bagian-bagian ini saat merencanakan perubahan.

Pipelines

Perbarui pemicu CI untuk semua alur. Alur perancang dapat diedit di web. Alur YAML dapat diedit di repositori masing-masing.

Permintaan tarik dalam penerbangan

Targetkan ulang setiap permintaan pull terbuka ke cabang default baru.

Kloning yang ada

Klon baru repositori akan mendapatkan cabang default baru. Setelah pengalihan, semua orang dengan kloning yang ada harus berjalan git remote set-head origin -a (mengganti origin dengan nama remote mereka jika itu sesuatu yang lain) untuk memperbarui tampilan mereka dari cabang default jarak jauh. Cabang baru di masa mendatang harus didasarkan pada default baru.

Tautan masuk

Beberapa bookmark, dokumen, dan file non-kode lainnya yang menunjuk ke file di Azure Repos perlu diperbarui. Nama cabang untuk file atau direktori dapat muncul di URL.

Jika URL berisi querystring untuk version, misalnya &version=GBmybranchname, maka URL tersebut harus diperbarui. Untungnya, sebagian besar tautan ke cabang default tidak akan memiliki version segmen dan dapat dibiarkan apa adanya. Selain itu, setelah Anda menghapus cabang default lama, upaya untuk menavigasi ke sana akan dibawa ke default baru.

Pencerminan sementara

Repositori Git hanya dapat memiliki satu cabang default. Namun, untuk sementara waktu, Anda dapat menyiapkan pencerminan ad-hoc antara default lama dan default baru Anda. Dengan cara ini, jika pengguna akhir Anda terus mendorong ke default lama, mereka tidak perlu mengulangi pekerjaan di akhir mereka. Kita akan menggunakan Azure Pipelines untuk menyiapkan pencerminan sementara ini.

Catatan

Bagian ini menggunakan bahasa yang berseberangan dengan perspektif Microsoft. Secara khusus, kata master itu muncul di beberapa tempat yang konsisten dengan bagaimana kata itu digunakan di Git. Tujuan dari topik ini adalah untuk menjelaskan cara beralih ke bahasa yang lebih inklusif, seperti main. Menghindari semua penyebutan master akan membuat arah jauh lebih sulit dipahami.

Alur pencerminan

Catatan

Instruksi ini tidak tahan bodoh, dan penyiapan repositori Anda mungkin memerlukan perubahan tambahan seperti melonggarkan izin dan kebijakan.

Peringatan

Jika cabang default lama dan baru diperbarui sebelum alur ini berjalan, alur tidak akan dapat mencerminkan perubahan. Seseorang harus menggabungkan cabang default lama secara manual ke cabang default baru untuk menjalankannya secara otomatis lagi.

1. Untuk semua build CI yang ada, perbarui untuk dipicu terhadap cabang default baru Anda alih-alih yang lama.

2. Berikan identitas build Izin kontribusi ke repositori Anda. Navigasi ke Project Pengaturan> Repositories> (repo Anda)>Izin. Mungkin ada hingga dua identitas, satu untuk layanan build koleksi proyek dan yang lainnya untuk layanan build proyek. Pastikan izin Kontribusi mengatakan Izinkan.

3. Jika cabang default baru memiliki kebijakan cabang, berikan juga identitas build kebijakan Bypass saat mendorong izin. Izin ini adalah risiko keamanan karena pengguna berbahaya dapat membuat alur untuk menyelinapkan kode ke dalam repositori dalam proyek Anda. Saat pencerminan tidak diperlukan lagi, pastikan untuk menghapus izin ini.

4. Tambahkan file baru, mirror.yml ke repositori Anda di cabang default baru. Dalam contoh ini, kami berasumsi cabang default lama adalah master dan yang baru adalah main. Perbarui cabang pemicu dan git push baris jika nama cabang Anda berbeda.

trigger:
  branches:
    include:
    - main
    - master
 
pool: { vmImage: ubuntu-latest }
steps:
- checkout: self
  persistCredentials: true
- script: |
    git checkout $(Build.SourceBranchName)
    git push origin HEAD:master HEAD:main
  displayName: Mirror old and new default branches

5. Buat alur baru, pilih "Azure Repos Git" dan "File YAML Alur Azure yang Ada" dalam wizard. Pilih file yang mirror.yml Anda tambahkan di langkah sebelumnya. Simpan dan jalankan alur.

Pemecahan Masalah

Alur ini akan berjalan setiap kali ada dorongan ke master atau ke main. Ini akan membuat mereka tetap sinkron selama penerapan baru tidak tiba di kedua cabang secara bersamaan.

Jika alur mulai gagal dengan pesan kesalahan seperti "Pembaruan ditolak karena ujung cabang yang didorong berada di belakang jarak jauhnya", seseorang harus menggabungkan cabang lama ke cabang baru dengan tangan.

1. Kloning repositori dan cd ke direktorinya.
2. Lihat cabang default baru dengan git checkout main (jika main merupakan cabang default baru Anda).
3. Buat cabang baru untuk mengintegrasikan dua cabang dengan git checkout -b integrate.
4. Gabungkan cabang default lama dengan git merge master (jika master adalah cabang default lama Anda).
5. Dorong cabang baru, lalu buka dan selesaikan permintaan pull ke cabang default baru.
6. Alur pencerminan kemudian harus mengurus pencerminan penerapan penggabungan kembali ke default lama.