Dalam aliran GitHub, apakah OK untuk mendasarkan cabang fitur pada cabang fitur lain?


22

Kami menggunakan GitHub Flow dalam proyek kami dan sebagian besar waktu, kami membuka cabang fitur baru dari master , melakukan beberapa pekerjaan di sana, membuka PR, meninjau kode dan menggabungkan kembali menjadi master .

Namun, pekerjaan saya saat ini tergantung pada masalah lain yang sedang dikerjakan feature-branch-A. Apakah halal untuk membuat cabang saya dari cabang lain itu atau apakah itu bertentangan dengan semangat GitHub Flow?

Alternatifnya adalah dengan mendasarkan cabang saya pada master dan menggabungkan perubahan dari feature-branch-A(sering).

Opsi mana yang lebih disukai dalam aliran GitHub?

Jawaban:


24

Berikut adalah alur kerja yang saya ikuti ketika saya cabang dari cabang fitur:

  1. Buat feature-branch-Bdarifeature-branch-A
  2. Mengerjakan feature-branch-B
  3. Jika lebih banyak komit ditambahkan feature-branch-Asetelah bercabang, rebase feature-branch-Bkefeature-branch-A
  4. Selesai bekerja feature-branch-Bdan tunggu sampai feature-branch-Adigabung master.
  5. Setelah feature-branch-Adigabung menjadi master, rebase feature-branch-Bkemaster
  6. Gabung feature-branch-Bkemaster

Dengan mengikuti alur kerja di atas, akan muncul bahwa Anda bercabang dari mastersetelah feature-branch-Adigabungkan. Anda tidak harus menunggu sampai feature-branch-Adigabung untuk mulai bekerja feature-branch-B. Namun, Anda akan mendapatkan sejarah yang bersih tanpa pohon yang rumit.


Ini persis jawaban yang saya cari! Anda menyelamatkan saya sakit kepala untuk menyelesaikannya, terima kasih!
Vance Palacio

Jangan rebase komitmen yang sudah diterbitkan ... daolf.com/posts/git-series-part-2
Sebi2020

8

Saya pikir ini sepenuhnya ok jika Anda membuat fitur di fitur lain.

Tetapi jangan sering melakukannya. Saya melihat satu pengembang yang membuat ini dan dua atau minggu dia membuang 10 PR untuk penggabungan. Itu sangat melelahkan bagi anggota lain untuk ditinjau dan sulit untuk digabung juga. Cobalah jangan membuat pohon di git. Itu membantu membagi dua untuk menemukan kesalahan.


7

Hal utama yang ingin ditangani oleh git-flow adalah kemampuan untuk berpikir tentang peran cabang tertentu, dan dari mana cabang itu berasal dan bergabung.

Idealnya, semua cabang bergabung kembali ke codeline tempat mereka bergabung. Ini biasanya merupakan gabungan dari garis utama (dalam git-flow inilah dev). Cabang fitur cabang dan bergabung dari dev, lepaskan cabang cabang dan bergabung dari dev (dengan gabungan tambahan ke master). Cabang hot fixes dan bergabung dari master (dengan tambahan itu menggabungkan kembali ke dev).

Setiap codeline bercabang dari dan bergabung kembali ke induknya. Codeline dapat menarik kode dari codeline lain kapan saja jika perlu.

Jika cabang dari cabang fitur adalah "Saya ingin menjelajahi cara memperbaiki masalah di cabang fitur" - baik-baik saja. Ini cabang dari cabang fitur, melakukan beberapa kode dan bergabung kembali ke cabang fitur (atau dibuang).

  1. cabang dari fitur
  2. jelajahi ide
  3. bergabung ke fitur

Apa yang ingin Anda hindari adalah sesuatu yang terlihat seperti:

  1. cabang dari fitur yang diperlukan
  2. bekerja pada kode
  3. bergabung dari dev setelah fitur yang diperlukan selesai
  4. verifikasi fungsionalitas (dan komitmen tambahan) di cabang fitur
  5. bergabung dengan dev

Alasannya adalah bahwa awal dan akhir tidak cocok - itu membuat sedikit lebih sulit untuk memahami apa ini dan itu. Bukan tidak mungkin, tetapi hanya membutuhkan sedikit waktu bagi seseorang untuk memahami perannya.

Namun, jika ini adalah fitur baru yang bergantung pada kode yang belum ditemukan di dev, alurnya harus:

  1. cabang dari dev
  2. bergabung dari fitur yang diperlukan
  3. bekerja pada kode
  4. bergabung dari dev setelah fitur yang diperlukan selesai
  5. verifikasi fungsionalitas (dan komitmen tambahan) di cabang fitur
  6. bergabung dengan dev

