Gitflow: fitur selesai tidak melakukan --no-ff merge

Dibuat pada 14 Feb 2011  ·  12Komentar  ·  Sumber: nvie/gitflow

Saya menghargai alur kerja yang diuraikan dalam artikel "Model percabangan Git yang sukses". Saya terutama menyukai penggunaan objek komit untuk penggabungan fitur.

Saya baru menyadari bahwa git-flow mungkin menggunakan --no-ff merge, dan di lain waktu mungkin tidak. Kenapa ini? Apakah dengan desain?

Apakah saya harus melakukan fork git-flow agar berfungsi dengan --no-ff penggabungan fitur, atau apakah ada cara untuk mengonfigurasi ini?

Terima kasih,
skot

Komentar yang paling membantu

Hai Vincent,

Saya pasti dapat memahami pemikiran di balik desain itu, tetapi saya pikir pilihan apakah komit gabungan harus dibuat harus ditentukan oleh apakah pengguna memilih untuk memulai cabang fitur. Terkadang saya mungkin melakukan perubahan cepat pada cabang pengembangan, tetapi saya akan memilih untuk membuat cabang fitur _khusus_ karena saya ingin melihat komit gabungan. Saya mungkin hanya membuat satu komit ke cabang fitur, tetapi mungkin bukan itu yang menurut saya sebagai pengguna tidak cukup signifikan untuk menjamin pengabaian komit gabungan eksplisit.

Pada akhirnya, saya pikir pilihannya harus milik pengguna, dan saya pikir pengguna mengekspresikan pilihan yang berbeda dengan menggunakan cabang fitur versus membuat komitmen cepat ke cabang pengembangan.

Setiap petunjuk di mana saya bisa pergi di basis kode untuk membuat perubahan ini dalam bentuk pribadi akan sangat dihargai!

Terima kasih banyak untuk alat yang hebat!
-Scott

Semua 12 komentar

Hai Scott,

Secara desain, git-flow menggunakan opsi --no-ff saat menggabungkan untuk mencatat bahwa komit milik bersama secara historis. Namun, ketika cabang fitur hanya berisi satu komit, komit gabungan tambahan tidak menambahkan apa pun dan hanya memperumit pohon cabang tanpa perlu. Jadi untuk cabang komit tunggal, penggabungan maju cepat dibuat seolah-olah komit dilakukan pada develop secara langsung.

Bersulang,
Vincent

Hai Vincent,

Saya pasti dapat memahami pemikiran di balik desain itu, tetapi saya pikir pilihan apakah komit gabungan harus dibuat harus ditentukan oleh apakah pengguna memilih untuk memulai cabang fitur. Terkadang saya mungkin melakukan perubahan cepat pada cabang pengembangan, tetapi saya akan memilih untuk membuat cabang fitur _khusus_ karena saya ingin melihat komit gabungan. Saya mungkin hanya membuat satu komit ke cabang fitur, tetapi mungkin bukan itu yang menurut saya sebagai pengguna tidak cukup signifikan untuk menjamin pengabaian komit gabungan eksplisit.

Pada akhirnya, saya pikir pilihannya harus milik pengguna, dan saya pikir pengguna mengekspresikan pilihan yang berbeda dengan menggunakan cabang fitur versus membuat komitmen cepat ke cabang pengembangan.

Setiap petunjuk di mana saya bisa pergi di basis kode untuk membuat perubahan ini dalam bentuk pribadi akan sangat dihargai!

Terima kasih banyak untuk alat yang hebat!
-Scott

Di sinilah keajaiban terjadi: https://github.com/nvie/gitflow/blob/develop/git-flow-feature#L310

Saya tidak akan menambahkan opsi untuk membuat cabang fitur komit tunggal bergabung secara eksplisit dengan --no-ff, karena saya masih tidak berpikir itu menambahkan apa pun (selain kompleksitas tambahan dari flag baris perintah lain), tetapi jangan ragu untuk menjadikannya perubahan pribadi jika Anda bersikeras.

Bersulang,
Vincent

Terima kasih, Vincent! Saya menghargai penunjuknya!

Terbaik,
skot

Jika saya dapat menambahkan 5 sen saya,

Saya sangat menginginkan opsi untuk memiliki komit gabungan bahkan ketika menyelesaikan satu fitur komit.

Dalam cara saya menggunakan git flow, fitur saya menyertakan nomor tiket yang sedang saya kerjakan dalam namanya. Ketika saya menyelesaikan sebuah fitur, saya sangat ingin melihat komit gabungan yang menentukan nama fitur (termasuk nomor tiket).

Ini berguna untuk menelusuri kembali setiap komit ke tiket yang sebenarnya tanpa harus menulis nomor tiket di setiap pesan komit.

@DonGiulio Tidak tahu apakah Anda sudah memeriksanya, tapi saya cukup yakin edisi AVH melakukan apa yang Anda inginkan.

Terima kasih, saya tidak tahu itu, saya akan memeriksanya.

Saya juga memilih untuk hanya menambahkan opsi untuk memiliki perilaku tanpa komit tunggal. Alangkah baiknya jika Anda dapat mempertimbangkan kembali hal ini.

(Saya tidak yakin apa lagi yang ada di edisi AVH).

@nvie Bolehkah saya sebagai mengapa?! "_Saya masih tidak berpikir itu menambahkan apa-apa_"
Jujur saya pikir ketika sekelompok orang percaya itu tidak add sesuatu dan beberapa berpikir itu kita

Jika pengguna mengalami kesulitan membuat fitur dan memilih untuk melakukan satu komit di dalamnya, ini berarti dia membutuhkannya seperti itu (katakanlah demi menjaga sejarah visual) dan tidak mendorong ke pengembangan secara langsung . Saya akan berdebat sebaliknya dan mengabaikan jalur yang diambil pengguna tidak masuk akal.

Apakah Anda tertarik untuk menguraikannya? Kita harus setuju bahwa, tidak semua orang mungkin ingin melakukan pekerjaan yang solid karena perubahan kecil seperti itu.

@Mehradzie Belum ada komitmen pada repo ini dalam 5 tahun. Edisi AVH telah menjadi pilihan utama untuk beberapa waktu sekarang dan cukup stabil. Saya tidak akan menahan napas untuk tanggapan di sini, apalagi perubahan kode.

@jawshooah sejujurnya saya bahkan tidak memeriksa nama repo ketika saya berakhir di sini karena saya mengejar masalah yang sama di SourceTree.
Apakah gitflow yang digunakan SourceTree untuk melakukan alirannya? Saya agak bingung sekarang :D
Dan jika demikian, dapatkah saya memotong dan mengubah seperti yang Anda sarankan untuk menggunakan beberapa pekerjaan repo lain sebagai gantinya!

@Mehradzie AFAIK SourceTree menyematkan versi yang sedikit dimodifikasi dari versi nvie asli. Ada permintaan luar biasa bagi mereka untuk memperbarui ke versi AVH (lihat di sini dan di sini ).

Apakah halaman ini membantu?
0 / 5 - 0 peringkat