Pertanyaan praktik terbaik penamaan cabang git [tertutup]


Saya telah menggunakan repositori git lokal yang berinteraksi dengan repositori CVS grup saya selama beberapa bulan, sekarang. Saya telah membuat sejumlah cabang yang hampir neurotik, yang sebagian besar untungnya telah bersatu kembali ke dalam batang saya. Tapi penamaan mulai menjadi masalah. Jika saya memiliki tugas yang mudah dinamai dengan label sederhana, tetapi saya menyelesaikannya dalam tiga tahap yang masing-masing menyertakan cabang mereka sendiri dan menggabungkan situasi, maka saya dapat mengulangi nama cabang setiap kali, tetapi itu membuat sejarah sedikit membingungkan. Jika saya mendapatkan lebih spesifik dalam nama, dengan deskripsi terpisah untuk setiap tahap, maka nama cabang mulai menjadi panjang dan berat.

Saya belajar mencari melalui utas lama di sini sehingga saya bisa mulai menamai cabang dengan tanda / di nama, yaitu, topik / tugas, atau sesuatu seperti itu. Saya mungkin mulai melakukan itu dan melihat apakah itu membantu menjaga hal-hal terorganisir dengan lebih baik.

Apa sajakah praktik terbaik untuk menamai cabang git?

Edit: Tidak ada yang benar-benar menyarankan konvensi penamaan. Saya menghapus cabang ketika saya selesai dengan mereka. Saya kebetulan memiliki beberapa di sekitar karena manajemen terus menyesuaikan prioritas saya. :) Sebagai contoh mengapa saya mungkin membutuhkan lebih dari satu cabang pada tugas, misalkan saya perlu melakukan tonggak sejarah diskrit pertama dalam tugas ke repositori CVS grup. Pada saat itu, karena interaksi saya yang tidak sempurna dengan CVS, saya akan melakukan itu dan kemudian membunuh cabang itu. (Saya telah melihat terlalu banyak keanehan berinteraksi dengan CVS jika saya mencoba terus menggunakan cabang yang sama pada saat itu.)


787
2017-11-07 21:29


asal


Jawaban:


Berikut beberapa konvensi penamaan cabang yang saya gunakan dan alasannya

Konvensi penamaan cabang

  1. Gunakan token pengelompokan (kata) di awal nama cabang Anda.
  2. Definisikan dan gunakan token prospek singkat untuk membedakan cabang dengan cara yang berarti bagi alur kerja Anda.
  3. Gunakan garis miring untuk memisahkan bagian dari nama cabang Anda.
  4. Jangan gunakan angka kosong sebagai bagian utama.
  5. Hindari nama deskriptif panjang untuk cabang-cabang berumur panjang.

Token grup

Gunakan token "pengelompokan" di depan nama cabang Anda.

group1/foo
group2/foo
group1/bar
group2/bar
group3/bar
group1/baz

Grup dapat diberi nama apa pun yang Anda suka untuk mencocokkan alur kerja Anda. Saya suka menggunakan kata benda pendek untuk saya. Baca terus untuk kejelasan lebih lanjut.

Token singkat yang terdefinisi dengan baik

Pilih token pendek agar mereka tidak menambahkan terlalu banyak gangguan ke setiap nama cabang Anda. Saya menggunakan ini:

wip       Works in progress; stuff I know won't be finished soon
feat      Feature I'm adding or expanding
bug       Bug fix or experiment
junk      Throwaway branch created to experiment

Setiap token ini dapat digunakan untuk memberi tahu Anda bagian mana dari alur kerja Anda yang dimiliki masing-masing cabang.

Sepertinya Anda memiliki banyak cabang untuk berbagai siklus perubahan. Saya tidak tahu apa siklus Anda, tetapi mari kita asumsikan mereka 'baru', 'menguji' dan 'diverifikasi'. Anda dapat menamai cabang-cabang Anda dengan versi singkat dari tag ini, selalu dieja dengan cara yang sama, untuk mengelompokkan keduanya dan mengingatkan Anda pada tahap mana Anda berada.

new/frabnotz
new/foo
new/bar
test/foo
test/frabnotz
ver/foo

Anda dapat dengan cepat mengetahui cabang mana yang telah mencapai setiap tahap yang berbeda, dan Anda dapat mengelompokkannya bersama dengan mudah menggunakan opsi pencocokan pola Git.

$ git branch --list "test/*"
test/foo
test/frabnotz

$ git branch --list "*/foo"
new/foo
test/foo
ver/foo

$ gitk --branches="*/foo"

Gunakan garis miring untuk memisahkan bagian

