Git push ditolak setelah cabang fitur rebase

OK, saya pikir ini adalah skenario git sederhana, apa yang saya lewatkan?

Saya memiliki mastercabang dan featurecabang. Saya melakukan beberapa pekerjaan master, beberapa feature, dan kemudian beberapa lagi master. Saya berakhir dengan sesuatu seperti ini (urutan leksikografis menyiratkan urutan komitmen):

A--B--C------F--G  (master)
       \    
        D--E  (feature)

Saya tidak punya masalah untuk git push origin mastermenjaga remote masterdiperbarui, atau dengan git push origin feature(saat aktif feature) untuk menjaga cadangan jarak jauh untuk featurepekerjaan saya . Sampai sekarang, kami baik-baik saja.

Tetapi sekarang saya ingin rebase featuredi atas F--Gkomit pada tuan, jadi saya git checkout featuredan git rebase master. Masih bagus. Sekarang kita punya:

A--B--C------F--G  (master)
                 \
                  D'--E'  (feature)

Masalah: saat saya ingin mem-backup featurecabang rebased baru dengan git push origin feature, dorongan ditolak karena pohon telah berubah karena rebasing. Ini hanya dapat diselesaikan dengan git push --force origin feature.

Saya benci menggunakan --forcetanpa yakin saya membutuhkannya. Jadi, apakah saya membutuhkannya? Apakah rebasing harus menyiratkan bahwa berikutnya pushharus --forcememuaskan?

Cabang fitur ini tidak dibagi dengan pengembang lain, jadi saya tidak punya masalah secara de facto dengan dorongan paksa, saya tidak akan kehilangan data apa pun, pertanyaannya lebih konseptual.

Masalahnya adalah git pushmengasumsikan bahwa cabang jarak jauh dapat diteruskan dengan cepat ke cabang lokal Anda, yaitu bahwa semua perbedaan antara cabang lokal dan cabang jarak jauh adalah di daerah memiliki beberapa komitmen baru pada akhirnya seperti itu:

Z--X--R         <- origin/some-branch (can be fast-forwarded to Y commit)
       \        
        T--Y    <- some-branch

Ketika Anda melakukan git rebasekomit D dan E diterapkan ke basis baru dan komit baru dibuat. Itu berarti setelah rebase Anda memiliki sesuatu seperti itu:

A--B--C------F--G--D'--E'   <- feature-branch
       \  
        D--E                <- origin/feature-branch

Dalam situasi itu cabang terpencil tidak dapat diteruskan ke lokal. Meskipun, secara teoritis cabang lokal dapat digabungkan menjadi remote (jelas Anda tidak membutuhkannya dalam kasus itu), tetapi sebagaigit push melakukan hanya gabungan fast-forward yang dilemparkan dan kesalahannya.

Dan --forceopsi apa yang dilakukan adalah mengabaikan keadaan cabang jarak jauh dan mengaturnya ke komit yang Anda dorong. Jadi git push --force origin feature-branchcukup menimpa origin/feature-branchdengan lokal feature-branch.

Menurut pendapat saya, menghidupkan kembali fitur cabang masterdan mendorong mereka kembali ke repositori jarak jauh adalah OK selama Anda adalah satu-satunya yang bekerja pada cabang itu.

Alih-alih menggunakan -f atau - memaksa pengembang harus menggunakan

--force-with-lease

Mengapa? Karena memeriksa cabang jarak jauh untuk perubahan yang benar-benar ide yang bagus. Mari kita bayangkan bahwa James dan Lisa sedang bekerja di cabang fitur yang sama dan Lisa telah mendorong sebuah komit. James sekarang mengubah cabang lokalnya dan ditolak ketika mencoba mendorong. Tentu saja James berpikir ini karena rebase dan menggunakan --force dan akan menulis ulang semua perubahan Lisa. Jika James menggunakan - force-with-leasing, ia akan menerima peringatan bahwa ada komitmen yang dilakukan oleh orang lain. Saya tidak melihat mengapa ada orang yang menggunakan --force bukannya --force-with-leasing saat mendorong setelah rebase.

Saya akan menggunakan "checkout -b" dan lebih mudah dimengerti.

git checkout myFeature
git rebase master
git push origin --delete myFeature
git push origin myFeature

ketika Anda menghapus, Anda mencegah untuk mendorong cabang keluar yang berisi ID SHA berbeda. Saya hanya menghapus cabang jarak jauh dalam kasus ini.

Salah satu solusi untuk ini adalah melakukan apa yang dilakukan skrip penggabungan msysGit - setelah rebase, gabungkan di kepala lama featuredengan -s ours. Anda berakhir dengan grafik komit:

A--B--C------F--G (master)
       \         \
        \         D'--E' (feature)
         \           /
          \       --
           \    /
            D--E (old-feature)