Perhatikan bahwa ini dimulai dengan cabang dari dev dan diakhiri dengan gabungan ke dev.

Semua yang dikatakan, mungkin hal terbaik untuk dilakukan adalah menghindari penggabungan dari satu fitur ke fitur lainnya. Cabang fitur tersebut, lakukan persiapan apa pun yang diperlukan ... dan tunggu.

  1. cabang dari dev
  2. bekerja pada kode
  3. bergabung dari dev setelah fitur yang diperlukan selesai
  4. verifikasi fungsionalitas (dan komitmen tambahan) di cabang fitur
  5. bergabung dengan dev

Ini memberikan set cabang dan kode yang paling stabil.

Sesuatu yang perlu dipertimbangkan untuk pekerjaan di masa depan adalah memiliki fitur untuk menerbitkan antarmuka yang diperlukan untuk interoperabilitas dengan fitur lain - bahkan jika kode implementasi tidak lengkap. Ini akan digabungkan ke dev, dan kemudian fitur yang diperlukan dapat bekerja dari antarmuka tersebut seperti halnya fitur masa depan. Ini kemungkinan akan memungkinkan fitur masa depan untuk maju lebih lanjut (pengkodean terhadap antarmuka, pengujian terhadap stubb yang mengimplementasikan antarmuka) daripada jika harus menunggu fitur yang diperlukan untuk bergabung ke dev.


Pada set langkah ketiga Anda, downside adalah bahwa langkah 1 perlu mengandung beberapa "dummy commit". Dalam situasi saya, saya tidak memiliki sesuatu yang berguna untuk dilakukan sebelum required-featurebergabung.
Borek Bernard

Saya masih menunjuknya sebagai salah satu artikel favorit saya tentang percabangan: Strategi Percabangan SCM Lanjutan . Sementara itu berfokus pada sistem kontrol versi terpusat, ide-ide peran yang disajikan persis peta untuk git-flow.

Dan mengenai dummy commit, itu sebabnya paragraf terakhir ada di sana. Apa yang akan berguna adalah fitur yang dijalankan dan diselesaikan sebagai "menyediakan antarmuka untuk melakukan hal-hal". Kemudian fitur yang diperlukan dan fitur yang akan datang dapat bekerja di luar antarmuka tersebut. Sementara fitur yang diperlukan bekerja pada implementasi antarmuka, fitur masa depan akan dapat mematikannya dan melakukan tes terhadap mereka - menunggu fitur yang diperlukan untuk digabungkan ke dev.

Ingin tahu seberapa buruk langkah kedua Anda. Apakah dalam prakteknya suatu masalah bahwa cabang tidak memiliki awal dan akhir yang "sama"? Saya tidak berpikir itu akan terlalu mengganggu saya, tetapi mungkin itu adalah faktor kekacauan utama?
Borek Bernard

Ini adalah masalah menggambarkan dengan jelas melalui cabang, komit dan menggabungkan sejarah tentang cabang mana yang merupakan cabang induk. Di dalam git-flow, Anda harus mengikuti sistem yang dijelaskan dalam cabang fitur git flow . Cabang fitur cabang dari cabang berkembang dan bergabung kembali untuk berkembang. Saat Anda mulai bercabang dari cabang fitur lainnya, menjadi kurang jelas apa peran cabang itu. Saya mendorong Anda untuk menunggu sampai fitur yang diperlukan selesai jika Anda tidak dapat melanjutkan pada kode tanpa itu sekarang.

1

Cabang fitur biasanya dianggap kurang stabil daripada trunk (develop / master), sehingga Anda mungkin mengalami perubahan yang lebih mendasar daripada biasanya jika Anda mendasarkan pekerjaan Anda dari satu.

Juga, sementara biasanya disukai jika cabang telah didorong, tidak jarang untuk rebase cabang fitur ke cabang induknya, untuk mendapatkan sejarah yang lebih bagus, tetapi itu akan lebih rumit jika ada cabang tambahan yang menggantung, sehingga Anda Pada dasarnya menciptakan batasan baru untuk pemilik cabang induk, serta potensi sakit kepala untuk Anda sendiri.

Karena itu, tidak ada aturan ketat yang melarangnya. Ini hanya pola dan praktik terbaik.

Edit: bagian pertanyaan Anda tidak terjawab. Menggabungkan cabang fitur menjadi milik Anda sendiri, yang didasarkan pada master tidak benar-benar menghindari masalah yang disebutkan di atas, dan mungkin benar-benar membuat sejarah yang lebih berbelit-belit.

Jadi jika saya berada di posisi Anda dan saya dapat menunda pekerjaan sampai fitur a selesai, atau melakukan hal lain terlebih dahulu, saya akan melakukannya.

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.