Является ли ветвление от branchA, которое само разветвляется от master, таким же, как ветвление от master, а затем слияние изменений с другой ветви master?

#git #github #version-control

#git #github #контроль версий

Вопрос:

Сценарий 1:

  • У нас есть master.
  • git checkout -b branchA (разветвленная от master)
  • git checkout -b BranchB (разветвленный от branchA)
  • branchA была объединена.
  • git проверка BranchB
  • git pull origin master (основные изменения переносятся в BranchB)
  • // Это конечное состояние

Сценарий 2:

  • У нас есть master.
  • git checkout -b branchA (разветвленная от master)
  • git checkout master
  • git checkout -b BranchB (разветвленный от master)
  • git извлекает исходную ветку (извлекает изменения branchA в BranchB)
  • branchA слилась с master
  • git извлекает исходный мастер
  • // конечное состояние.

Являются ли оба этих сценария одинаковыми?

Комментарии:

1. Git pull origin master — не будет переносить изменения в ветку B. Он просто обновит ваш локальный master изменениями из удаленного источника. Поскольку вы не вносили никаких изменений, и если в удаленном репозитории нет изменений, многократное ветвление и слияние не изменят состояние. Все ветви по-прежнему будут указывать на последний коммит.

2. Вы никогда ничего не фиксируете ни в одной из ветвей. Это намеренно?

3. Это просто беспорядок в вашем описании. Ветвь не создается из другой ветви, ветвь основана на фиксации, ветвь — это просто указатель, указывающий на фиксацию. Вам лучше изучить основную концепцию git из ProGit .

4. Что вы имеете в виду под «branchA был объединен». в сценарии 1?

5. Говоря «git pull origin branchA в сценарии 2», кажется, вы также неправильно поняли концепцию извлечения и слияния, на самом деле это операция слияния. И поскольку ветвь A и ветвь B в сценарии 2 указывают на одну и ту же фиксацию, нет необходимости выполнять операцию слияния. Наконец, git pull — плохая привычка, сначала git fetch и просмотрите изменения, затем решите использовать git merge или git rebase — лучшая операция.

Ответ №1:

Вы не ответвляетесь от ветки, вы ответвляетесь от фиксации, на которую ссылается ветка. Если master и branchA ссылаются на один и тот же коммит, назовем его ABC123, тогда все они одинаковы.

 git branch branchB master
git branch branchB branchA
git branch branchB ABC123
  

Во всех случаях BranchB будет указывать на фиксацию ABC123. С этого момента то, что происходит с master или branchA, не влияет на BranchB.

Например…

 A - B [master]

$ git branch branchA
$ git branch branchB

A - B [master]
      [branchA]
      [branchB]
  

Все три ветви указывают на фиксацию B.

Если мы затем проверим branchA и сделаем несколько коммитов…

 $ git checkout branchA
$ ...git commit...
$ ...git commit...

      C - D [branchA]
     /
A - B [master]
      [branchB]
  

master и BranchB остаются при фиксации B. branchA отключается сама по себе. Если мы затем проверим BranchB и сделаем несколько коммитов…

 $ git checkout branchB
$ ...git commit...
$ ...git commit...

      C - D [branchA]
     /
A - B [master]
     
      E - F [branchB]
  

Теперь BranchB отключается сам по себе. И если мы сделаем то же самое для master…

 $ git checkout master
$ ...git commit...
$ ...git commit...

      C - D [branchA]
     /
A - B - G - H [master]
     
      E - F [branchB]
  

master отключается сам по себе.


Остальная часть вашего сценария запутана, потому что это неверно.

 git pull origin master (master changes pulled into branchB)
  

Это переносит изменения из источника / master в master.

Если вы хотите перенести origin / master в BranchB, вы бы использовали git pull origin master:branchB . Полный синтаксис git pull <remote> <src>:<dest> . Обычно это используется как just git pull <remote> <src> .