Penggabungan fast-forward masuk akal untuk cabang-cabang yang berumur pendek, tetapi dalam sejarah yang lebih kompleks , penggabungan non-fast-forward dapat membuat sejarah lebih mudah untuk dipahami, dan membuatnya lebih mudah untuk mengembalikan sekelompok komitmen.
Peringatan : Non-fast-forwarding juga memiliki efek samping. Harap tinjau https://sandofsky.com/blog/git-workflow.html , hindari 'no-ff' dengan "checkpoint commit" yang melanggar dua bagian atau disalahkan, dan dengan hati-hati mempertimbangkan apakah itu harus menjadi pendekatan default Anda master.
(Dari nvie.com , Vincent Driessen , pos " Model percabangan Git yang sukses ")
Memasukkan fitur selesai pada pengembangan
Fitur yang sudah jadi dapat digabungkan ke dalam cabang pengembangan untuk menambahkannya ke rilis yang akan datang:
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop
The --no-ffbendera menyebabkan penggabungan untuk selalu membuat yang baru komit objek, bahkan jika penggabungan dapat dilakukan dengan cepat-maju. Ini menghindari kehilangan informasi tentang keberadaan historis cabang fitur dan grup bersama-sama semua komit yang bersama-sama menambahkan fitur.
Jakub Narębski juga menyebutkan para configmerge.ff :
Secara default, Git tidak membuat komit gabungan tambahan saat menggabungkan komit yang merupakan turunan dari komit saat ini. Alih-alih, ujung cabang saat ini diteruskan dengan cepat.
Ketika diatur ke false, variabel ini memberitahu Git untuk membuat komit gabungan tambahan dalam kasus seperti itu (setara dengan memberikan --no-ffopsi dari baris perintah).
Ketika diatur ke ' only', hanya penggabungan maju-cepat yang diizinkan (setara dengan memberikan --ff-onlyopsi dari baris perintah).
Maju-cepat adalah default karena:
- cabang berumur pendek sangat mudah dibuat dan digunakan di Git
- cabang berumur pendek sering kali mengisolasi banyak komitmen yang dapat diatur ulang secara bebas di dalam cabang itu
- komitmen tersebut sebenarnya adalah bagian dari cabang utama: setelah direorganisasi, cabang utama diteruskan dengan cepat untuk memasukkannya.
Tetapi jika Anda mengantisipasi alur kerja yang berulang pada satu cabang topik / fitur (yaitu, saya bergabung, maka saya kembali ke cabang fitur ini dan menambahkan beberapa komit), maka akan berguna untuk hanya memasukkan penggabungan di cabang utama, daripada semua komit menengah dari cabang fitur.
Dalam hal ini, Anda bisa mengatur file konfigurasi seperti ini :
[branch "master"]
# This is the list of cmdline options that should be added to git-merge
# when I merge commits into the master branch.
# The option --no-commit instructs git not to commit the merge
# by default. This allows me to do some final adjustment to the commit log
# message before it gets commited. I often use this to add extra info to
# the merge message or rewrite my local branch names in the commit message
# to branch names that are more understandable to the casual reader of the git log.
# Option --no-ff instructs git to always record a merge commit, even if
# the branch being merged into can be fast-forwarded. This is often the
# case when you create a short-lived topic branch which tracks master, do
# some changes on the topic branch and then merge the changes into the
# master which remained unchanged while you were doing your work on the
# topic branch. In this case the master branch can be fast-forwarded (that
# is the tip of the master branch can be updated to point to the tip of
# the topic branch) and this is what git does by default. With --no-ff
# option set, git creates a real merge commit which records the fact that
# another branch was merged. I find this easier to understand and read in
# the log.
mergeoptions = --no-commit --no-ff
OP menambahkan dalam komentar:
Saya melihat beberapa hal dalam fast-forward untuk cabang-cabang [berumur pendek], tetapi menjadikannya tindakan standar berarti bahwa git mengasumsikan Anda ... sering memiliki cabang-cabang [berumur pendek]. Masuk akal?
Jefromi menjawab:
Saya pikir masa hidup cabang sangat bervariasi dari pengguna ke pengguna. Di antara pengguna yang berpengalaman, mungkin ada kecenderungan untuk memiliki cabang yang lebih pendek.
Bagi saya, cabang yang berumur pendek adalah cabang yang saya buat untuk membuat operasi tertentu lebih mudah (rebasing, kemungkinan, atau patching cepat dan pengujian), dan kemudian segera hapus setelah saya selesai.
Itu artinya kemungkinan harus diserap ke dalam cabang topik yang bercabangnya , dan cabang topik akan digabung sebagai satu cabang. Tidak ada yang perlu tahu apa yang saya lakukan secara internal untuk membuat serangkaian komitmen yang mengimplementasikan fitur yang diberikan.
Secara umum, saya menambahkan:
itu benar-benar tergantung pada alur kerja pengembangan Anda :
- jika linier, satu cabang masuk akal.
- Jika Anda perlu mengisolasi fitur dan mengerjakannya untuk jangka waktu yang lama dan berulang kali menggabungkannya, beberapa cabang masuk akal.
Lihat " Kapan Anda harus bercabang? "
Sebenarnya, ketika Anda mempertimbangkan model cabang Mercurial, pada intinya satu cabang per repositori (meskipun Anda dapat membuat kepala anonim, bookmark, dan bahkan cabang bernama )
Lihat "Git dan Mercurial - Bandingkan dan Kontras" .
Mercurial, secara default, menggunakan codelines ringan anonim, yang dalam terminologinya disebut "kepala".
Git menggunakan cabang bernama ringan, dengan pemetaan injeksi untuk memetakan nama-nama cabang dalam repositori jarak jauh ke nama-nama cabang pelacakan jarak jauh.
Git "memaksa" Anda untuk menamai cabang (dengan pengecualian satu cabang yang tidak disebutkan namanya, yang merupakan situasi yang disebut " kepala terpisah "), tapi saya pikir ini bekerja lebih baik dengan alur kerja cabang-berat seperti alur kerja cabang topik, yang berarti banyak cabang dalam paradigma repositori tunggal.
no-ff' dengan "checkpoint commit" yang memecah dua bagian atau disalahkan.