Gitflow: cabang fitur dengan komit tunggal digabung menggunakan maju cepat

Dibuat pada 18 Jan 2013  ·  24Komentar  ·  Sumber: nvie/gitflow

Hai,

git-flow-feature memiliki pemeriksaan eksplisit di sekitar baris 310 di mana ia secara eksplisit menggabungkan maju cepat jika cabang fitur memiliki satu komit di dalamnya.

Saya tidak begitu mengerti alasan untuk ini karena meskipun itu adalah satu komit, itu masih sangat berguna untuk mengetahui itu mengimplementasikan fitur tertentu (yang komit gabungan nyata bertindak sebagai metadata untuk). Tampaknya juga sangat tidak selaras dengan model pengembangan yang diusulkan.

Dengan senang hati menawarkan tambalan untuk menjadikan cabang --no-ff sebagai default.

Terima kasih, Alex J Burke.

Komentar yang paling membantu

Setiap rilis baru, ini adalah hal pertama yang saya periksa :D dan tidak pernah ada :/

Semua 24 komentar

Baru juga menemukan ini sendiri hari ini. Ada masalah yang sudah diangkat dan ditutup untuk ini di sini: https://github.com/nvie/gitflow/issues/100 tapi saya setuju bahwa itu tidak cocok dengan model pengembangan. Mudah-mudahan jika cukup banyak orang yang membuat keributan kita bisa mendapatkan sesuatu yang berubah di sini. (Saya tidak cukup paham untuk membuat perubahan ini secara pribadi.)

Mulai menonton kedua masalah. Saya tidak yakin tentang cara mana yang saya sukai, tetapi pilihan hampir selalu lebih baik daripada tidak ada pilihan sama sekali, bukan?

Bendera diperkenalkan untuk fitur ini di fork git-flow saya (Edisi AVH)
Garpu saya telah menyimpang jauh untuk menjadikannya permintaan tarik yang mudah untuk gitflow nvie,

Lihat changelog untuk informasi lebih lanjut tentang perbaikan bug dan fitur baru yang diterapkan di fork saya.

Sepakat. Setidaknya saya ingin melihat alasan di balik ini.

Setuju - perilakunya tidak jelas, terutama untuk pengguna aliran git baru.

Salah satu alasan untuk memiliki tanda ini adalah alur kerja yang melibatkan proses peninjauan. Saya ingin dapat membubuhi keterangan permintaan penggabungan dengan nomor tiket, bahkan ketika tiket hanya melibatkan satu komit. Ya, komit gabungan tambahan mungkin menambah kebisingan secara umum, tetapi dalam alur kerja seperti ini, penting untuk melacak kembali ke tiket, tanpa harus mengedit pesan komit itu sendiri (karena nomor tiket mungkin tidak ada sejak awal)

Saya sangat buruk dalam berkomentar, tetapi selain dari pengamatan asli saya, saya pikir banyak orang lain telah menyumbangkan kasus penggunaan mereka dan selanjutnya membenarkan utilitas.

Meskipun demikian, hal yang membuat saya bingung adalah di mana harus menyumbangkan tambalan & peningkatan - dengan proyek git-flow asli yang tampaknya tidak terawat dan tidak ada garpu yang diberkati sebagai penerus.

Sebagai catatan, saya percaya garpu 'AVH' menyertakan sesuatu seperti perubahan ini yang berada di belakang bendera (saya percaya dinonaktifkan secara default), tetapi juga memiliki sejumlah perubahan lain yang terakhir saya periksa.

  • terlambat -> besar

+1 untuk setidaknya menambahkan opsi untuk membiarkan pengguna memaksa --no-ff bahkan dengan cabang hanya berisi satu komit :+1:

Saya berjuang hari ini untuk memahami mengapa saya tidak melakukan penggabungan komit dan mengapa tiba-tiba melakukan fast-forward, harus bertanya-tanya apa yang saya lakukan salah dll ... sampai saya menemukan itu adalah gitflow itu sendiri yang melakukan ini tanpa memberi tahu saya tentang hal itu .

