Як я можу архівувати гілки git?

У моєму сховищі git є кілька старих гілок, які вже не активно розвиваються. Я хотів би архівувати гілки так, щоб вони не з’являлися за замовчуванням під час запуску git branch -l -r. Я не хочу їх видаляти, бо хочу зберігати історію. Як я можу це зробити?

Я знаю, що можна створити посилання поза посиланнями / головами. Наприклад, refs/archive/old_branch. Чи є наслідки цього?

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

Якщо вам потрібно повернутися до відділення, просто перевірте тег. Це ефективно відновить гілку з тегу.

Щоб архівувати та видалити гілку:

git tag archive/<branchname> <branchname>
git branch -d <branchname>

Щоб відновити відділення через деякий час:

git checkout -b <branchname> archive/<branchname>

Історія філії збережеться точно так само, як була під час позначення її.

Відповідь Джеремі в принципі правильна, але IMHO команди, які він вказує, не зовсім правильні.

Ось як архівувати гілку до тегу, не вимагаючи оформити гілку (і, отже, не потрібно переходити до іншої гілки, перш ніж її можна видалити):

> git tag archive/<branchname> <branchname>
> git branch -D <branchname>

А ось як відновити гілку:

> git checkout -b <branchname> archive/<branchname>

Так, ви можете створити ref за допомогою нестандартного префікса за допомогою git update-ref. напр

• Архівуйте філію: git update-ref refs/archive/old-topic topic && git branch -D topic
• Відновіть гілку (за потреби): git branch topic refs/archive/old-topic

Посилання з нестандартним префіксом (тут refs/archive) не відображатимуться ні зазвичай git branch, git logні git tag. Тим не менш, ви можете перерахувати їх git for-each-ref.

Я використовую такі псевдоніми:

[alias]
    add-archive = "!git update-ref refs/archive/$(date '+%Y%m%d-%s')"
    list-archive = for-each-ref --sort=-authordate --format='%(refname) %(objectname:short) %(contents:subject)' refs/archive/
    rem = !git add-archive
    lsrem = !git list-archive

