Saat menggunakan Git, apakah menggunakan cabang master untuk pengembangan aktif disarankan?

Pertama, beberapa latar belakang, kami sedang dalam proses memindahkan semua tim proyek kami untuk menggunakan git dan sedang dalam proses meletakkan pedoman untuk bagaimana repositori harus diatur sehingga cabang-cabang tertentu juga dapat dimonitor untuk integrasi berkelanjutan dan penyebaran otomatis ke server pengujian. Saat ini ada dua model yang sedang berkembang:

Sangat dipengaruhi oleh artikel nvie.com tentang percabangan yang sukses dengan cabang utama yang mewakili kode paling stabil, cabang pengembangan untuk kode tepi pendarahan, dan cabang integrasi untuk kode yang siap untuk pengujian QA.
Model alternatif di mana cabang utama mewakili kode pengembangan tepi pendarahan, cabang integrasi untuk kode yang siap untuk pengujian QA, dan cabang produksi untuk kode stabil yang siap untuk ditempatkan.

Pada titik ini, ini sebagian merupakan masalah semantik sehubungan dengan apa yang diwakili cabang master, tetapi apakah melakukan pengembangan aktif pada cabang master sebenarnya merupakan praktik yang baik atau apakah itu tidak terlalu relevan?

git branching

— rjzii
sumber

Saya suka worfklow yang digunakan Scott Chacon untuk mengembangkan GitHub: scottchacon.com/2011/08/31/github-flow.html

— user16764

Seperti yang dijelaskan, bagi saya tampaknya lebih merupakan masalah semantik daripada tidak - organisasi mana pun akan mengembangkan proses mereka sendiri dan dalam beberapa hal nama-nama tersebut perlu mencerminkan alur kerja Anda. Secara umum kuncinya adalah bahwa di suatu tempat Anda mendefinisikan sesuatu sedemikian rupa sehingga "kode sumber HEAD selalu mencerminkan keadaan siap produksi". Apa yang Anda pilih untuk dipanggil itu tidak terlalu penting tetapi git-flow dan alur kerja GitHub fokus pada pemisahan itu dan pada pengontrolan saat Anda mendorong ke "thingy" yang siap produksi

— Murph

@Murph - Benar, tetapi karena kami melakukan ini dari awal, saya pikir akan lebih baik untuk lebih atau kurang mengikuti konvensi umum sehingga pengembang baru yang dipekerjakan tidak memiliki kurva belajar yang curam karena praktik internal yang tidak biasa.

— rjzii

Maka Anda telah menjawab pertanyaan Anda sendiri (-: Sejujurnya bahkan dengan mengajukan pertanyaan Anda jauh di depan kurva ...

— Murph

Jawaban:

Satu-satunya fitur nyata dari mastercabang adalah bahwa ini adalah default untuk beberapa operasi. Juga, nama-nama cabang hanya memiliki arti dalam repositori tertentu. Saya mastermungkin menunjuk ke Anda development, misalnya. Juga, mastercabang bahkan tidak diperlukan, jadi jika ada kebingungan tentang cabang mana yang seharusnya, saran saya biasanya adalah untuk meninggalkannya sama sekali.

Namun, menurut saya, cara terbaik untuk memikirkannya adalah sebagai standar untuk mendorongnya. Kebanyakan tutorial online yang dibaca pengembang Anda akan menganggap itu. Jadi, sangat masuk akal untuk memiliki mastercabang apa pun yang paling sering didorong. Beberapa orang menganggapnya sebagai salinan asli yang tidak tersentuh bagi pengembang kecuali setelah pengawasan ketat, tetapi menggunakannya dengan cara itu menghilangkan banyak standar membantu git menyediakan. Jika Anda menginginkan cabang murni semacam itu, saya akan meletakkannya di repositori yang benar-benar terpisah yang hanya dapat ditulis oleh beberapa orang.

— Karl Bielefeldt
sumber

+1. Dan karena kode "siap produksi" adalah kode penting, itu juga harus hidup di cabang dengan nama yang menyoroti pentingnya ini. "master" sebagai nama cabang default pasti tidak memenuhi permintaan itu, karena juga digunakan di setiap repositori lain untuk niat apa pun.

— Bananeweizen

+1. Inilah jawaban kehidupan nyata. Untuk menekankan poin: tidak ada seorang pun di tim Anda yang mendefinisikan cabang "master", sistem git yang melakukannya. Untuk hal-hal penting, pertahankan cabang yang didefinisikan oleh seseorang di tim Anda.

— Travis Wilson

Sangat setuju. Sementara saya sangat menyukai model git flow ( nvie.com/posts/a-successful-git-branching-model ), satu-satunya hal yang mengganggu saya adalah bahwa master dikhususkan untuk rilis, yang kontra-intuitif.

— Bachi

Tidak, itu tidak disarankan, bahkan di awal sebelum Anda pergi ke QA. Sebagai praktik terbaik, pola pengembangan harus konsisten dari awal hingga akhir. Cabang master Anda harus dimulai dengan kosong, Anda harus memangkas cabang pengembangan Anda dan mulai menambahkan file, bergabung ke cabang integrasi Anda, lalu selanjutnya ke master Anda.

Meskipun tidak ada yang peduli selama pengembangan yang tidak dibangun cabang master, itu cenderung pada kebiasaan buruk sejak dini. Master harus selalu membangun, dan untuk rilis fitur utama juga bukan ide yang buruk untuk memiliki cabang-cabang build besar sehingga titik rilis yang stabil dapat dikembalikan ke jika diperlukan.

— Joel Etherton
sumber

Bukankah lebih baik melakukan pelacakan versi melalui tag?

— Adonis K. Kakoulidis

@AdonisK .: Saya gagal melihat relevansi pertanyaan Anda.

— Joel Etherton