Konvensi penamaan yang baik untuk cabang bernama di {DVCS} pilihan Anda

16

Kami mengintegrasikan Mercurial secara perlahan di kantor kami dan melakukan pengembangan web yang kami mulai gunakan cabang bernama.

Kami belum menemukan konvensi yang baik sejauh penamaan cabang kami.

Kami sudah mencoba:

FeatureName (Dapat melihat ini menyebabkan masalah di telepon)
DEVInitial_FeatureName (Bisa membingungkan ketika pengembang datang dan turun baris)
{uniqueID (int)} _ Fitur

Sejauh ini uniqueID_featureName menang, kami berpikir untuk mempertahankannya dalam DB kecil hanya untuk referensi.

Itu akan memiliki: branchID (int), featureName (varchar), featureDescription (varchar), date, who etc. ...

Ini akan memberi kami cabang seperti: 1_NewWhizBangFeature, 2_NowWithMoreFoo, ... dan kami akan memiliki referensi yang mudah tentang apa yang dilakukan cabang itu tanpa harus memeriksa log.

Ada solusi yang lebih baik di luar sana?

version-control mercurial

— jfrobishow
sumber

14

Jika Anda tidak memiliki pelacak masalah, saya sarankan untuk mengaturnya lalu menggunakan {nama pelacak masalah} _ {nomor tiket}. Ketika seseorang bertahun-tahun dari sekarang mengajukan bug dan Anda tidak tahu persis bagaimana fitur seharusnya bekerja, akan mudah untuk membuat anotasi file dan kembali ke tempat pengguna mungkin meminta fungsionalitas yang tepat.

— Asa Ayers
sumber

Setuju kami memang memiliki bugtracker dan berencana untuk menggunakan bugID dalam nama cabang untuk perbaikan bug. Pertanyaan saya lebih untuk pengembangan yang sama sekali baru, ketika Anda tidak memperbaiki apa pun selain menambahkan sesuatu yang sama sekali baru. Saya kira kita bisa membuat tiket tambahan bodoh dan pergi dari sana.

— jfrobishow

5

Anda benar-benar harus membuat tiket untuk fitur baru. Pekerjaan juga harus dilacak. +1 untuk memerlukan id unik.

— AShelly

Jika Anda memastikan untuk memasukkan semua detail fitur baru ke dalam pelacak, nanti seseorang dapat memverifikasi apakah berfungsi sebagaimana dirancang atau jika memang ada bug. Saya bekerja di tim pengembangan yang mempertahankan program berumur 5+ tahun. Ada kalanya klien mengajukan bug dan ketika kami melakukan riset kami menemukan bahwa berfungsi sebagaimana dirancang dan pengembang asli dan pemohon asli keduanya hilang. Kami memiliki situasi serupa di mana kami tidak tahu mengapa ada sesuatu seperti itu dan jika fitur tidak ada dalam pelacak kami tidak akan memiliki cara untuk mengetahuinya.

— Asa Ayers

2

Saya menyarankan agar tetap sederhana dan beri nama cabang sesuai dengan konvensi FeatureName(atau feature-name). Ya, ini berarti namespace bersama, tetapi ini jarang menjadi masalah di dunia nyata. Setelah fitur selesai dan benar-benar bergabung ke jalur utama, cabang dapat dihapus dengan aman.

Gagasan utama dari kontrol versi terdistribusi adalah bahwa itu harus mudah untuk bercabang, memperkenalkan birokrasi tambahan, seperti id unik wajib, hanya akan membuat ini lebih sulit.

— Adam Byrtek
sumber

1

Saya setuju, ini jalan yang harus ditempuh. Di dunia apa Anda akan memiliki begitu banyak cabang sehingga Anda tidak dapat menghindari tabrakan?

— alternatif

Cukup adil, mendapatkan deskripsi yang terkait dengan nama yang saya kira lebih penting bagi kami ... komit awal harus berisi itu, tapi saya tidak tahu cara untuk mengekstraknya dengan cepat.

— jfrobishow

1

Dalam lingkungan perusahaan besar, membiarkan pengembang membuat nama untuk fitur akan menyebabkan sakit kepala cepat atau lambat.

— AShelly

1

Saya mengerti, karena di "lingkungan perusahaan besar" pengembang tidak dapat dipercaya. Tapi tunggu, mereka juga membuat nama untuk variabel, fungsi dan file. Kita harus membentuk komite untuk mengendalikan itu juga! (ironi)

— Adam Byrtek

2

Saya sarankan menggunakan formulir tersebut (misalnya):

BUG_ID
ID BUG #
TICKET_ID
TIKET # ID
feature_bla-bla-bla
release-x.xx.xx
release_x.xx.xx
build_2010-20-12
build_4565
BRANCH_x.xx.xx

Cukup pilih awalan yang baik (untuk memungkinkan keluaran filter dari cabang hg ), aturan kapitalisasi dan pembatas antara awalan dan ID / nama.

— gavenkoa
sumber

+1 yang kami gunakan pada BUGID_ {freeCamelCasedTextDescription} pada akhirnya.

— jfrobishow