Ketika saya sedang bekerja pada cabang fitur, saya cenderung ingin membersihkan komit di cabang menggunakan rebase interaktif sebelum pekerjaan saya ditinjau dan diintegrasikan di cabang utama.

Selama pengembangan fitur, saya ingin mendorong pekerjaan antara saya ke repositori jarak jauh sebagai ukuran cadangan. Yaitu ketika hard drive saya crash, saya tidak ingin seluruh cabang fitur saya hilang.

Namun, ini mengarah pada fakta bahwa saya sering harus melakukan git push --forceke repositori jarak jauh setelah rebase, suatu tindakan yang umumnya disukai. Atau seperti yang dikatakan halaman github:

Karena mengubah riwayat komit Anda dapat mempersulit orang lain menggunakan repositori, itu dianggap praktik yang buruk untuk mengubah komitmen ketika Anda sudah mendorong ke repositori.

Apakah ada kebijakan (yang diterima secara umum) yang menyelesaikan konflik ini?

Mengapa ini bukan duplikat Apakah git "Peraturan Emas untuk Rebasing" begitu penting?

Pertanyaan saya di sini meminta kebijakan untuk menyelesaikan konflik antara keinginan untuk membackup pekerjaan Anda di repositori jarak jauh dan memoles kembali pekerjaan Anda , sementara pertanyaan lain mencoba menyangkal bahwa ada konflik dan bertanya mengapa beberapa orang berpikir konflik itu ada, dan dengan demikian bertanya mengapa "sangat penting" untuk tidak mendorong kekuatan kembali?

Pertanyaan kunci untuk ditanyakan pada diri sendiri:

• Apakah Anda menjaga cabang jarak jauh Anda setelah bergabung kembali ke master?

Jika Anda menghapus cabang fitur jarak jauh Anda setelah bergabung ke master, Anda sudah kehilangan sejarah. Dengan asumsi Anda squash / rebase cabang sebelum membuat merger / PR Anda, Anda kehilangan sejarah ini. Semua dorongan kekuatan Anda lakukan dalam hal ini memungkinkan Anda untuk menggunakan github sebagai cadangan.

Situasi di mana Anda ingin menyimpan sejarah dan tidak memaksakan push adalah jika cabang jarak jauh Anda bertahan setelah digabung dan tidak hanya ada untuk jangka waktu sementara.

Saya kira Anda bertanya apakah saya akan tetap menggunakan ranting yang tidak direferensikan? Tidak, AFAIC. Namun, push force mungkin secara teoritis mengakibatkan hilangnya komitmen dari pengguna lain yang mendorong ke cabang yang sama

Sepertinya Anda memiliki banyak orang yang mendorong ke cabang itu secara bersamaan. Ini berarti Anda melakukan peduli tentang sejarah di cabang.

Apa yang bisa Anda lakukan sebagai gantinya antara pekerjaan menengah adalah membuat garpu cabang itu. Anda dapat mendorong ini dan kemudian mengubah semua komit Anda menjadi satu komit sebelum penggabungan, jadi ketika Anda menggabungkannya ke dalam cabang-fitur Anda, Anda hanya memiliki 1 komit (dengan sejarah rebased seluruh cabang Anda).

Saya mendaftar beberapa kemungkinan di sini yang terlintas di benak saya.

Selalu rebase di cabang baru

Saat memiliki cabang yang berantakan some-feature, rebase di cabang baru. Misalnya

$ git checkout -b some-feature-rebase
$ git rebase -i master # etc..

Kemudian telah some-feature-rebaseditinjau dan terintegrasi.

Masalah: Kelemahan besar di sini adalah bahwa, sebenarnya, Anda memerlukan cabang baru untuk setiap rebase. (Anda bisa mendapatkan beberapa rebases jika Anda membuat perubahan setelah ulasan kode, misalnya)

Menggunakan git push --force-with-lease

Saya baru belajar tentang git push --force-with-leasealternatifgit push --force , yang

menolak untuk memperbarui cabang kecuali itu adalah keadaan yang kami harapkan; yaitu tidak ada yang memperbarui cabang hulu.

Masalah : Hal ini tampaknya membaik secara langsung pada situasi di mana kami menggunakan hanya --force, tetapi masih memiliki beberapa peringatan, terutama ketika saya melakukan git fetchalih - alih git pull, yang memperbarui cabang-cabang hulu lokal kami, menipu --force-with-leaseberpikir bahwa tidak ada perubahan yang tak terhapuskan dibuat pada remote cabang.