Anda dapat menggunakan sebagian besar pembatas apa pun yang Anda suka di nama cabang, tetapi saya menemukan garis miring menjadi yang paling fleksibel. Anda mungkin lebih suka menggunakan garis atau titik. Tapi garis miring membiarkan Anda melakukan perubahan nama cabang saat mendorong atau mengambil ke / dari remote.

$ git push origin 'refs/heads/feature/*:refs/heads/phord/feat/*'
$ git push origin 'refs/heads/bug/*:refs/heads/review/bugfix/*'

Bagi saya, garis miring juga berfungsi lebih baik untuk ekspansi tab (penyelesaian perintah) di shell saya. Cara saya mengaturnya, saya dapat mencari cabang dengan sub-bagian yang berbeda dengan mengetikkan karakter pertama dari bagian tersebut dan menekan tombol TAB. Zsh kemudian memberi saya daftar cabang yang cocok dengan bagian token yang saya ketikkan. Ini berfungsi untuk token sebelumnya serta yang disematkan.

$ git checkout new<TAB>
Menu:  new/frabnotz   new/foo   new/bar


$ git checkout foo<TAB>
Menu:  new/foo   test/foo   ver/foo

(Zshell sangat dapat dikonfigurasi tentang penyelesaian perintah dan saya juga bisa mengkonfigurasinya untuk menangani setrip, garis bawah atau titik dengan cara yang sama. Tapi saya memilih untuk tidak.)

Ini juga memungkinkan Anda mencari cabang dalam banyak perintah git, seperti ini:

git branch --list "feature/*"
git log --graph --oneline --decorate --branches="feature/*" 
gitk --branches="feature/*" 

Peringatan: Seperti yang ditunjukkan Slipp dalam komentar, tebasan dapat menyebabkan masalah. Karena cabang diimplementasikan sebagai jalur, Anda tidak dapat memiliki cabang bernama "foo" dan cabang lain bernama "foo / bar". Ini bisa membingungkan bagi pengguna baru.

Jangan gunakan angka kosong

Jangan gunakan menggunakan angka telanjang (atau angka heksadesimal) sebagai bagian dari skema penamaan cabang Anda. Di dalam tab-ekspansi nama referensi, git dapat memutuskan bahwa nomor adalah bagian dari sha-1 bukan nama cabang. Misalnya, bug pelacak nama saya dengan angka desimal. Saya beri nama cabang terkait saya CRnnnnn alih-alih hanya nnnnn untuk menghindari kebingungan.

$ git checkout CR15032<TAB>
Menu:   fix/CR15032    test/CR15032

Jika saya mencoba memperluas hanya 15032, git akan tidak yakin apakah saya ingin mencari nama SHA-1 atau cabang, dan pilihan saya akan agak terbatas.

Hindari nama deskriptif yang panjang

Nama cabang panjang bisa sangat membantu ketika Anda melihat daftar cabang. Tapi itu bisa menghalangi ketika melihat log satu baris yang dihiasi karena nama cabang dapat memakan sebagian besar garis tunggal dan menyingkat bagian yang terlihat dari log.

Di sisi lain, nama-nama cabang yang panjang dapat lebih membantu dalam "menggabungkan komitmen" jika Anda tidak terbiasa menulis ulang dengan tangan. Pesan commit gabungan default adalah Merge branch 'branch-name'. Anda mungkin merasa lebih bermanfaat jika menggabungkan pesan yang muncul sebagai Merge branch 'fix/CR15032/crash-when-unformatted-disk-inserted' bukan hanya Merge branch 'fix/CR15032'.


714
2018-05-19 23:25



Model percabangan Git yang sukses oleh Vincent Driessen memiliki saran bagus. Gambar di bawah. Jika model percabangan ini menarik bagi Anda pertimbangkan ekstensi aliran ke git. Yang lain punya berkomentar tentang aliran

Model Driessen termasuk

  • Cabang utama, hanya digunakan untuk rilis. Nama yang khas master.

  • Cabang "berkembang" dari cabang itu. Itu yang digunakan untuk sebagian besar pekerjaan utama. Biasa dinamai develop.

  • Beberapa fitur bercabang dari cabang pengembangan. Nama berdasarkan nama fitur. Ini akan digabungkan kembali ke dalam pengembangan, bukan ke master atau melepaskan cabang.

  • Lepaskan cabang untuk menahan rilis kandidat, dengan hanya perbaikan bug dan tidak ada fitur baru. Nama yang khas rc1.1.

Hotfix adalah ranting yang berumur pendek untuk perubahan yang berasal dari master dan akan masuk ke master tanpa pengembangan cabang yang terlibat.

enter image description here


227
2017-11-23 16:58



Preferensi pribadi saya adalah menghapus nama cabang setelah saya selesai dengan cabang topik.