Jika saya memulai perbaikan cepat yang hanya membutuhkan satu komit dan saya secara eksplisit tidak ingin komit gabungan dan maju cepat, saya cukup komit langsung di cabang develop . Saya selalu melakukan ini. Jika saya membuat cabang fitur, bahkan untuk satu komit, itu agar cabang itu disimpan, tidak menghilang secara ajaib (karena maju cepat) ketika saya bergabung. Jika saya tidak menginginkan cabang ini, saya akan berkomitmen langsung pada pengembangan dan tidak akan membuat cabang fitur dari awal.

Setidaknya tolong tambahkan flag atau entri konfigurasi untuk membiarkan pengguna memilih perilaku mana yang dia inginkan, alih-alih secara tidak terduga menonaktifkan fast-forward pada beberapa kondisi (dapat dimengerti tetapi sewenang-wenang):wink:

Fork git-flow saya (Edisi AVH) memiliki opsi untuk menyetel flag sebagai default, dengan begitu Anda selalu dapat melakukan --no-ff tanpa mengetiknya. Lihat Wiki untuk informasi lebih lanjut.

Garpu saya telah menyimpang jauh untuk menjadikannya permintaan tarik yang mudah untuk gitflow nvie,

Lihat changelog untuk informasi lebih lanjut tentang perbaikan bug dan fitur baru yang diterapkan di fork saya.

@petervanderdoes Terima kasih.

Sebenarnya untuk bersikap adil saya tidak menggunakan baris perintah gitflow tetapi SourceTree GUI yang tampaknya menggunakan baris perintah gitflow @nvie secara internal. Tidak yakin apakah saya dapat membuat SourceTree menggunakan alternatif git-flow versi/executable dan bagaimana caranya?

Dalam edisi penutup #100, @nvie hanya salah: dia berkomentar bahwa "komit gabungan tambahan tidak menambahkan apa pun dan hanya memperumit pohon cabang tanpa perlu" sedangkan, pada kenyataannya, komentar gabungan adalah satu-satunya catatan yang tersisa untuk generasi mendatang yang menunjukkan fakta bahwa (a) cabang fitur telah dibuat, dan (b) apa nama cabang fitur itu sebenarnya. Tanpa penggabungan eksplisit, tanpa penggabungan maju cepat, riwayat proyek benar-benar kehilangan informasi bahwa komit adalah cabang, dan merupakan fitur, sama sekali!

Akan menyenangkan jika ini ditangani

Saya akan tergoda untuk menghapus opsi --ff eksplisit dari kasus komit tunggal. Kemudian, konfigurasi git merge bawaan merge.ff=false dapat digunakan untuk menyetel --no-ff untuk semua penggabungan (termasuk yang menurut penyelesaian aliran), dengan konfigurasi git default mereplikasi perilaku saat ini.

+1

Paling tidak, alangkah baiknya jika "fitur" ini didokumentasikan.

Kemajuan apa pun dalam hal ini, saya tahu saya mengulangi yang lama tetapi kami tidak melihat cara untuk menggunakan sourcetree untuk menutup fitur dengan itu tidak meneruskan penggabungan dengan cepat. Ada pengaturan di preferensi, tetapi sepertinya tidak menghormatinya

+1

+1

Lihat "Apakah repositori ini mati? #6340"

Ternyata Anda bisa menggunakan git tanpa ini! 😝

Tidak didokumentasikan, dan tidak memberikan opsi penggunaan.
Jenis keputusan ini harus diambil di sisi pengguna. Mengapa tidak memberi tanda centang kecil pada dialog "Finish Release" dan jika Anda benar-benar penggemar berat fitur ini, biarkan dicentang secara default, tetapi karena saya tidak, saya dapat menghapus centangnya, bukan?

Setiap rilis baru, ini adalah hal pertama yang saya periksa :D dan tidak pernah ada :/

Baru saja ditemukan bahwa ada juga kotak centang untuk ini di preferensi. Jadi tidak perlu memeriksanya untuk setiap penggabungan cabang.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat