Чи слід видаляти гілку після її об’єднання?


94

Після об’єднання гілки ви видаляєте її зі сховища?
Однак це хороша практика чи ні?

Зазвичай я створюю багато гілок, оскільки я не хочу порушувати свій поточний випуск, і я хочу видалити їх, щоб підтримувати порядок.
Однак, якщо ви працюєте з Assembla або GitHub, ваші запити на злиття зі старих гілок будуть збережені на сайті, тому, якщо ви видалите їх, ви отримаєте повідомлення про помилку, оскільки він не зможе їх отримати ...

Зазвичай як це вдається?

Відповіді:


72

Немає проблем з видаленням об’єднаних гілок. Усі коміти все ще доступні в історії, і навіть в інтерфейсі GitHub вони все одно відображатимуться (див., Наприклад, цей PR, який стосується форка, який я видалено після прийняття PR).


Ви сказали, що всі коміти все ще доступні в історії. Якщо я переглядаю проект на github.com, я виявляю, що це правда. Однак у настільному додатку Github для Mac здається, що ви більше не можете бачити історію комітів для об’єднаної гілки. Я помиляюся?
Peacetype

Я б додав, що якщо ви не використовуєте git-клієнт, особливо не використовуючи такий із графічним інтерфейсом, тоді наявність гілок може бути корисним для розуміння вашого журналу. Тобто, оскільки у вас немає github / gitlab / іншого графічного інтерфейсу для перегляду, збереження імен гілок дозволяє вам мати просте місце для посилання на історію на додаток до історії комітів, яке в іншому випадку втрачається видаленням гілки. Хтось, будь ласка, дайте мені знати, якщо це останнє твердження неправильне.
Радж

@Raj у вас це вже є, у формі Merge branch fix-foo-barповідомлень про коміти . Спробуйте git log --grep="Merge branch", а потім скиньте власні якорі інтересу через git checkout -b curious-change. Крім того, нічого не втрачається під час видалення гілки - крім простого вказівника "ім'я гілки → коміташу" (а це те, що гілка насправді є, не має значення локальна чи віддалена).
ulidtko

@ fred-foo На питання, чи є це доброю практикою, відповіді немає. (У мене таке саме запитання)
Есгер

27

Я обов’язково прибираю свої гілки після їх об’єднання.

Ми використовуємо GitLab та об’єднуємо запити під час роботи, тому історична інформація про гілки зберігається там; Мені не потрібно, щоб вони захаращували мій список гілок, і коли я дивлюся на вилку колеги, в ідеалі я хотів би бачити лише гілки їхнього поточного активного розвитку. Якщо я намагаюся переглянути якийсь код на їхній гілці, я хочу мати можливість переглянути лише кілька активних гілок, а не кожну функцію чи виправлення, над якими вони коли-небудь працювали.

Вищезазначене також стосується BitBucket та GitHub.

Єдина причина, по якій у вас може бути не видалення гілки після злиття, полягає в тому, що ви знаєте, де закінчилась дана функція, але коміти злиття (і git merge --no-ffякщо ви дійсно хочете) роблять це неактуальним.


3
Очевидно, GitHub завжди робить --no-ff, тому ми не втратимо того факту, що це була гілка навіть у таких ситуаціях.
joeytwiddle

7
@joeytwiddle: припускаючи, що ви використовуєте власний інтерфейс GitHub для об'єднання гілки, так!
Ашера

1

Просто подбайте про
посилання на всі посилання на гіперпосилання ваших ВИДАЛЕНИХ гілок, будуть ЗЛАМАНІ .

Наприклад,
якщо ви видалите branch_feature_xгілку зі свого репозиторію,
відповідна URL-адреса гіперпосилання цієї гілки буде порушена
https://github.com/username/project/tree/branch_feature_x


0

Просто для уточнення, розгалуження, з точки зору git, - це просто посилання на якийсь коміт. Видаливши гілку, ви не будете видаляти коміти з git repo. Звичайно, відокремлені коміти будуть очищені через деякий час через збирач сміття git.

FYI: Зазвичай ми об’єднуємо гілки в master через інтерфейс bitbucket. Там ви можете встановити delete feature branch after mergeпрапор.

Якщо вам потрібно мати справу зі занадто старими гілками, ви можете пошукати деякі утиліти, наприклад цю .

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.