Коли видалити гілки в Git?

Припустимо, у нас є стабільна програма.

Завтра хтось повідомляє про велику помилку, яку ми вирішимо виправити відразу. Таким чином, ми створюємо гілку для цього виправлення від "master", називаємо її "2011_Hotfix", і ми підштовхуємо її, щоб усі розробники могли співпрацювати над її виправленням.

Ми виправляємо помилку та об’єднуємо "2011_Hotfix" у "master", а також у поточну галузь розвитку. І натисніть "господар".

Що ми робимо з "2011_Hotfix" зараз? Чи повинен він просто сидіти там, як гілка, назавжди до кінця часу, або ми повинні тепер її видалити, оскільки вона послужила своєму призначенню? Здається, нечисто просто залишати гілки, що лежать повсюди, оскільки список гілок, швидше за все, стане дуже довгим, більшість з яких вже навіть не потрібні.

У випадку, якщо його слід видалити, що буде з його історією? Чи збережеться це, хоча фактична галузь більше не доступна? Крім того, як би я видалити віддалену гілку?

Ви можете сміливо видалити гілку за допомогою git branch -d yourbranch. Якщо він містить неперевірені зміни (тобто ви втратите комісії, видаливши гілку), git скаже вам і не видалить її.

Отже, видалення об'єднаної гілки коштує дешево і не змусить вас втратити історію.

Щоб видалити віддалену гілку, використовуйте git push origin :mybranch, припускаючи, що ваше віддалене ім'я є походженням, а віддалена гілка, яку ви хочете видалити, названа mybranch.

Що вам потрібно зробити, це позначити те, що ви випускаєте. Тримайте гілки навколо, коли ви активно розвиваєтесь.

Видаліть старі гілки за допомогою

git branch -d branch_name

Видаліть їх із сервера за допомогою

git push origin --delete branch_name

або старий синтаксис

git push origin :branch_name

який читається як "нічого не натискайте на ім'я гілки під час виникнення".

Це означає, що поки DAG (спрямований ациклічний графік) може вказувати на нього, комісії будуть існувати в історії.

Google "git-stream", і це може дати більше розуміння щодо управління випуском, розгалуженням та тегами.

Оскільки в запитанні є тег "github", я також додам це: конкретно в Github , якщо ви потягнете запит на гілку і вона об'єднається (або через інтерфейс користувача, або об'єднавши гілку запиту на виклик), ви не будете втрачаєте дані запиту на витяг (включаючи коментарі), навіть якщо ви видалите гілку .

Наслідок цього: Якщо ви включите запити на виклик як частину свого робочого процесу (який солодко поєднується з оглядами коду), ви можете безпечно видалити гілки, як тільки вони об’єднаються. Це настільки звично, що нещодавно Github додав (солодку) функцію, яка з'являється кнопкою "видалити гілку" відразу після об'єднання запиту на витяг.

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

Звичайно, жодне керування історією (витягнути запити чи іншим чином) не замінює належне тегування версій (які ви, як правило, автоматизуєте тим самим інструментом / сценарієм, який розгортає / пакує версію), тому ви завжди можете швидко переходити до того, на що трапляються ваші користувачі. в даний момент. Позначення тегів - це також ключ до вирішення вашої початкової проблеми: якщо ви встановите, що будь-яка гілка, об'єднана з гілками "робота", може і повинна бути видалена, а будь-яка, яка об'єднана з тегом версії, "виробництво" тощо, не повинна , ви завжди будете мати виправлення, поки вони не будуть інтегровані у майбутній версії.

Я додам, що недоліком видалення гілок є те, що ви порушите будь-які гіперпосилання на ці гілки на GitHub (це питання позначене github). Ви отримаєте 404 Not Foundпомилку для цих посилань. Ось чому я змінюю свої посилання, щоб вказати на фіксацію чи тег після видалення гілки на GitHub.

Оскільки деякі посилання неможливо змінити, як-от в електронній пошті, я тепер уникаю гіперпосилання на гілки GitHub цілком і посилаюся на коміт або теги з першого дня.

Я вважаю за краще видалити гілки після їх об'єднання. Це запобігає візуальному захаращенню довгого списку гілок у вашому сховищі. Ці гілки також поширюються на всі вилки сховища.

Спочатку я видаляю свою місцеву гілку. Це запобігає випадковому натисканню.

git branch -d branchName

Потім я видаляю гілку віддаленого відстеження

git branch -dr remoteName\branchName

Потім я видаляю гілку на GitHub. Я використовую веб-інтерфейс, але еквівалентна команда нижче.

git push remoteName :branchName

Навіть якщо гілка ніколи не об'єднується, я зазвичай хотів би зберегти зобов’язання для нащадків. Однак я все одно люблю видалити гілку. Щоб розповсюджувати комітети навколо та не допускати їх з'їдання сміттєзбірником, я роблю примітку, що вказується на те саме, що і видалене відділення.

git tag -a tagName commitOrBranchName

Потім я підштовхую тег до github

git push remoteName tagName

Здається, ви хочете видалити 2011_Hotfixгілку, не втрачаючи її історії. Я обговорюю видалення перше та історію друге.

Звичайні gitметоди видалення гілки вже були описані вище, і вони працюють як очікувалося. gitне має команди з одним або двома словами, що означає: "Ей git, видаліть і локальну, і віддалену гілку". Але цю поведінку можна імітувати за допомогою сценарію оболонки. Наприклад, візьміть сценарій оболонки Зака ​​Холмана "git-nuke" . Це дуже просто:

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

Помістіть це у виконуваний файл (наприклад, git-nuke) в один із ваших $PATHкаталогів. Якщо ви не на 2011_Hotfixгілці, просто запущена програма git-nuke 2011_Hotfixвидалить як локальну, так і віддалену гілки. Це набагато швидше і простіше - хоча можливо і небезпечніше - ніж стандартgit команди.

Ваша турбота про збереження історії - це добре. У цьому випадку вам не потрібно хвилюватися. Після того як ви приєднаєтесь 2011_Hotfixдо цього master, всі комісії з файлу 2011_Hotfixбудуть додані до masterісторії фіксації. Словом, ви не втратите історію від простого злиття.

Маю ще одне слово, що могло б вийти за рамки вашого питання, але все-таки є актуальним. Уявімо собі, що існує 20 крихітних «незавершених робіт» 2011_Hotfix; однак, ви хочете, 2011_Hotfixщоб masterдо історії історії було додано лише одне повне завдання . Як ви об'єднаєте всі 20 невеликих комісій в один великий комітет? На щастя, gitдозволяє об'єднати декілька комітетів в одну команду за допомогою git-rebase. Я не поясню тут, як це працює; однак, якщо вам цікаво, документація наgit-rebase відмінні. Зауважте, щоgit rebase переписує історію, тому її слід використовувати розумно, особливо якщо ви новачок у ній. Нарешті, ваш 2011_Hotfixсценарій стосується команди розробників, а не соло. Якщо користувачі членів проектної групи використовуютьgit rebase, розумно для команди є чіткі вказівки щодо використання для git rebaseтого, щоб якийсь ковбойський розробник в команді не мимоволі завдав шкоди gitісторії проекту.

Якщо це було успішно об'єднано назад і, можливо, навіть позначено тегами, я б сказав, що це більше не має користі. Тож можна сміливо робити git branch -d branchname.

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

git fetch --prune

Ви можете видалити гілки у всіх основних веб-інтерфейсах, таких як github, BitBucket. Після видалення відділення в Інтернеті ви можете видалити локальну гілку за допомогою

git remote prune origin