... dan dorongan Anda feature akan menjadi maju cepat.

Dengan kata lain, Anda dapat melakukan:

git checkout feature
git branch old-feature
git rebase master
git merge -s ours old-feature
git push origin feature

(Tidak diuji, tapi saya pikir itu benar ...)

Mungkin atau mungkin tidak ada kasus bahwa hanya ada satu pengembang di cabang ini, yaitu sekarang (setelah rebase) tidak sejalan dengan asal / fitur.

Karena itu saya menyarankan untuk menggunakan urutan berikut:

git rebase master
git checkout -b feature_branch_2
git push origin feature_branch_2

Ya, cabang baru, ini harus menyelesaikan ini tanpa --force, yang saya pikir umumnya adalah kelemahan utama git.

Cara saya menghindari dorongan gaya adalah dengan membuat cabang baru dan melanjutkan pekerjaan pada cabang baru itu dan setelah beberapa stabilitas, hapus cabang lama yang telah direstrukturisasi:

• Rebasing cabang yang dicek secara lokal
• Bercabang dari cabang rebased ke cabang baru
• Mendorong cabang itu sebagai cabang baru ke jarak jauh. dan menghapus cabang lama di remote

Yang lain telah menjawab pertanyaan Anda. Jika Anda rebase cabang, Anda harus memaksa untuk mendorong cabang itu.

Rebase dan repositori bersama umumnya tidak cocok. Ini adalah penulisan ulang sejarah. Jika orang lain menggunakan cabang itu atau telah bercabang dari cabang itu maka rebase akan sangat tidak menyenangkan.

Secara umum, rebase bekerja dengan baik untuk manajemen cabang lokal. Manajemen cabang jarak jauh bekerja paling baik dengan penggabungan eksplisit (--no-ff).

Kami juga menghindari penggabungan master ke cabang fitur. Alih-alih, kami rebase menjadi master tetapi dengan nama cabang baru (mis. Menambahkan akhiran versi). Ini menghindari masalah rebasing di repositori bersama.

Apa yang salah dengan git merge masterdi featurecabang? Ini akan mempertahankan pekerjaan yang Anda miliki, sambil tetap memisahkannya dari cabang jalur utama.

A--B--C------F--G
       \         \
        D--E------H

Sunting: Ah maaf tidak membaca pernyataan masalah Anda. Anda akan membutuhkan kekuatan saat Anda melakukan a rebase. Semua perintah yang mengubah riwayat akan membutuhkan --forceargumen. Ini adalah cara yang gagal untuk mencegah Anda kehilangan pekerjaan (yang lama Ddan Eakan hilang).

Jadi, Anda melakukan apa git rebaseyang membuat pohon itu terlihat (meskipun sebagian disembunyikan Ddan Etidak lagi dalam cabang bernama):

A--B--C------F--G
       \         \
        D--E      D'--E'

Jadi, ketika mencoba untuk mendorong featurecabang baru Anda (dengan D'dan E'di dalamnya), Anda akan kehilangan Ddan E.

Bagi saya langkah-langkah mudah berikut berfungsi:

1. git checkout myFeature
2. git rebase master
3. git push --force-with-lease
4. git branch -f master HEAD
5. git checkout master
6. git pull

Setelah melakukan semua hal di atas, kita dapat menghapus cabang myFeature juga dengan mengikuti perintah:

git push origin --delete myFeature

Berikut ini berfungsi untuk saya:

git push -f origin branch_name

dan itu tidak menghapus kode saya.

Tetapi, jika Anda ingin menghindari ini maka Anda dapat melakukan hal berikut:

git checkout master
git pull --rebase
git checkout -b new_branch_name

maka Anda dapat memilih semua komitmen Anda ke cabang baru. git cherry-pick COMMIT ID dan kemudian dorong cabang baru Anda.

Karena OP memang memahami masalahnya, hanya mencari solusi yang lebih baik ...

Bagaimana ini sebagai praktik?

• Miliki cabang pengembangan fitur yang sebenarnya (di mana Anda tidak pernah rebase dan memaksa, jadi sesama pengembang fitur Anda tidak membenci Anda). Di sini, secara teratur ambil perubahan itu dari main dengan penggabungan. Sejarah Messier , ya, tapi hidup itu mudah dan tidak ada yang terganggu dalam karyanya.

• Memiliki cabang pengembangan-fitur yang kedua, di mana satu anggota tim pengawas fitur mendorong semua fitur berkomitmen untuk, memang diubah, memang dipaksa. Jadi hampir bersih berdasarkan komit master yang cukup baru. Setelah fitur lengkap, dorong cabang itu di atas master.

Mungkin sudah ada nama pola untuk metode ini.