Apa saja contoh praktik yang umum digunakan untuk penamaan cabang git? [Tutup]


1121

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 bergabung kembali ke bagasi saya. Namun 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-nama, dengan deskripsi terpisah untuk setiap tahap, maka nama-nama cabang mulai menjadi panjang dan sulit.

Saya memang belajar mencari melalui thread lama di sini bahwa saya bisa mulai menamai cabang dengan a / dalam nama, yaitu, topik / tugas, atau sesuatu seperti itu. Saya mungkin mulai melakukan itu dan melihat apakah itu membantu menjaga hal-hal lebih terorganisir.

Apa saja praktik terbaik untuk penamaan cabang git?

Sunting: 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-menerus menyesuaikan prioritas saya. :) Sebagai contoh mengapa saya mungkin membutuhkan lebih dari satu cabang pada suatu tugas, misalkan saya perlu melakukan tonggak tersendiri yang terpisah dalam tugas ke repositori CVS grup. Pada saat itu, karena interaksi saya yang tidak sempurna dengan CVS, saya akan melakukan komit itu dan kemudian membunuh cabang itu. (Saya telah melihat terlalu banyak keanehan berinteraksi dengan CVS jika saya mencoba untuk terus menggunakan cabang yang sama pada saat itu.)


Ya - mungkin bagus untuk tidak menyimpan atau mendorong cabang yang tidak berguna setelah Anda selesai menggunakannya. Kecuali ada alasan bagus untuk mempertahankan cabang topik (mis. Untuk berkonsultasi nanti), tidak ada masalah dalam menghapusnya. Git membuat percabangan mudah, dan akibatnya adalah Anda bisa berakhir dengan banyak cabang-cabang sepele yang bisa dibersihkan tanpa banyak basa-basi.
Eric Walker


2
Untuk kelengkapan, ada beberapa urutan karakter yang tidak dapat Anda gunakan .
Nick Westgate

18
Perlu ada tempat untuk jenis pertanyaan ini dalam jaringan StackExchange. Sangat menjengkelkan ketika seseorang mengajukan pertanyaan bagus seperti ini dan kemudian ditutup karena tidak mengikuti aturan. Jika itu terus terjadi maka itu mungkin harus menandakan perlunya mendukung jenis pertanyaan ini entah bagaimana. Hanya saja, ini mungkin harus diimplementasikan dalam situs Overflow karena mereka sangat terkait dengan pertanyaan jenis pemrograman. Melimpah, bagi saya, bukan untuk "pertanyaan yang bisa dijawab secara objektif" (terlalu spesifik), itu "pertanyaan pemrograman".
Nick Res

@Wim Kami menggunakan kunci masalah jira, dikombinasikan dengan judul pendek, misalnya:KEY-1234/allow-users-to-do-smart-stuff
RobAu

Jawaban:


938

Berikut adalah beberapa konvensi penamaan cabang yang saya gunakan dan alasannya

Konvensi penamaan cabang

  1. Gunakan token pengelompokan (kata-kata) di awal nama cabang Anda.
  2. Tentukan dan gunakan token timah pendek 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 telanjang sebagai komponen utama.
  5. Hindari nama deskriptif yang panjang untuk cabang yang 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 agar sesuai dengan alur kerja Anda. Saya suka menggunakan kata benda pendek untuk kata benda saya. Baca terus untuk kejelasan lebih lanjut.

Token pendek yang terdefinisi dengan baik

Pilih token pendek sehingga mereka tidak menambahkan terlalu banyak suara 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 siklus perubahan yang berbeda. Saya tidak tahu apa siklus Anda, tetapi anggaplah mereka 'baru', 'pengujian' dan 'diverifikasi'. Anda dapat memberi nama cabang Anda dengan versi singkat dari tag ini, selalu dieja dengan cara yang sama, untuk mengelompokkan mereka dan untuk mengingatkan Anda di tahap mana Anda berada.

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

Anda dapat dengan cepat memberi tahu cabang mana yang telah mencapai setiap tahap yang berbeda, dan Anda dapat mengelompokkannya 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-bagian

Anda dapat menggunakan hampir semua pembatas yang Anda suka dalam nama cabang, tetapi saya menemukan garis miring menjadi yang paling fleksibel. Anda mungkin lebih suka menggunakan tanda hubung atau titik. Tapi garis miring memungkinkan Anda melakukan penggantian 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 mengonfigurasinya, saya dapat mencari cabang dengan berbagai sub-bagian dengan mengetik karakter pertama dari bagian itu dan menekan tombol TAB. Zsh kemudian memberi saya daftar cabang yang cocok dengan bagian token yang saya ketik. Ini berfungsi untuk token sebelumnya dan juga yang tertanam.

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


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

(Zshell sangat bisa dikonfigurasi tentang penyelesaian perintah dan saya juga bisa mengkonfigurasinya untuk menangani tanda hubung, menggarisbawahi atau titik dengan cara yang sama. Tapi saya memilih untuk tidak.)

