зачем нужна вторая ветка трекинга для origin / master

Question

Я читаю книгу Pro Git и запутался, настроив вторую ветку трекинга для origin / master.Ниже приведено описание из книги:

... Например, если вы хотите отправить в проект вторую тему работы, не продолжайте работать над веткой темы, которую вы только что выдвинули- начать заново с главной ветви основного репозитория:

$git checkout -b featureB origin/master
...work
$git commit
$git push myfork featureB
$git fetch origin

, поэтому история коммитов будет выглядеть следующим образом:

Q1-masterветвь уже отслеживает происхождение / мастера, почему автор создал вторую ветку-FeatureB для отслеживания происхождения / хозяина?Каковы преимущества этого?

Answer 1

Суть этих ветвей в том, что ваша работа (в FeatureA и FeatureB) находится на отдельных ветвях - отдельно от master и отдельно друг от друга.Они начинают с origin/master, но не отслеживают его как таковой.Это местные филиалы, которые содержат вашу работу.Затем вы можете отправлять запросы на загрузку в апстрим для своих ветвей featureA и featureB.

Answer 2

TL; DR

Это на самом деле не полезно здесь.Это просто побочный эффект чего-то, что иногда полезно.

Long

Здесь есть проблема терминологии.В частности, слово track или tracking , а фраза отслеживающая ветвь или ответвление отслеживает , является неоднозначным и простым в использовании.Со временем документация Git отошла от использования глагола tracking , чтобы вместо него использовать существительное или прилагательное upstream .Давайте попробуем использовать это слово вместо этого, чтобы избежать путаницы.

Имя ветви, такое как master или featureA или featureB, может не иметь восходящего потока или иметь одно восходящее.(Это только два варианта.) Следовательно, восходящий поток featureA равен либо set , либо unset .Если он установлен, восходящий поток featureA - это либо другое имя вашей ветви, например master, либо одно из ваших имен удаленного отслеживания ¹ , например origin/master или origin/featureA.

При использовании:

git checkout -b featureA origin/master

вы создаете новое имя ветви featureA.Если бы вы сделали это:

git checkout origin/master
git checkout -b featureA

имя новой ветви featureA будет иметь no upstream: он не будет ничего отслеживать.Или, если бы вы сделали это:

git checkout -b featureA master

то же самое будет иметь место, хотя если origin/master и master идентифицируют разные коммиты , вы теперь будете на другом коммите,Но при использовании:

git checkout -b featureA origin/master

возможно - и фактически по умолчанию - что Git установит восходящий поток новой ветви featureA в origin/master.Это зависит от настройки branch.autoSetupMerge (по умолчанию true).Если branch.autoSetupMerge равно true (или не установлено), создание новой ветви с использованием некоторого существующего имени удаленного отслеживания (например, origin/master) в качестве начальной точки заставляет git checkout и git branch установить указанное удаленное отслеживаниеимя в качестве восходящего потока для новой ветви.

Установка восходящего потока для featureA на origin/master часто бесполезна и, возможно, даже нежелательна.Если вы не хотите, чтобы этот восходящий параметр имел место, у вас есть три прямых параметра (плюс более косвенные параметры, такие как многошаговый метод, описанный выше):

• Изменить настройку branch.autoSetupMerge.Это влияет на все будущие операции git checkout -b, в которых (1) пропускаются либо --track, либо --no-track, а (2) использование имени удаленного отслеживания в качестве начального коммита для нового имени ветви.Вы можете временно установить его для одной команды, используя git -c:

  git -c branch.autoSetupMerge=false checkout -b featureA origin/master
  

  , но это бессмысленно из-за следующей опции.

• Использование git checkout -b --no-track featureA origin/masterпереопределить значение по умолчанию.Новая ветвь, featureA, не будет иметь восходящего потока.

• Разрешить featureA ненадолго иметь неверный восходящий поток, но затем исправить это вручную.Например, создав featureA локально, вы можете создать featureA в Git в origin немедленно и установить восходящий поток вашего featureA для вновь созданного origin/featureA:

  git checkout -b featureA origin/master
  git push --set-upstream origin featureA
  

  Или используйте git branch --unset-upstream:

  git checkout -b featureA origin/master
  git branch --unset-upstream featureA
  

  (хотя добавление --no-track к вашей команде оформления заказа, вероятно, проще).

Наличие восходящего потока не особенно вредно , поэтому, если какое-то время установить origin/master в качестве восходящего потока для featureA, возможно, все в порядке.Если вы не хотите, чтобы это произошло, рассмотрите различные варианты выше.Думайте о командах Git как о инструментах , а не решениях: они делают то, что делают, и если то, что они делают, совпадает с тем, что вы хотите сделать, используйте их.Если нет, используйте другие инструменты или инструменты с дефектами и следите за этими операциями, исправляя недостатки.

---

¹ Git вызывает эти remoteотслеживание названий веток, , но я думаю, что слово branch здесь вводит в заблуждение, поэтому я предпочитаю его опускать.К сожалению, в нем по-прежнему используются слова remote и tracking , а remote - это еще одно жаргонное слово в Git, но по крайней мере пара дефисов remote-tracking явно немного отличается от удаленного или отслеживания .

Answer 3

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