Kapan waktu yang tepat untuk menghapus cabang fitur git?

90

Saya tidak ingin berakhir dengan 82 cabang fitur yang berkeliaran , jadi saya bertanya-tanya apa potensi kekurangannya hanya dengan menghapus cabang fitur segera setelah saya menggabungkannya menjadi master.

Alur Kerja:

git co -b feat-xyz
hack hack
git ci
hack some more
git ci
git co master
git merge feat-xyz
smoke test
git br -d feat-xyz

Ada masalah di sini?

git version-control branch

— bstpierre.dll
sumber

1

Saya akan mengatakan tidak ada masalah karena jika Anda benar-benar membutuhkannya, Anda selalu dapat menghidupkan kembali cabang yang dihapus nanti.

— slebetman

@slebetman Sejauh yang saya tahu cabang yang dihapus tidak dapat dihidupkan kembali. Namun jika cabang tersebut telah digabungkan sepenuhnya menjadi master sebelum menghapusnya, seharusnya tidak diperlukan lagi cabang tersebut.

— Simeon

1

@Simeon Ya, Anda bisa. Git tidak pernah menghapus komit, jadi ketika Anda menghapus cabang Anda, Anda hanya perlu menghapus namanya. Untuk menghidupkan kembali cabang yang dihapus, Anda hanya perlu mengingat hal terakhir yang Anda lakukan untuk cabang itu dan Anda dapat mencarinya git reflog. Kemudian

— periksa

@slebetman yang hanya akan berlaku jika cabang tersebut akhirnya digabungkan. jika komitmen ditinggalkan, mereka pada akhirnya akan menjadi tidak terjangkau dan akan dikenakan pengumpulan sampah setelah jangka waktu tertentu. bahkan entri dalam reflog pada akhirnya akan dihapus, Anda memiliki sekitar 90 hari secara default.

— goldenratio

@ Goldenratio: Ada referensi untuk itu?

— slebetman

63

Hapus setelah penggabungan adalah cara yang biasa. Inilah sebabnya mengapa git branch -d yourbranchnamememeriksa untuk memastikan bahwa cabang telah digabungkan sepenuhnya sebelum akan dihapus.

Ada beberapa alasan yang dapat saya pikirkan untuk mempertahankan sebuah cabang: Anda mungkin ingin menyimpannya jika ada bug yang muncul kembali setelah mencapai produksi, atau Anda mungkin menginginkan catatan historis.

Dalam kedua kasus tersebut, Anda memiliki opsi untuk menandai kepala cabang sebelum Anda menghapusnya. Sebuah tag seperti cabang yang merupakan penunjuk ke komit, kecuali untuk beberapa perbedaan kecil: 1) porcelain biasanya tidak menampilkan tag dalam perintah eksplorasi seperti git show-branch atau tab-auto complete di checkout, 2) memeriksa satu menempatkan Anda dalam KEPALA (non-ref) terpisah) Anda dapat meninggalkan pesan " penandaan ", yang menyebabkan tag disimpan sebagai objek di penyimpanan objek seperti komit.

Dengan cara ini Anda menyimpan riwayat, dan jika Anda memang perlu memperbaiki bug, saya sarankan untuk membuat cabang baru dari master untuk memperbaikinya.

— masonk
sumber

1

Memeriksa tag out tidak mengatur HEAD, tetapi tidak secara otomatis membuat cabang. HEAD pada komit tanpa cabang adalah yang membuatnya terlepas.

— Binarian

1

Anda benar, ini menetapkan HEAD ke id komit daripada ref. Bagian OP saya itu salah. Saya harus memperbaruinya.

— masonk

97

Saya menghapus setelah penggabungan, tetapi saya selalu melakukan a git merge --no-ff, untuk menghindari penerusan cepat sehingga riwayat cabang terlihat pada grafik. Saya suka memiliki riwayat di mana cabang fitur berangkat dari cabang pengembangan dan di mana ia bergabung kembali:

Menggabungkan dengan atau tanpa fast-forward

Ini diambil dari Model percabangan Git yang sukses oleh Vincent Driessen, alur kerja yang sangat bagus untuk digunakan dengan git yang saya terapkan untuk sebagian besar proyek saya.

— lkraider
sumber

