В Git местные филиалы могут отслеживать друг друга - насколько это полезно?

Question

Я слышал, что в Git вы можете позволить local branch A отслеживать другую local branch B.

Зачем кому-то это делать?

Answer 1

Основными вещами, которые приходят на ум при отслеживании локальной ветви другой локальной ветви, являются (1) более информированные сообщения от Git относительно ветви, находящейся впереди / позади отслеживаемой ветви, и (2) перехватчиков триггеров.

В одной области Git отображает больше информации при создании ветки.Создание базовой ветви выглядит следующим образом:

$ git co -b A master
Switched to a new branch 'A'

При создании отслеживание ветви выглядит следующим образом:

$ git co --track -b B master
Branch B set up to track local branch master.
Switched to a new branch 'B'

Это добавитв .git/config:

[branch "B"]
    remote = .
    merge = refs/heads/master

После внесения некоторых изменений в ветви A и B, выполнение git status -s -b в ветви A отображает ## A, а в ветви B этоотображает ## B...master [ahead 1, behind 1], предоставляя некоторую быструю информацию о взаимоотношениях между ветвями B и master.

Другая область, где вы можете захотеть отслеживать локальную ветку, другая локальная ветка - это запуск hooks ;в частности pre-receive, update, post-receive и post-update в течение git push.У вас могут быть ловушки, например, для запуска сборки на сервере непрерывной интеграции, выполнения некоторых проверок заголовка лицензии, проверки на наличие ошибок формата пробелов и т. Д.

Answer 2

Есть много случаев, когда отслеживание другой локальной ветки полезно.Например, в некоторых рабочих процессах git существует нечто, защищающее master от непосредственного получения push-запросов.Одним из примеров является система проверки кода или непрерывной интеграции, которая должна пройти до посадки фиксации в удаленной ветви.Другой пример - когда проект управляется набором коммиттеров, которые принимают только запросы извлечения (проекты GitHub часто делают это).Как разработчик, я могу захотеть создать функциональную ветвь, а затем отправить эту ветку на проверку (или отправить запрос на извлечение для коммиттера репо).Затем я могу продолжить локальную разработку, пока мои товарищи по команде асинхронно проверяют мой код и сборки CI завершены.Чтобы продолжить разработку поверх моего предыдущего коммита, я могу создать вторую локальную ветвь, которая будет отслеживать мою первую локальную ветку.Это позволяет мне строить из моего первого коммита, даже если этот коммит не попал в удаленную ветку upstream.Кроме того, если кто-то предлагает изменения проверки кода для моей первой ветви, или сборка CI не удалась, я могу обновить эту ветку, а затем перенести эти изменения в локальные ветви нисходящего потока.Вот как настроить ветку для отслеживания другой локальной ветви.

С учетом локальной ветви функции:

$ git co -b branch-1
$ git branch -u origin/master
Switched to a new branch 'branch-1'
$ git branch -vv
* branch-1                9f0c361 [origin/master] Some commit message
  master                  85ede1a [origin/master] Some commit message

Это показывает, что локальные ветви отслеживания master и branch-1 обе отслеживаютветка master на пульте origin.Теперь я могу создать другую ветку и настроить ее для отслеживания локальной ветви отслеживания branch-1.

$ git co -b branch-2
Switched to a new branch 'branch-2'
$ git branch -u branch-1 branch-2
Branch branch-2 set up to track local branch branch-1 by rebasing.
$ git branch -vv
  branch-1                85ede1a [origin/master] Some commit message
* branch-2                85ede1a [branch-1] Some commit message
  master                  85ede1a [origin/master] Some commit message

Answer 3

Обратите внимание, что информация впереди / сзади, которую вы располагаете между одной веткой 'B' и другой 'A', отслеживаемой первой, работает только в том случае, если конфигурация branch.B.merge строго определена: refs/heads/master.
Это не сработало бы, если бы оно было свободно определено: 'master'.

Но с commit 05e7368 , выполненным Junio ​​C Hamano (gitster) для Git 2.3.0 (1 квартал 2015 года), это тоже будет работать.

При проверке ветки, которая собирается строить поверх другой ветвь (часто ветвь удаленного отслеживания), "git checkout" сообщает, как ваша работа связана с другой ветвью, например

Your branch is behind 'origin/master', and can be fast-forwarded.

Назад, когда эта функция была введена, это было сделано только для веток, которые строятся на ветвях удаленного отслеживания, но 5e6e2b4 (локальные ветви ведут себя как удаленные ветки, когда --tracked, 2009-04-01 , git 1.6.3) добавлена ​​поддержка для предоставления того же отчета для веток, построенных на других локальных ветвях (то есть ветвях, чьи переменные branch.*.remote установлены в '.').
Однако, в отличие от поддержки создания веток в ветвях удаленного отслеживания, эта не учитывает тот факт, что в конфигурации branch.*.merge разрешена запись сокращенного имени ветви .

Когда branch.*.merge установлено в 'master' (не 'refs/heads/master'), то есть "моя ветвь строится на локальной ветке 'master'", это заставило "git checkout" сообщить:

Your branch is based on 'master', but the upstream is gone.

Вверх по течению находится наш репозиторий, и он определенно не исчез, так что это вывод ерунда.

Answer 4

Один пример, который я могу вспомнить, это если у вас есть «стабильная» ветка.Тогда было бы неплохо, если бы вы могли создать новую ветвь, например, «эксперимент», и позволить ей отслеживать стабильную ветвь.

git checkout --track -b experiment stable
* do some experiments with some commits *
git push

Кроме того, это может быть для согласованности (это всего лишь предположение),