Kapan menghapus cabang di Git?


284

Misalkan kita memiliki aplikasi yang stabil.

Besok, seseorang melaporkan bug besar yang kami putuskan untuk diperbaiki segera. Jadi kami membuat cabang untuk perbaikan terbaru itu dari "master", kami beri nama "2011_Hotfix", dan kami dorong agar semua pengembang dapat berkolaborasi untuk memperbaikinya.

Kami memperbaiki bug, dan menggabungkan "2011_Hotfix" menjadi "master" serta ke cabang pengembangan saat ini. Dan dorong "tuan."

Apa yang kita lakukan dengan "2011_Hotfix" sekarang? Haruskah itu hanya duduk di sana sebagai cabang selamanya sampai akhir zaman atau kita sekarang harus menghapusnya, karena telah melayani tujuannya? Rasanya najis meninggalkan cabang di mana-mana, karena daftar cabang kemungkinan akan menjadi sangat panjang, yang sebagian besar bahkan tidak diperlukan lagi.

Jika itu harus dihapus, apa yang akan terjadi dengan sejarahnya? Apakah itu akan dipertahankan, meskipun cabang yang sebenarnya tidak lagi tersedia? Juga, bagaimana saya menghapus cabang jarak jauh?


33
Seringkali membantu untuk menganggap cabang sebagai gagasan. Aturan praktis yang cukup baik adalah jika Anda selesai mengerjakan ide yang diwakili cabang - termasuk pengujian yang dilakukan dan menggabungkan perubahan tersebut (menggabungkannya menjadi master) - Anda selesai dengan cabang itu sendiri.
Cascabel

3
Apa yang ingin saya ketahui: jika perbaikan terbaru jarak jauh sedang dihapus, apakah akan dihapus secara lokal untuk semua pengembang yang berkolaborasi? Jika tidak; bagaimana mencapai ini? Saya pikir satu orang memigrasikan perbaikan terbaru untuk dikuasai, tetapi setelah itu harus dibersihkan untuk semua kolaborator juga, untuk mencegah mereka menambahkan komit ke cabang itu.
rolandow

1
Anda tidak dapat memengaruhi repositori lokal komputer rekan kerja Anda. Anda juga harus memberitahunya untuk menghapus cabang secara lokal atau Anda juga dapat menegakkan sisi server ini dengan git hooks / keamanan cabang untuk mencegah dorongan dari cabang Anda yang ingin Anda hapus
srz2

Jawaban:


183

Anda dapat menghapus cabang dengan aman git branch -d yourbranch. Jika itu berisi perubahan yang tidak dihapus (mis., Anda akan kehilangan komit dengan menghapus cabang), git akan memberi tahu Anda dan tidak akan menghapusnya.

Jadi, menghapus cabang gabungan adalah murah dan tidak akan membuat Anda kehilangan riwayat apa pun.

Untuk menghapus cabang jarak jauh, gunakan git push origin :mybranch, dengan anggapan nama jarak jauh Anda adalah asal dan cabang jarak jauh yang ingin Anda hapus bernama mybranch.


35
"menghapus cabang yang digabungkan itu murah", begitu juga menyimpannya. Tidak ada performa yang signifikan dalam hal waktu atau penggunaan ruang git, jika Anda tetap menggunakannya. Yang mengatakan, saya akan menghapus cabang karena semua komit sudah ada dalam sejarah master, jadi itu membuat semuanya jauh lebih bersih.
MatrixFrog

22
Salah satu alasan saya ingin menghapus cabang adalah: Kami melakukan banyak perubahan di cabang (sebenarnya, semua perubahan) sehingga pada akhirnya Anda mendapatkan daftar panjang saat menggunakan perintah 'git branch'. Untuk ikhtisar, saya ingin mempersingkat daftar itu. Jadi cabang lama akan dihapus. Rilis reale ditandai, jadi tidak dalam disussion ini untuk saya.
michel.iamit

7
Sementara saya setuju dengan menghapus cabang yang telah digabung, jika Anda ingin melihat daftar cabang yang belum digabung ke cabang Anda saat ini, Anda dapat menggunakan: git branch --no-merger
lsklyut

51
@ MatrixFrog Sangat murah untuk menjaga sekitar dalam hal git, namun dalam biaya manusia bisa menjadi mahal. Saya baru saja memasuki proyek dengan sekitar 40 cabang, semuanya dengan nama cabang numerik. Saya tidak tahu apa itu apa, dan hampir setiap cabang itu basi. Overhead mencari melalui cabang-cabang itu dan mencari tahu apa yang melelahkan dan membutuhkan waktu. Jadi ya, secara teknis itu murah, tetapi sebenarnya tidak. Saya suka menjaga bentuk git repo ship saya. Jika tidak dalam dev aktif dan telah digabungkan, hapuslah. Tapi itu hanya MO saya dan saya menghargai bahwa orang lain mungkin melakukan sesuatu yang berbeda.
dudewad