Ini juga memungkinkan Anda mencari cabang di 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, garis miring 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 telanjang

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

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

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

Hindari nama deskriptif yang panjang

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

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


156
Satu kelemahan menggunakan campuran bentuk like bug/20574/frabnotz-finderdan bug/20424adalah bahwa begitu Anda mulai tanpa sub-token, Anda tidak bisa menambahkannya nanti dan sebaliknya. EG: Jika Anda membuat bug/20424cabang, Anda tidak bisa membuat bug/20424/additional-fixingcabang nanti (kecuali Anda menghapus bug/20424cabang). Demikian juga, jika bug/20574/frabnotz-findersudah menjadi cabang, Anda tidak dapat membuat bug/20574cabang. Saya cenderung menggunakan pembatas non-sub-token dalam kasus-kasus seperti ini (misalnya bug/20574_frabnotz-finder), atau memilih nama default untuk sub-token (misalnya bug/20424/main).
Slipp D. Thompson

5
Itu juga memiliki manfaat mendorong beberapa alat berbasis Git GUI untuk memungkinkan divisi token runtuh seperti tampilan daftar direktori. Dalam contoh di atas, Anda akan melihat featuregrup dan buggrup, yang dapat diperluas untuk menampilkan foo, bartag untuk yang pertama dan yang 20574, 20592grup 20424, dan , 21334tag untuk yang terakhir.
Slipp D. Thompson

47
Saya akan memulai kampanye untuk tidak pernah menggunakan garis miring dalam penamaan cabang git. Alasan untuk ini adalah bahwa jika pada CI misalnya, Anda ingin merujuk ke nama cabang ketika mengemas kode misalnya, Anda ingin merujuk ke nama cabang saat membangun uri atau PATH (misalnya), mungkin membangun uri dalam skrip bash; Anda akan kesulitan membangun uri karena garis miring menambahkan bagian url. Ya mungkin untuk mengganti garis miring tetapi itu akan membawa saya ke banyak waktu untuk memilah.
Adam Spence

13
Apakah ada masalah bahwa garis miring ke depan memiliki arti untuk git dalam beberapa kasus? Misalnya, sebagai respons terhadap git branch -a, dan mendapatkan remotes/origin/master, dll. Ketika saya melihat git memberi tahu saya tentang cabang, saya tidak menggunakan garis miring ke depan dan ketika saya melihatnya, saya tahu itu adalah referensi "khusus".
Dogweather

11
Bisakah Anda menggunakan beberapa contoh alih-alih foo and bar?
Layak 7

329

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 berkomentar tentang aliran

Model Driessen termasuk

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

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

  • Beberapa cabang fitur dari cabang pengembangan. Nama berdasarkan nama fitur. Ini akan digabung kembali menjadi berkembang, bukan ke master atau melepaskan cabang.

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

Perbaikan terbaru adalah cabang yang berumur pendek untuk perubahan yang datang dari master dan akan menjadi master tanpa melibatkan cabang pengembangan.

masukkan deskripsi gambar di sini


