Apakah Konflik Penggabungan yang Sering Terjadi Beberapa Tanda Masalah?


35

Di tim kami, kami menggunakan Git sebagai kontrol sumber kami. Kami memiliki beberapa area kode yang hampir independen tetapi memiliki beberapa tumpang tindih. Akhir-akhir ini kami telah membahas alur kerja dan pendekatan untuk menggunakan kontrol sumber. Salah satu keluhan yang muncul ketika saya mempromosikan menggunakan alur kerja cabang fitur adalah bahwa orang sering mengalami konflik gabungan rumit yang mereka salah atasi. Yang rumit, maksud saya "tidak jelas bagaimana cara menyelesaikannya". Sehubungan dengan ini, alur kerja lainnya sedang lebih aktif digunakan, seperti alur kerja berbasis "tarik rebase".

Sebagai penganjur pendekatan cabang fitur, saya tidak benar-benar mendapatkan keluhan. Ya, Anda harus tetap memperbarui fitur cabang lokal Anda dari master atau di mana pun, tetapi hanya itulah masalah sebenarnya yang saya lihat. Saya berpikir bahwa jika penggabungan Anda selalu rumit dan mungkin memiliki efek sekunder, maka itu lebih merupakan masalah kerja tim daripada masalah Git.

Apakah saya benar dalam memikirkan ini? Apakah konflik menggabungkan rumit tanda sesuatu yang baik atau buruk?


1
Berapa lama fitur bertahan? Seberapa baik modulasi kodenya? Bisakah Anda (misalnya), memilih ceri di komit kode uji (itu dilakukan terlebih dahulu, dan terpisah dari kode yang sebenarnya, kan?) Untuk melihat bagaimana fungsi berubah?

@MichaelT Basis kode untuk basis kode uji otomatis kami. Kami akan mulai bekerja pada tambahan baru untuk proyek kami yang mungkin akan membutuhkan pengembangan paralel sebentar. Oleh karena itu pembahasan fitur-cabang vs yang lain.
joshin4colours

7
Apakah orang benar-benar mengalami masalah seperti ini, atau mereka takut masalah itu akan muncul?
Christopher Creutzig

2
Ngomong-ngomong, tutorial mengagumkan yang telah Anda
tautkan

1
Rebasing cabang fitur atau menggabungkannya dengan hasil trunk di gabungan yang sama. Rebasing sebenarnya melakukan lebih banyak penggabungan dan karenanya lebih cenderung menciptakan konflik buruk. Yang penting adalah seberapa sering hal itu dilakukan.
Jan Hudec

Jawaban:


23

Bukan tidak mungkin masalahnya adalah kode Anda. Jika basis kode Anda memiliki banyak hubungan antar modul, maka setiap perubahan akan memiliki sulur di mana-mana, dan setiap pengembang berinteraksi dengan kode orang lain, itu akan menjadi mimpi buruk.

Saya cenderung berpikir Anda akan memperhatikan hal ini terlebih dahulu, tetapi mungkin Anda sudah terbiasa sehingga Anda tidak bisa melihatnya lagi.


9
Ini adalah pikiran pertamaku. Konflik gabungan yang rumit terjadi ketika beberapa perubahan dilakukan pada kode yang sama. Jika Anda memiliki proyek yang cukup muda maka ini adalah umum, tetapi jika Anda memiliki basis kode berukuran baik maka ini bisa menjadi tanda "objek dewa" atau bahwa beberapa modul / kelas melakukan terlalu banyak dan perlu dire-refored. Itu juga bisa berasal dari komuter yang terlalu bersemangat melakukan lusinan perubahan kecil, tapi itu jarang terjadi.
TMN

1
Fakta basis kode kami agak "muda" (sekitar 6 bulan, melewati beberapa refaktor utama) bisa menjadi indikator hal ini.
joshin4colours

10
@ joshin4colours Jika Anda melakukan refactoring saat seseorang sedang menulis fitur besar, Anda dalam kesulitan.
Sean McSomething

17

Saya terbiasa dengan alur kerja "fetch-rebase-push". Yang sebenarnya adalah alur kerja pertama, paling primitif, yang dijelaskan dalam tutorial Anda. Berikut adalah keuntungannya:

  • Integrasi berkelanjutan yang sejati
  • Manajemen konflik dini - tepat setelah seseorang telah menulis dan menguji kode tersebut
  • Respon cepat - "-Hei, Bob, interpolasi kubik yang Anda tulis memberikan hasil yang lucu, dapatkah Anda melihatnya saat saya makan siang?"
  • Tidak ada komitmen gabungan - timeline bersih seolah-olah satu pengembang menulis everithyng

Sekarang, tentang konflik gabungan yang rumit. Saya tidak mengerti bagaimana seseorang bisa mengalami penggabungan yang sering dan rumit. Komplikasi muncul dari tidak rebasing / memetik ceri untuk waktu yang lama, bekerja pada fitur yang sendirian selama sebulan.

Saya pribadi lebih suka berurusan dengan konflik yang sering dan mudah digabung (sebenarnya rebase), daripada jarang, horor gabungan yang mencakup semua.


1
Deskripsi hebat alur kerja Git yang baik, tetapi ini tidak cukup menjawab pertanyaan saya.
joshin4colours

2
@ Asty ini benar. Hanya paragraf tengah yang menjawab pertanyaan Anda. Tapi di sini ada jawaban langsung. Jika penggabungan sering dan sulit, maka ini tentu merupakan indikasi alur kerja bermasalah / masalah komunikasi / masalah arsitektur / divisi atau masalah peran.
Vorac