1
Apa perintah untuk membuat --no-mergeddefault? Saya mencoba git config --global --add branch.noMerged truedan ditambahkan tetapi tidak ada bedanya.
Craig Silver

55

Yang perlu Anda lakukan adalah menandai apa pun yang Anda lepaskan. Pertahankan cabang saat Anda aktif berkembang.

Hapus cabang lama dengan

git branch -d branch_name

Hapus dari server dengan

git push origin --delete branch_name

atau sintaksis lama

git push origin :branch_name

yang bertuliskan "push nothing to branch_name at origin".

Yang mengatakan, selama DAG (grafik asiklik diarahkan) dapat menunjukkan itu, komit akan ada dalam sejarah.

Google "git-flow" dan itu mungkin memberikan lebih banyak wawasan tentang manajemen rilis, percabangan dan penandaan.


31

Karena pertanyaan memiliki tag "github", saya juga akan menambahkan ini: khususnya di Github , jika Anda menarik-meminta cabang dan digabung (baik melalui UI atau dengan menggabungkan cabang permintaan tarik), Anda tidak akan kehilangan data permintaan tarik (termasuk komentar), bahkan jika Anda menghapus cabang .

Konsekuensi dari ini: Jika Anda memasukkan permintaan tarikan sebagai bagian dari alur kerja Anda (yang berpadu manis dengan ulasan kode), Anda dapat menghapus cabang dengan aman segera setelah mereka digabungkan. Ini sangat biasa sehingga baru-baru ini Github menambahkan fitur (manis) yang muncul tombol "hapus cabang" tepat setelah Anda menggabungkan permintaan tarik.

Tetapi perlu diperhatikan bahwa masing-masing kelompok harus mengadopsi alur kerja yang paling cocok (dan itu mungkin atau mungkin tidak mengarah pada penghapusan cabang-cabang seperti itu). Tim kerja saya saat ini, misalnya, memangkas semua cabang yang tidak terkait dengan master atau penempatan (misalnya, produksi, pementasan, dll.) Segera setelah permintaan tarik mereka digabung, dan kami masih memiliki pelacakan penuh tentang bagaimana komitmen terkait dibentuk setiap peningkatan bertahap dari setiap produk.

Tentu saja tidak ada manajemen riwayat (menarik permintaan atau sebaliknya) menggantikan penandaan versi yang tepat (yang Anda lebih baik diotomatisasi dengan alat / skrip yang sama yang menyebarkan / mengemas suatu versi), sehingga Anda selalu dapat dengan cepat beralih ke apa pun yang kebetulan dilakukan oleh pengguna Anda. pada saat tertentu. Pemberian tag juga merupakan kunci untuk menyelesaikan masalah awal Anda: jika Anda menetapkan bahwa cabang mana pun yang digabungkan dengan cabang "pekerjaan" dapat dan harus dihapus, dan bahwa setiap cabang yang digabungkan dengan tag versi, "produksi", dll. Tidak boleh , Anda akan selalu memiliki perbaikan terbaru hidup sampai mereka diintegrasikan dalam versi masa depan.


2
Terima kasih telah menjelaskan mengapa Github menunjukkan saya tombol "Hapus cabang".
Todd Owen

Kami menggunakan sourcetree dan memberikan opsi untuk menjaga cabang hotfix lokal dan cabang hotfix jarak jauh tetap terbuka. Saya pikir menutup cabang hotfix berarti menghapusnya dan Anda tidak dapat menggunakannya kembali. mis. Kita perlu mendorong perbaikan panas setiap hari selama 5 hari ke depan. Lalu kita tutup. Tapi katakanlah pada hari ke-6, kita perlu perbaikan terbaru. Apakah kita membuat cabang perbaikan terbaru baru?
Bahaya14

Itu yang biasanya dilakukan orang. Jika penamaan mereka secara individu tidak layak, Anda dapat menamainya berdasarkan hari itu, atau pada referensi untuk sistem tiket yang mengelola mereka (jika ada). Tentu saja, alur kerja git seharusnya diterapkan berdasarkan "apa pun yang paling berhasil untuk tim Anda", jadi jangan khawatir jika Anda memutuskan untuk bekerja secara berbeda.
chesterbr

7

Saya ingin menambahkan bahwa kerugian dari menghapus cabang adalah Anda akan memutuskan tautan apa pun ke cabang-cabang di GitHub (pertanyaan ini ditandai dengan github). Anda akan mendapatkan 404 Not Foundkesalahan untuk tautan tersebut. Inilah sebabnya saya mengubah tautan untuk mengarahkan ke komit atau tag setelah saya menghapus cabang di GitHub.

