Strategi untuk tinjauan kode sebelum bergabung menjadi master dari cabang fitur

Saya dan tim saya menggunakan cabang fitur (dengan git). Saya bertanya-tanya mana yang merupakan strategi terbaik untuk tinjauan kode sebelum bergabung menjadi master.

1. Saya checkout cabang baru dari master, sebut saja fb_ # 1
2. Saya komit beberapa kali dan kemudian ingin menggabungkannya kembali ke master
3. Sebelum saya menggabungkan seseorang seharusnya membuat tinjauan kode

Sekarang ada 2 kemungkinan:

1

1. Saya menggabungkan master ke fb_ # 1 ( bukan fb_ # 1 untuk dikuasai) untuk menjadikannya sebagai yang terbaru.
2. Rekan tim meninjau perubahan antara kepala master dan kepala fb_ # 1
3. Jika fb_ # 1 tidak masalah, kami menggabungkan fb_ # 1 untuk dikuasai
4. Pro: tidak ada kode usang dalam ulasan
5. Cons: jika orang lain menggabungkan sesuatu di antara "1." dan "2." perubahannya muncul di ulasan, meskipun itu milik ulasan lain.

Ke-2

1. Rekan satu tim mengulas perubahan antara titik checkout (git merge-base master fb_ # 1) dan head fb_ # 1
2. Pro: kami melihat apa yang diubah selama bekerja di cabang fitur
3. Cons: beberapa kode usang mungkin muncul di ulasan.

Menurut Anda cara mana yang lebih baik dan mengapa ? Mungkin ada pendekatan lain yang lebih cocok?

Ada variasi opsi 1 Anda:

1. gabungkan master ke fb_ # 1 (bukan fb_ # 1 untuk dikuasai) untuk menjadikannya sebagai yang terbaru.
2. Rekan tim meninjau perubahan antara master pada titik yang Anda gabungkan dan kepala fb_ # 1
3. Jika fb_ # 1 tidak masalah, kami menggabungkan fb_ # 1 untuk dikuasai
4. periksa cepat apakah penggabungannya ok

misalnya.

... ma -- ... -- mm -- ... -- mf  <- master
      \            \         /
       f1 ... fn -- fm -----      <-- fb_#1

dimana:

• ma adalah leluhur dari master dan fb_ # 1.
• fn adalah perubahan terakhir di cabang Anda
• mm adalah komit yang merupakan master / HEAD pada saat Anda bergabung ke cabang Anda (memberi fm ).

Jadi, Anda membandingkan mm dan fm di ulasan awal Anda, dan kemudian dengan cepat memeriksa setelah menggabungkan kembali mf untuk memastikan tidak ada perubahan signifikan pada master selama langkah 1-3. Ini tampaknya memiliki semua pro dan tidak ada kontra untuk tinjauan awal.

Ini mengasumsikan review cepat dibandingkan dengan frekuensi normal dari perubahan yang didorong ke master, jadi fm -> mf akan sering menjadi fast-forward.

Jika bukan itu masalahnya, untuk alasan apa pun, kontra hanya akan berpindah dari tinjauan awal ke ulasan pasca-penggabungan, dan mungkin lebih mudah untuk hanya menggabungkan langsung ke master dan melakukan satu ulasan di sana.

Ke-3

• Anda rebase cabang pada master untuk membuatnya terbaru dan menjaga perubahan terpisah.

  Ini menciptakan sejarah baru cabang. Ini akan menjadi revisi baru dengan ID baru yang akan memiliki konten yang sama, tetapi akan berasal dari master terbaru dan tidak akan ditautkan ke revisi lama. Revisi lama masih dapat diakses di "reflog" jika Anda perlu merujuk mereka misalnya karena Anda menemukan Anda membuat kesalahan dalam penyelesaian konflik. Selain itu mereka tidak berharga. Git secara default memangkas reflog setelah 3 bulan dan membuang revisi lama.

• Anda menggunakan rebase interaktif ( git rebase -idan git commit --amend) untuk menyusun ulang, mengedit, dan membersihkan perubahan sehingga masing-masing melakukan perubahan yang ditutup secara logis.

  Ini lagi-lagi menciptakan sejarah baru, kali ini dengan manfaat tambahan yang dapat Anda ubah strukturnya menjadi paling masuk akal selama peninjauan.

• Pro:

  • tidak ada kode usang dalam ulasan
  • kita melihat dengan tepat apa yang diubah selama bekerja di cabang fitur
• Cons:
  • sedikit lebih banyak pekerjaan
  • Anda harus berhati-hati untuk tidak melakukan rebase pada apa pun yang sudah digabung atau yang Anda bagikan dan penerima tidak mengharapkannya untuk diulang.

Biasanya pekerjaan tambahan berarti Anda meninjau kode secara menyeluruh terlebih dahulu dan itu akan menangkap banyak masalah juga.

Inilah yang dilakukan Linux dan Git. Dan bukan hal yang aneh melihat serangkaian 20 hingga 25 tambalan diajukan untuk ditinjau dan ditulis ulang beberapa kali dalam proyek-proyek tersebut.

Sebenarnya Linux melakukannya sejak awal dalam proyek ketika versi kontrol pilihan mereka adalah tarball dan patch. Ketika bertahun-tahun kemudian Linus mulai membuat git, itu adalah alasan utama untuk mengimplementasikan rebaseperintah dan itu varian interaktif. Juga karena itu git memiliki gagasan terpisah tentang pengarang dan pengalih . Penulis adalah yang pertama kali membuat revisi dan komuter adalah yang terakhir menyentuhnya. Karena di Linux dan Git tambalan masih dikirimkan melalui email, keduanya hampir tidak pernah orang yang sama.

Sebenarnya ada kepemilikan ketiga — dan kemungkinan besar banyak yang lain, karena GIT lebih merupakan implementasi kerangka SCM daripada implementasi metodologi SCM. Kemungkinan ketiga ini didasarkan pada rebase.

The rebaseGIT subcommand mengambil serangkaian komit (biasanya dari titik Anda bercabang ke ujung cabang topik Anda topic) dan replay mereka di tempat lain (biasanya di ujung cabang integrasi Anda, misalnya master). rebaseSub - perintah tersebut menghasilkan komitmen baru, yang memberikan peluang untuk menyusun ulang komitmen dalam bentuk yang lebih mudah ditinjau. Ini menghasilkan serangkaian komit baru, mirip dengan apa yang topicdulu tetapi muncul berakar di bagian atas cabang integrasi. Cabang baru ini masih dipanggil topicoleh GIT, sehingga referensi lama dibuang. Secara tidak resmi saya memberi label topic-0kondisi asli cabang Anda topic-1dan seterusnya, serta berbagai refactoringnya.

Ini saran saya untuk topiccabang Anda :

1. (Langkah Opsional) Anda secara interaktif rebase cabang topik Anda topicpada titik percabangan (lihat --fixuppilihan untuk commitdan -idan --autosquashpilihan pada rebase), yang memberikan Anda kesempatan untuk menulis ulang komit Anda dengan cara yang lebih mudah untuk ulasan. Ini menghasilkan cabang topic-1.

2. Anda rebase cabang topik Anda di bagian atas cabang integrasi Anda, mirip dengan melakukan penggabungan, tetapi sejarah “tidak mencemari” dengan penggabungan yang hanya merupakan artefak rekayasa perangkat lunak. Ini menghasilkan cabang topic-2.

3. Kirim topic-2ke teman satu tim yang mengulasnya di ujung master.

4. Jika topic-2tidak apa-apa maka gabungkan menjadi master.

CATATAN Cabang-cabang — di mana cabang mengacu pada pohon komit — semua akan disebut sama oleh GIT, dengan demikian, pada akhir proses, hanya cabang yang topic-2memiliki nama dalam GIT.

Pro:

• Tidak ada kode usang dalam ulasan.
• Tidak ada ulasan "penggabungan asing" palsu (fenomena yang Anda gambarkan pada tanggal 1).
• Peluang untuk menulis ulang komit dengan cara yang bersih.

Cons:

• Alih-alih satu cabang topic-0, ada tiga cabang artefak topic-0, topic-1dan topic-2yang dibuat di pohon komit. (Meskipun setiap saat, hanya satu dari mereka yang memiliki nama di GIT.)

Dalam skenario 1 Anda «jika seseorang menggabungkan sesuatu di antara" 1. " dan "2." »mengacu pada rentang waktu antara penciptaan titik cabang dan waktu ketika Anda memutuskan untuk bergabung. Dalam skenario ini «jika seseorang menggabungkan sesuatu di antara" 1. " dan "2." »mengacu pada rentang waktu antara rebase dan penggabungan, yang biasanya sangat singkat. Jadi dalam skenario yang saya sediakan, Anda dapat «mengunci» mastercabang untuk saat penggabungan tanpa mengganggu alur kerja Anda secara signifikan, sementara itu tidak praktis dalam skenario 1.

Jika Anda melakukan tinjauan kode sistematis, mungkin ide yang baik untuk mengatur ulang komit dengan cara yang memadai (langkah opsional).

Mengelola artefak cabang perantara hanya menghadirkan kesulitan jika Anda membaginya di antara repositori.