Saya tidak melihat masalah di sini.
Anda sudah memiliki ini setiap waktu dengan master
cabang Anda , yang terus berubah saat fitur dikembangkan dan kemudian digabung.
Jadi, dalam contoh konkret Anda, Anda pertama kali membuat feature_xxx_backend
cabang dan mengembangkan perubahan backend. Ketika ini selesai, cabang akan meninjau dan akan digabung menjadi master
setelah review selesai.
Jadi, cukup mulai cabang lain feature_yyy_frontend
,. Anda mungkin ingin bercabang langsung feature_xxx_backend
, sehingga Anda sudah memiliki perubahan-perubahan itu di branc Anda. kemudian cukup mengembangkan fitur frontend asif cabang master
.
Ketika feature_xxx_backend
cabang berubah, misalnya karena ada hal-hal yang muncul selama peninjauan yang perlu ditekankan, lakukan saja perubahan ini dan gabungkan mereka ke dalam feature_yyy_frontend
cabang. Kemudian lanjutkan di cabang frontend.
Setelah peninjauan cabang backend selesai, itu akan digabung menjadi master
. Pada titik ini, akan lebih bijaksana untuk rebase yang feature_yyy_frontend
cabang ke master
, sehingga pengulas hanya perlu meninjau baru perubahan yang cabang ini memberikan kontribusi untuk master
, dan tidak perlu meninjau ulang perubahan yang dibuat untuk backend (yang telah disetujui ).
Ini juga dapat dilakukan ketika Anda memiliki dua, tiga atau lebih cabang tergantung. Jika Anda memiliki dua cabang fitur yang Anda andalkan, sederhana buatlah cabang turunan yang menggabungkan kedua fitur. Cabang dari sana, kembangkan fitur ketiga, gabungkan kedua cabang fitur di sepanjang jalan ketika masing-masing berubah. Ketika kedua fitur selesai dan digabung ke salah satu cabang yang diturunkan, rebase ke itu, atau jika mereka digabung menjadi master, rebase ke master.
Rebasing (seperti yang disarankan di atas) sangat kuat dan membantu menjaga log perubahan yang bersih, membuat ulasan menjadi lebih mudah.