Как мне заархивировать ветки git? - PullRequest
257 голосов
/ 20 августа 2009

У меня есть несколько старых веток в моем репозитории git, которые больше не находятся в активной разработке. Я хотел бы заархивировать ветви, чтобы они не отображались по умолчанию при запуске git branch -l -r. Я не хочу их удалять, потому что я хочу сохранить историю. Как я могу это сделать?

Я знаю, что можно создать реф вне рефсов / голов. Например, refs / archive / old_branch. Есть ли какие-либо последствия этого?

Ответы [ 11 ]

341 голосов
/ 21 августа 2009

Я считаю, что правильный способ сделать это - пометить ветку. Если вы удалили ветку после того, как отметили ее, то вы фактически сохранили ветку, но она не загромождает ваш список ветвей.

Если вам нужно вернуться в ветку, просто отметьте тег. Эффективно восстановит ветку из тега.

Для архивации и удаления ветки:

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

Чтобы восстановить ветку через некоторое время:

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

История ветки будет сохранена точно так, как это было, когда вы пометили ее.

108 голосов
/ 27 ноября 2010

Ответ Джереми в принципе верен, но ИМХО, указанные им команды не совсем верны.

Вот как архивировать ветку в теге без необходимости извлекать ветку (и, следовательно, без необходимости извлекать ветку в другую ветку, прежде чем вы сможете удалить эту ветку):

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

А вот как восстановить ветку:

> git checkout -b <branchname> archive/<branchname>
19 голосов
/ 07 декабря 2016

Да, вы можете создать ссылку с нестандартным префиксом, используя git update-ref. (например, git update-ref refs/archive/old-topic your-commit)

В отличие от обычных веток или тегов, эти ссылки не будут отображаться на обычных git branch, git log или git tag (в то время как вы можете видеть их с git log --all или git for-each-ref, как показано ниже).

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

Я использую следующие псевдонимы:

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

Кроме того, вы можете настроить пульты, например push = +refs/archive/*:refs/archive/*, на автоматическое нажатие (или git push origin refs/archive/*:refs/archive/* для однократного).

Редактировать: Нашел perl-реализацию той же идеи с помощью @ ap : git-attic

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

17 голосов
/ 20 августа 2009

Вы можете заархивировать ветки в другом хранилище. Не так элегантно, но я бы сказал, что это жизнеспособная альтернатива.

git push git://yourthing.com/myproject-archive-branches.git yourbranch
git branch -d yourbranch
13 голосов
/ 14 февраля 2017

Расширяя ответ Стива , чтобы отразить изменения на пульте, я сделал

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

Для восстановления с пульта см. этот вопрос .

9 голосов
/ 02 сентября 2015

Вот псевдоним для этого:

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"

о добавлении псевдонимов

5 голосов
/ 18 апреля 2013

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

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

То есть git br для отображения активно развивающихся ветвей и git bra для отображения всех ветвей, включая "архивированные" единицы.

3 голосов
/ 05 февраля 2015

я бы не архивировал ветки. Иными словами, ветки архивируют сами. Вы хотите, чтобы информация, относящаяся к археологам, была найдена надежными способами. Надежный в том, что он помогает в ежедневном развитии и не добавляет дополнительного шага к процессу выполнения работы. То есть я не верю, что люди не забудут добавить тег, как только они закончат работу с веткой.

Вот два простых шага, которые очень помогут развитию археологии и .

  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 и найти имя ветви в коммите слияния. Это достаточно быстро даже для очень больших репозиториев.

Вот что я имею в виду, когда говорю, что ветви сами архивируют.

Пометка каждой ветви добавляет ненужную работу к выполнению задач (критический процесс, который должен быть безжалостно упорядочен), объединяет список тегов (не говоря о производительности, но удобочитаемость для человека) с сотнями тегов, которые очень редко бывают полезными, и даже не очень полезен для археологии.

2 голосов
/ 20 сентября 2016

Мой подход состоит в том, чтобы переименовать все ветви, которые меня не интересуют, с префиксом "trash_", а затем использовать:

git branch | grep -v trash

(с привязкой ключа оболочки)

Чтобы сохранить окраску активной ветви, потребуется:

git branch --color=always | grep --color=never --invert-match trash
1 голос
/ 25 июня 2013

Вы можете использовать скрипт, который заархивирует для вас ветку

archbranch

Создает для вас тег с архивом префиксов /, а затем удаляет ветку. Но проверьте код, прежде чем использовать его.


Использование - $/your/location/of/script/archbranch [branchname] [defaultbranch]

Если вы хотите запустить скрипт без указания местоположения, добавьте его в свой путь

Тогда вы можете позвонить по

$ archbranch [branchname] [defaultbranch]

[defaultbranch] - это ветвь, к которой он перейдет после завершения архивирования. Есть некоторые проблемы с цветовым кодированием, но кроме того, что оно должно работать. Я давно использую его в проектах, но он все еще находится в стадии разработки.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...