Ketika bekerja dengan git dalam sebuah tim yang menggunakan cabang fitur, saya sering merasa sulit untuk memahami struktur cabang dalam sejarah.
Contoh:
Katakanlah ada fitur cabang fitur / kopi , dan perbaikan bug berlanjut pada master secara paralel dengan cabang fitur.
Sejarah mungkin terlihat seperti ini:
* merge feature/make-coffee
|\
| * small bugfix
| |
* | fix bug #1234
| |
| * add milk and sugar
| |
* | improve comments
| |
* | fix bug #9434
| |
| * make coffe (without milk or sugar)
| |
* | improve comments
|/
*
Masalah
Pada pandangan pertama, saya merasa sulit untuk mengatakan sisi mana yang merupakan cabang fitur. Saya biasanya perlu menelusuri beberapa komentar di kedua sisi untuk mendapatkan ide yang mana. Ini menjadi lebih rumit jika ada beberapa cabang fitur secara paralel (terutama jika mereka untuk fitur terkait erat), atau jika ada penggabungan di kedua arah antara fitur cabang dan master.
Sebagai kontras, dalam Subversion, ini jauh lebih mudah karena nama cabang adalah bagian dari sejarah - jadi saya bisa langsung tahu bahwa komit awalnya dibuat pada "fitur / kopi".
Git dapat membuat ini lebih mudah dengan memasukkan nama cabang saat ini di metadata komit ketika membuat komit (bersama dengan penulis, tanggal dll.). Namun, git tidak melakukan ini.
Adakah alasan mendasar mengapa ini tidak dilakukan? Atau hanya tidak ada yang menginginkan fitur tersebut? Jika yang terakhir, apakah ada cara lain untuk memahami tujuan cabang sejarah tanpa melihat nama?