Saya baru saja membuat blog tentang topik ini:
Bagaimana kami terus memperbarui cabang fitur ini? Menggabungkan komit upstream terbaru itu mudah, tetapi Anda ingin menghindari pembuatan komit penggabungan, karena itu tidak akan dihargai ketika didorong ke hulu: Anda kemudian secara efektif melakukan kembali perubahan upstream, dan komit upstream tersebut akan mendapatkan hash baru ( saat mereka mendapatkan orang tua baru). Ini sangat penting, karena komit yang digabungkan tersebut akan tercermin dalam permintaan penarikan GitHub Anda ketika Anda mendorong pembaruan tersebut ke cabang fitur GitHub pribadi Anda (bahkan jika Anda melakukannya setelah Anda mengeluarkan permintaan penarikan.)
Itulah mengapa kita perlu melakukan rebase daripada menggabungkan:
git co devel #devel is ansible's HEAD aka "master" branch
git pull --rebase upstream devel
git co user-non-unique
git rebase devel
Baik opsi rebase dan perintah rebase ke git akan menjaga struktur Anda tetap bersih, dan menghindari menggabungkan komit. Namun perlu diingat bahwa itu adalah komit pertama Anda (dengan mana Anda mengeluarkan permintaan tarik pertama) yang sedang di-rebased, dan yang sekarang memiliki hash komit baru, yang berbeda dari hash asli yang masih ada di cabang repo github jarak jauh Anda .
Sekarang, mendorong pembaruan tersebut ke cabang fitur GitHub pribadi Anda akan gagal di sini, karena kedua cabang berbeda: pohon cabang lokal dan pohon cabang jarak jauh “tidak sinkron”, karena hash komit yang berbeda tersebut. Git akan memberi tahu Anda untuk pertama kali git pull --rebase, lalu mendorong lagi, tetapi ini tidak akan menjadi dorongan maju cepat yang sederhana, karena riwayat Anda telah ditulis ulang. Jangan lakukan itu!
Masalahnya di sini adalah Anda akan kembali mengambil komit pertama yang diubah seperti aslinya, dan itu akan digabungkan di atas cabang lokal Anda. Karena status tidak sinkron, tarikan ini tidak berlaku dengan baik. Anda akan mendapatkan riwayat rusak di mana komit Anda muncul dua kali. Saat Anda memasukkan semua ini ke cabang fitur GitHub, perubahan tersebut akan tercermin pada permintaan penarikan asli, yang akan menjadi sangat, sangat buruk.
AFAIK, sebenarnya tidak ada solusi yang benar-benar bersih untuk ini. Solusi terbaik yang saya temukan adalah memaksa mendorong cabang lokal Anda ke cabang GitHub Anda (sebenarnya memaksa pembaruan non-percepat-maju):
Sesuai git-push (1):
Update the origin repository’s remote branch with local branch, allowing non-fast-forward updates. This can leave unreferenced commits dangling in the origin repository.
Jadi jangan ditarik, paksa saja dorong seperti ini:
git push svg +user-non-unique
atau:
git push svg user-non-unique --force
Ini sebenarnya akan menimpa cabang jarak jauh Anda, dengan semua yang ada di cabang lokal Anda. Komit yang berada di aliran jarak jauh (dan menyebabkan kegagalan) akan tetap ada, tetapi akan menjuntai, yang akhirnya akan dihapus oleh git-gc (1). Bukan masalah besar.
Seperti yang saya katakan, AFAICS adalah solusi terbersih. Kelemahan dari ini, adalah bahwa PR Anda akan diperbarui dengan komitmen terbaru tersebut, yang akan mendapatkan tanggal kemudian, dan dapat muncul tidak sinkron dalam riwayat komentar PR. Bukan masalah besar, tetapi berpotensi membingungkan.