Крім того, ви можете налаштуватиpush = +refs/archive/*:refs/archive/* віддалені пристрої, як-от автоматичне натискання архівованих гілок (або git push origin refs/archive/*:refs/archive/*для одного знімка).

Інший спосіб - записати SHA1 десь перед видаленням гілки, але він має обмеження. Команди без будь-якого дозволу будуть GC'd через 3 місяці (або пару тижнів без відмови) , не кажучи вже про посібник git gc --prune. Коміти, на які посилаються відповіді, захищені від GC.

Редагувати: Знайшов реалізацію тієї самої ідеї за допомогою @ap :git-attic

Редагувати ^ 2: Знайшов допис у блозі, де сам Гітстер використовував ту саму техніку.

Розширення Стіва відповіді , щоб відобразити зміни на пульті дистанційного керування, я зробив

 git tag archive/<branchname> <branchname>
 git branch -D <branchname>
 git branch -d -r origin/<branchname>
 git push --tags
 git push origin :<branchname>

Щоб відновитись із пульта, див. Це питання .

Ви можете архівувати гілки в іншому сховищі. Не дуже елегантно, але я б сказав, що це альтернатива.

git push git://yourthing.com/myproject-archive-branches.git yourbranch
git branch -d yourbranch

Ось псевдонім для цього:

arc    = "! f() { git tag archive/$1 $1 && git branch -D $1;}; f"

Додайте так:

git config --global alias.arc '! f() { git tag archive/$1 $1 && git branch -D $1;}; f'

Майте на увазі, що git archiveкоманда вже є, тому ви не можете використовувати archiveяк псевдонім ім'я.

Також ви можете визначити псевдонім, щоб переглянути список "архівованих" гілок:

arcl   = "! f() { git tag | grep '^archive/';}; f"

про додавання псевдонімів

Я використовую такі псевдоніми, щоб приховати заархівовані гілки:

[alias]
    br = branch --no-merge master # show only branches not merged into master
    bra = branch                  # show all branches

Отже, git brпоказувати активно розвинені гілки та git braпоказувати всі гілки, включаючи "архівовані" .

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

Ось два простих кроки, які значно допоможуть археології та розвитку.

1. Зв’яжіть кожну гілку завдань із пов’язаною проблемою у трекері проблем, використовуючи просту конвенцію іменування .
2. Завжди використовувати git merge --no-ffдля об'єднання гілок завдань; ви хочете, щоб ця фіксація злиття та міхур історії були навіть для одного.

Це воно. Чому? Тому що, як археолог з питань коду, рідко я починаю з того, щоб знати, яку роботу було зроблено на гілці. Значно частіше саме тому в усіх кричущих дев'яти пеклах код пишеться так ?! Мені потрібно змінити код, але він має деякі дивні функції, і мені потрібно розгадати їх, щоб уникнути зламу чогось важливого.

Наступним кроком є git blameпошук пов'язаних команд, а потім сподівання, що повідомлення журналу є пояснювальним. Якщо мені потрібно копати глибше, я дізнаюся, чи була робота зроблена у гілці, і прочитаю гілку в цілому (разом із коментарем у трекері випуску).

Скажімо, git blameочки на коміті XYZ. Я відкриваю веб-переглядач історії Git (gitk, GitX, git log --decorate --graphі т. Д.), Знаходжу фіксацію XYZ і бачу ...

AA - BB - CC - DD - EE - FF - GG - II ...
     \                       /
      QQ - UU - XYZ - JJ - MM

Там моя філія! Я знаю, що QQ, UU, XYZ, JJ та MM - це одна і та ж галузь, і мені слід переглянути деталі їх журналів. Я знаю, що GG буде об'єктом злиття і матиме назву гілки, яка, сподіваємось, асоціюється з проблемою в трекері.

Якщо з якихось причин я хочу знайти стару гілку, я можу запустити git logі шукати ім'я гілки в комісії злиття. Це досить швидко навіть у дуже великих сховищах.

Це я маю на увазі, коли кажу, що філії архівів самі.

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

Мій підхід полягає в перейменуванні всіх галузей, які мене не цікавлять, з префіксом "trash_", а потім використовувати:

git branch | grep -v trash

(із прив’язкою ключа оболонки)

Щоб зберегти забарвлення активної гілки, потрібно:

git branch --color=always | grep --color=never --invert-match trash

Ви можете використовувати сценарій, який буде архівувати відділення для вас

архівний відділ

Він створює для вас тег з архівом префікса /, а потім видаляє гілку. Але перевірте код, перш ніж використовувати його.

Використання - $/your/location/of/script/archbranch [branchname] [defaultbranch]

Якщо ви хочете запустити скрипт, не записуючи його, додайте його до свого шляху

Тоді ви можете подзвонити по телефону

$ archbranch [branchname] [defaultbranch]

Це [defaultbranch]галузь, до якої вона піде, коли буде зроблено архівування. Існують деякі проблеми з кольоровим кодуванням, але інші, ніж це має працювати. Я давно його використовую в проектах, але він все ще знаходиться на стадії розробки.

Я інколи архівую філії так:

1. Створіть файли патчів, наприклад, format-patch <branchName> <firstHash>^..<lastHash>(отримати firstHash та lastHash за допомогою git log <branchName>.
2. Перемістіть створені файли патчів у каталог на файловому сервері.
3. Видаліть гілку, наприклад, git branch -D <branchName>

"Застосувати" патч, коли вам потрібно знову використовувати гілку; однак застосування файлів патчів (див. git am) може бути складним залежно від стану цільової гілки. З іншого боку, такий підхід має перевагу тим, що дозволяє філії філій збирати сміття та економити місце у вашому РЕПО.