129
Kecuali itu tidak benar-benar menjawab pertanyaan, karena menyisakan banyak konvensi penamaan kepada pengguna, terutama untuk cabang fitur (mereka bisa "apa pun kecuali menguasai, mengembangkan, melepaskan , atau perbaikan terbaru- "
Brian

1
@ Brian Apa yang akan membantu konvensi penamaan fitur dalam konteks masalah yang dipecahkan oleh model? Saya tidak benar-benar melihat, saat ini, bagaimana membuat perbedaan lebih lanjut dalam fitur sangat membantu. Mungkin masa depan vs rilis berikutnya, tapi itu bisa dinegosiasikan dan dengan demikian tidak boleh menjadi bagian dari nama. Agar mudah dibaca, mungkin cukup dengan menambahkannya dengan fitur- * sudah cukup. Anda bangun memilih beberapa kali jadi saya hanya ingin mendengar proses pemikiran Anda ...
Nick Res

2
Meskipun informasi yang baik, jawaban ini membahas pertanyaan tentang aliran alih-alih penamaan. Saya pikir OP ingin tahu kata-kata apa yang harus digunakan (kata benda vs kata kerja), pembatas, huruf, dll.
Caltor

6
Buku Continuous Delivery (hlm. 36) berpendapat bahwa model ini agak antitesis terhadap Continuous Integration, ... pada dasarnya, itu tidak benar-benar "gesit".
Markon

Ini sebenarnya tidak menjawab pertanyaan yang diajukan. Ini memang menawarkan wawasan untuk mengintegrasikan alur kerja git tertentu ke dalam pengembangan dan jadwal rilis menyeluruh, namun, op sedang mencari saran tentang konvensi tentang apa yang sebenarnya disebut cabang.
kendaraan roda

56

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 dari komit di komit pertama di cabang itu dengan "Cabang:" dan memasukkan penjelasan lebih lanjut dalam tubuh pesan jika subjek tidak memberi saya ruang yang cukup.

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

Itu membuat output dari git branchlebih berguna juga: itu hanya mendaftar cabang-cabang berumur panjang dan cabang topik aktif, tidak semua cabang pernah.


53

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

nama / fitur / masalah-pelacak-nomor / deskripsi pendek

yang akan diterjemahkan menjadi:

mike / blog / RSSI-12 / perbaikan logo

Bagian-bagian dipisahkan oleh garis miring ke depan karena dapat ditafsirkan sebagai folder di SourceTree untuk pengaturan yang mudah. Kami menggunakan Jira untuk pelacakan masalah kami, jadi termasuk nomornya memudahkan untuk mencari di sistem. Termasuk nomor itu juga membuatnya dapat dicari ketika mencoba menemukan masalah itu di dalam Github ketika mencoba mengirimkan permintaan tarik.


Saya sama, kecuali nomor bug / fitur dalam pesan commit (untuk GitHub -> integrasi Pivotal Tracker).
Leo

Saya ingin tahu apa artinya RSSI.
Renshuki

@ renshuki itu hanya kunci proyek Jira generik. Apa pun pelacak masalah yang Anda gunakan, masukkan ID tiket
MikeG

@ MikeG terima kasih atas ketepatannya!
Renshuki

3
Saya menggunakan yang sama kecuali saya melewati nomor masalah bersama dengan deskripsi:name/feature/issue-tracker-number-short-description
lephleg

22

Mengapa dibutuhkan tiga cabang / penggabungan 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-nama cabang unik, dan Anda bisa mengawali mereka dengan satu atau dua kata pendek dan deskriptif agar tetap dapat dibaca oleh manusia "ResizeWindow-43523". Ini juga membantu mempermudah Anda saat membersihkan cabang, karena Anda dapat mencari bug terkait. Beginilah biasanya saya memberi nama cabang saya.

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


12

Catatan, seperti yang diilustrasikan dalam komit e703d7 atau commit 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 tanda hubung" adalah cara aneh untuk mengatakan bahwa Anda tidak boleh menggunakan spasi.
Karena deskripsi baris perintah lebih umum untuk menggunakan kata-putus-putus, 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-formathalaman manual ).

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


7

Menindaklanjuti saran farktronix, kami telah menggunakan nomor tiket Jira untuk hal yang serupa, dan saya berencana untuk terus menggunakannya untuk cabang git. Tapi saya pikir nomor tiketnya sendiri mungkin cukup unik. Meskipun mungkin bermanfaat untuk memiliki kata deskriptif dalam nama cabang seperti yang dicatat farktronix, jika Anda cukup sering berpindah antar cabang, Anda mungkin ingin sedikit mengetik. Kemudian jika Anda perlu tahu nama cabang, cari di Jira untuk kata kunci terkait di tiket jika Anda tidak mengetahuinya. Selain itu, Anda harus memasukkan nomor tiket di setiap komentar.

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


1
Apakah ada masalah dengan konflik? Jika maksudnya adalah agar suatu v1.2.4cabang pada akhirnya mengarah ke titik akhir dengan sebuah v1.2.4tag (apakah saya benar dalam menganggap ini adalah situasi di mana Anda berdua menamai cabang dan tag setelah versi) , maka apakah itu penting? Tag masih bisa dihubungi di refs/tags/v1.2.4dan cabang di refs/heads/v1.2.4, dan tampaknya Git akan lebih suka nama tag ketika itu ambigu (dengan peringatan).
Slipp D. Thompson

1
Untuk contoh versi, seperti yang saya sebutkan dalam jawaban saya, praktik yang disarankan adalah awalan dengan "v" untuk nama tag, bukan cabang. Hindari ambiguitas jika Anda dapat menghindari miskomunikasi dan karena itu dapat menyebabkan masalah di ujung jalan bermigrasi ke apa pun VCS terbaru dan terhebat berikutnya.
Gary S. Weaver

2
Saya baru-baru ini bekerja dengan repo di mana kami menutup setiap cabang versi dengan tag dengan nama yang sama. Ini bekerja sangat baik karena tidak ada sedikit ambiguitas (tag menunjuk ke komit terakhir pada cabang yang sesuai dalam kebanyakan kasus), dan ketika mungkin ada, Git “melakukan hal yang benar” (dengan peringatan). Saya lebih suka itu karena jika seseorang membuat kesalahan berkepala tulang dan melakukan lebih lanjut ke cabang capped-off, Git akan terus memilih tag, yang merupakan tujuannya. Ambiguitas dapat membuat hal-hal menjadi lebih sederhana ketika sistem memiliki segalanya di bawah kendali, dan tujuannya jelas.
Slipp D. Thompson
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.