7

Penggabungan dan rebase harus menyebabkan konflik yang sama persis, untuk konflik inheren yang harus diselesaikan manusia (yaitu dua pengembang mengubah baris kode yang sama). Untuk konflik lainnya, gabungan sebenarnya cenderung lebih bersih, karena Anda tidak mengubah SHA-1 dari commit di semua tempat. Saya tidak yakin bagaimana Anda bisa masuk ke keadaan di mana penggabungan menyebabkan lebih banyak konflik daripada rebases, tapi itu tentu saja pertanda bahwa alur kerja beberapa orang kacau, dan mereka mungkin membutuhkan lebih banyak pelatihan tentang cara kerja git. Apakah mereka menghapus komitmen gabungan orang lain ketika mereka melakukan rebounds lokal mereka, atau sesuatu seperti itu?

Manfaat dan kelemahan dari metode pull-rebase adalah sangat mirip dengan alur kerja terpusat yang banyak digunakan orang. Anda tidak harus mengerti percabangan untuk menggunakannya.

Bagaimanapun, sangat layak untuk melakukan alur kerja cabang fitur hanya secara lokal, jika Anda tidak dapat membuat orang lain masuk ke dalamnya.


5

Proyek yang sedang saya kerjakan memiliki masalah seperti ini dari waktu ke waktu dan sepertinya merupakan hasil dari beberapa faktor:

  • Kami menggunakan Visual Studio dan file-file seperti Visual Studio .sln hanyalah dokumen XML (yang tidak merespon dengan baik terhadap penggabungan tekstual) yang penuh dengan Panduan (yang tidak dapat dipahami Git lebih baik daripada kita semua) dan dapat dengan mudah menjadi digabung dengan buruk dan menyebabkan file hilang.
  • Beberapa orang sedang mengerjakan bidang kode yang serupa, sehingga perubahan yang didorong dapat bersebelahan di kelas. Meskipun tidak dapat dihindari dalam situasi ini, konfigurasi jenis ini akan menjadi pekerjaan yang sangat sulit untuk sistem kontrol sumber apa pun. Bahkan jika Anda memiliki komunikasi hebat dalam tim Anda, kadang-kadang orang tidak akan menyadari bahwa mereka saling bertabrakan dengan kode satu sama lain dan konflik muncul.

Saya tertarik dengan potensi Semantic Merge untuk membantu dengan beberapa masalah itu, tetapi jelas itu hanya berguna jika Anda bekerja dalam bahasa yang dapat diuraikan dan saya belum mengalami tantangan signifikan ketika saya Saya menggunakannya, jadi saya tidak dapat menjamin efektivitasnya.


4

Kecuali jika pengembang memodifikasi komitmen historis (bukan gabungan murni), konflik dalam model tipe alur kerja fitur adalah tanda basis kode yang digabungkan secara ketat (/ basis kode baru) atau penugasan fitur yang tumpang tindih.


0

Anda memiliki cabang (master) utama dan semua orang bekerja di cabang fitur mereka.

Bekerja di cabang fitur dapat memakan waktu mulai dari beberapa jam hingga beberapa bulan.

Sesekali seseorang akan membalikkan penggabungan perubahan mereka kembali ke cabang utama. Pimpinan tim Anda perlu memastikan bahwa hanya satu orang yang melakukan penggabungan terbalik pada suatu waktu. Setelah ini selesai, Anda perlu meneruskan penggabungan dari cabang Utama ke cabang fitur Anda. Setelah semua orang melakukan penggabungan ke depan, orang lain dapat diizinkan untuk membalikkan penggabungan menjadi cabang utama. Kalau tidak, terlalu banyak perubahan akan dibatalkan penggabungan dan Anda akan memiliki banyak konflik gabungan pada penggabungan ke depan Anda.

Hanya untuk memperjelas terminologi, dengan "membalikkan penggabungan" yang saya maksud penggabungan dari cabang fitur ke cabang utama, dan dengan "penggabungan ke depan" maksud saya menggabungkan dari cabang utama ke cabang fitur. Berdasarkan apa yang saya alami sebelumnya, Anda cenderung melihat lebih banyak konflik penggabungan pada penggabungan terbalik, sebagai kebalikan dari penggabungan ke depan.


1
Penggabungan ke cabang utama tidak boleh memiliki konflik. Anda selalu menggabungkan utama ke fitur terlebih dahulu, jadi fitur ke utama kemudian bebas konflik.
gnasher729

@ gnasher729 - Saya pikir itulah yang dikatakan jawaban ini - saran yang saya lihat adalah bahwa setiap pengembang bergabung dari main ke cabang fitur mereka setiap kali ada yang melakukan sesuatu ke main, sehingga semua konflik segera diselesaikan pada cabang fitur.
Periata Breatta

Dia berkata "Anda lebih mungkin mengalami konflik yang menyatu dari fitur ke menguasai"
gnasher729

0

Dua hal yang mungkin membantu: Satu, hindari alat apa pun yang melakukan perubahan sendiri. Dua pengembang yang menggunakan pengaturan tab berbeda adalah resep untuk bencana. Dua, buat perubahan di lokasi yang berbeda. Anda mendapatkan masalah misalnya jika tiga pengembang menambahkan kode di akhir file yang sama - jauh lebih baik jika mereka menambahkan kode di tempat yang berbeda.

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.