Karena beberapa tautan tidak dapat diubah, seperti dalam email, saya sekarang menghindari hyperlink ke cabang GitHub sepenuhnya dan tautan ke komit atau tag sejak hari pertama.

Saya lebih suka menghapus cabang setelah digabung. Ini mencegah kekacauan visual dari daftar cabang yang panjang di repositori Anda. Cabang-cabang ini juga disebarkan ke semua garpu repositori.

Pertama saya menghapus cabang lokal saya. Ini mencegahnya agar tidak sengaja didorong kemudian.

git branch -d branchName

Kemudian saya menghapus cabang pelacakan jarak jauh

git branch -dr remoteName\branchName

Lalu saya menghapus cabang di GitHub. Saya menggunakan antarmuka web, tetapi perintah yang setara di bawah ini.

git push remoteName :branchName

Bahkan jika cabang tidak pernah digabungkan, biasanya saya masih ingin menjaga komitmen sekitar untuk keturunan. Namun saya masih suka menghapus cabang. Untuk menyebarkan komit di sekitar dan agar tidak dimakan oleh pengumpul sampah, saya membuat tag beranotasi yang menunjuk ke komit yang sama dengan cabang yang dihapus.

git tag -a tagName commitOrBranchName

Lalu saya mendorong tag ke github

git push remoteName tagName

Kapan pengumpul sampah memakan komitmen cabang? Apakah Anda perlu memberi tag dan mendorong tag sebelum menghapus cabang?
Jared Thirsk


4

Tampaknya Anda ingin menghapus 2011_Hotfixcabang tanpa kehilangan riwayatnya. Saya akan membahas penghapusan pertama dan sejarah kedua.

gitMetode penghapusan cabang biasa telah dijelaskan di atas, dan mereka bekerja seperti yang diharapkan. gittidak memiliki perintah satu atau dua kata yang berarti, "Hei git, hapus cabang lokal dan remote." Tetapi perilaku ini dapat ditiru melalui shell script. Misalnya, ambil skrip shell Zach Holman 'git-nuke' . Ini sangat sederhana:

#!/bin/sh
git branch -D $1
git push origin :$1

Masukkan ini dalam file yang dapat dieksekusi (mis., git-nuke) Di salah satu $PATHdirektori Anda . Jika Anda tidak berada di 2011_Hotfixcabang, Anda hanya menjalankan git-nuke 2011_Hotfixakan menghapus cabang lokal dan jauh. Ini jauh lebih cepat & sederhana - meskipun mungkin lebih berbahaya - daripada standargit perintah .

Kekhawatiran Anda tentang pelestarian sejarah adalah hal yang bagus. Dalam hal ini, Anda tidak perlu khawatir. Setelah Anda bergabung 2011_Hotfixke master, semua komit dari 2011_Hotfixakan ditambahkan ke master's sejarah commit. Singkatnya, Anda tidak akan kehilangan riwayat dari penggabungan sederhana.

Saya punya satu kata lagi untuk ditambahkan yang mungkin di luar cakupan pertanyaan Anda, tetapi tetap relevan. Mari kita bayangkan bahwa ada 20 kecil, "sedang dalam proses" berkomitmen 2011_Hotfix; namun, Anda hanya ingin satu komit lengkap untuk 2011_Hotfixditambahkan ke masterriwayat. Bagaimana Anda menggabungkan semua 20 komit kecil menjadi satu komit besar? Untungnya, gitmemungkinkan Anda untuk mengkonsolidasikan banyak komit menjadi satu komit dengan menggunakan git-rebase. Saya tidak akan menjelaskan di sini cara kerjanya; Namun, jika Anda tertarik, dokumentasinyagit-rebase sangat bagus. Perhatikan bahwagit rebase penulisan ulang riwayat, sehingga harus digunakan secara bijaksana, terutama jika Anda baru mengenalnya. Akhirnya, 2011_Hotfixskenario Anda adalah tentang tim pengembang, bukan pengembang solo. Jika anggota tim proyek digunakangit rebase, bijaksana bagi tim untuk memiliki pedoman eksplisit tentang penggunaan git rebaseagar beberapa koboi pengembang tidak secara tidak sengaja merusak sejarah proyek git.


3

Jika sudah berhasil digabungkan kembali dan bahkan mungkin ditandai maka saya akan mengatakan itu tidak ada gunanya lagi. Sehingga Anda bisa melakukannya dengan aman git branch -d branchname.


2

Jika Anda ingin memangkas cabang lokal yang telah dihapus dari asal, Anda juga dapat memangkas, saat menggunakan git fetch

git fetch --prune

0

Anda dapat menghapus cabang di semua UI web utama seperti github, BitBucket. Setelah menghapus cabang online, Anda dapat menghapus cabang lokal menggunakan

git remote prune origin
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.