Ini adalah cara bagus lainnya untuk mempertahankan riwayat, karena Anda dapat memilih komit yang dapat dijangkau dari fitur tetapi tidak dari master: rev ^ 1..rev ^ 2. Sisi negatifnya adalah ia mengacaukan setiap rebasing yang mungkin ingin Anda lakukan dari cabang master Anda (misalnya, jika Anda ingin mempertahankan master rebased ke remote upstream, yang sangat umum).

— masonk

1

Saya tidak punya masalah itu. Tim kami melakukan sinkronisasi melalui github, dan saya biasanya tidak perlu melakukan rebase, tetapi menurut saya ini bukan sisi negatifnya. Bahkan jika Anda mendasarkan kembali pengembangan dan cabang fitur Anda, percabangan tetap terlihat pada grafik, dan yang penting adalah apa yang ada di cabang fitur relatif terhadap pengembangan, bukan komit di mana Anda awalnya keluar saat Anda membuat cabang itu.

— lkraider

@Ikraider, terima kasih atas pengingatnya. Saya melihat artikel itu ketika saya pertama kali mempelajari git, itu lebih masuk akal bagi saya sekarang. Saya me-rebase cabang fitur saya, tetapi saya merge --no-ffkembali ke master karena seperti yang Anda katakan, Anda dapat melihat sejarah.

— bstpierre

7

Saya dapat memikirkan dua alasan mengapa Anda mungkin ingin menyimpan cabang fitur sebentar:

Ada kemungkinan itu akan ditendang kembali kepada Anda untuk lebih banyak pekerjaan di hulu.
Pengembang lain mungkin menginginkan fitur itu tanpa menginginkan yang lainnya di master.

Dalam praktiknya, sebagian besar waktu menghapus setelah penggabungan baik-baik saja.

— Karl Bielefeldt
sumber

6

Alur kerja tipikal akan

 // Create new branch
 $ git checkout -b myfeature
 // and then do some changes and commit them

 // Switch to master branch
 $ git checkout master

 // Merge myfeature to master. --no-ff will always keep branch information.
 $ git merge --no-ff myfeature

 // Delete myfeature branch
 $ git branch -d myfeature

 // Push the changes
 $ git push origin master

— Fizer Khan
sumber

1

saya pikir itu adalah alur kerja yang khas (menghapus setelah penggabungan)

EDIT Jadi, daripada menggabungkan, setidaknya untuk cabang berumur pendek, saya pikir idenya adalah untuk mendasarkannya kembali ke master. kemudian Anda berakhir dengan riwayat perubahan linier, dan seluruh cabang menjadi bagian dari batang utama. dalam hal ini Anda memiliki semua perubahan di sana sehingga Anda jelas tidak memerlukan salinannya.

— kedua
sumber

Jadi tidak ada gunanya menyimpan cabang di sekitar, bukan?

— bstpierre

1

Saya sangat menyarankan untuk menghindari "rebase". Rebasing umumnya berbahaya, hanya berguna dalam beberapa kasus.

— Dietrich Epp

9

Rebasing adalah alur kerja yang masuk akal untuk cabang pribadi lokal Anda. Sangat umum untuk tetap sinkron dengan pekerjaan upstream dengan melakukan rebasing misalnya ("rebasing down "). Jauh lebih jarang, dan biasanya berbahaya, untuk melakukan rebase up *. jawaban kedua tidak terlalu masuk akal, karena baik Anda melakukan rebasing atau menggabungkan perubahan upstream, Anda masih harus mendorong hal itu "ke atas". Bahkan di cabang lokal Anda, Anda harus menggabungkan fitur Anda untuk menguasai di beberapa titik. Keuntungan dari tetap berdasarkan pada fitur Anda adalah bahwa penggabungan ini menjadi maju cepat.

— masonk

1

Ada sesuatu yang harus diperhatikan dengan cabang rebasing, yang baru-baru ini menggigit saya. Sudah jelas sekarang, tapi aku pergi selama berbulan-bulan di cabang berumur panjang, selalu menilai semuanya melawan tuan. Itu berakhir dengan sekitar 600 komit yang bagus dan terperinci, tetapi master telah banyak kali direfraktorisasi dan sepenuhnya diubah. Dengan mengubah peringkat seluruh cabang setiap kali, saya memotong komitmen lama dari koneksi mereka menjadi komitmen master yang masuk akal bagi mereka. Sekarang saya lebih suka menggabungkan master saat dibutuhkan. Saya hanya akan melakukan rebase jika sejarah cabang sama sekali tidak terpengaruh.

— Gary Fixler