Alih-alih mencoba menggunakan nama cabang untuk menjelaskan arti cabang, saya memulai baris subjek pesan commit di commit pertama pada cabang tersebut dengan "Cabang:" dan menyertakan penjelasan lebih lanjut di badan pesan jika subjek tidak memberi saya cukup ruang.

Nama cabang yang saya gunakan adalah murni pegangan untuk merujuk ke cabang topik saat mengerjakannya. Setelah bekerja pada cabang topik selesai, saya menyingkirkan nama cabang, terkadang menandai komit untuk referensi nanti.

Itu membuat output git branch lebih berguna juga: ia hanya mencantumkan cabang-cabang berumur panjang dan cabang-cabang topik aktif, tidak semua cabang pernah ada.


42
2017-11-07 21:51



Saya telah mencampur dan mencocokkan dari skema yang berbeda yang pernah saya lihat dan berdasarkan pada alat yang saya gunakan. Jadi nama cabang saya yang lengkap adalah:

nama / feature / issue-tracker-number / deskripsi singkat

yang akan diterjemahkan menjadi:

mike / blogs / RSSI-12 / memperbaiki logo

Bagian-bagian dipisahkan oleh garis miring ke depan karena mereka diartikan sebagai folder di SourceTree untuk memudahkan organisasi. Kami menggunakan Jira untuk pelacakan masalah kami sehingga menyertakan nomor yang memudahkan untuk mencari di sistem. Menyertakan nomor tersebut juga membuatnya dapat ditelusuri ketika mencoba menemukan masalah tersebut di dalam Github ketika mencoba mengirim permintaan tarik.


25
2017-10-10 15:58



Mengapa dibutuhkan tiga cabang / gabungan untuk setiap tugas? Bisakah Anda menjelaskan lebih lanjut tentang itu?

Jika Anda menggunakan sistem pelacakan bug, Anda dapat menggunakan nomor bug sebagai bagian dari nama cabang. Ini akan membuat nama cabang tetap unik, dan Anda dapat menambahkannya dengan kata yang singkat dan deskriptif atau dua untuk membuatnya mudah dibaca manusia, seperti "ResizeWindow-43523". Ini juga membantu mempermudah saat Anda membersihkan cabang, karena Anda dapat mencari bug yang terkait. Ini adalah bagaimana saya biasanya menamai cabang saya.

Karena cabang ini akhirnya digabungkan kembali menjadi master, Anda harus aman menghapusnya setelah Anda bergabung. Kecuali Anda bergabung dengan --squash, seluruh sejarah cabang akan tetap ada jika Anda membutuhkannya.


19
2017-11-11 06:24



Perhatikan, seperti yang diilustrasikan dalam lakukan e703d7 atau lakukan b6c2a0d  (Maret 2014), sekarang bagian dari Git 2.0, Anda akan menemukan konvensi penamaan lain (yang dapat Anda terapkan ke cabang).

"Ketika Anda perlu menggunakan ruang, gunakan dasbor" adalah cara yang aneh untuk mengatakan bahwa Anda tidak boleh menggunakan spasi.
  Karena itu lebih umum untuk deskripsi baris perintah untuk menggunakan putus-multi-kata, Anda bahkan tidak ingin menggunakan spasi di tempat-tempat ini.

Nama cabang tidak boleh memiliki ruang (lihat "Karakter mana yang ilegal dalam nama cabang?"dan git check-ref-format halaman manual).

Jadi untuk setiap nama cabang yang akan diwakili oleh ekspresi multi-kata, menggunakan '-'(Dash) sebagai pemisah adalah ide yang bagus.


7
2018-06-14 19:41



Menindaklanjuti saran farktronix, kami telah menggunakan nomor tiket Jira untuk hal yang sama dengan lincah, dan saya berencana untuk terus menggunakannya untuk git branch. Tapi saya pikir nomor tiket itu sendiri mungkin cukup unik. Meskipun mungkin ada gunanya untuk memiliki kata deskriptif dalam nama cabang seperti yang dicatat oleh farktronix, jika Anda berpindah antar cabang cukup sering, Anda mungkin ingin mengetik lebih sedikit. Kemudian jika Anda perlu mengetahui nama cabang, lihat di Jira untuk kata kunci terkait di tiket jika Anda tidak mengetahuinya. Selain itu, Anda harus menyertakan nomor tiket di setiap komentar.

Jika cabang Anda mewakili versi, tampaknya konvensi umum adalah menggunakan xxx (contoh: "1.0.0") format untuk nama cabang dan vx.xx (contoh "v1.0.0") untuk nama tag (untuk menghindari konflik) . Lihat juga: ada-ada-standar-penamaan-konvensi-untuk-git-tag


4
2018-01-27 21:31