Есть ли у git branch -m побочные эффекты для других разработчиков? - PullRequest
Новая
       14

Есть ли у git branch -m побочные эффекты для других разработчиков?

7 голосов
/ 01 апреля 2009

Мы уже научились переключать, какая ветвь указывает на какую , используя git branch -m. Если я сделаю это, станет ли трудной жизнь для других людей, извлекающих информацию из моего хранилища?

Скажем, я делаю кучу вещей на ветке topic1, а затем делаю 

git branch -m master old_master
git branch -m topic1 master
git push origin master

и затем кто-то еще вытянет master из моего удаленного хранилища, что им нужно будет сделать, чтобы все указывало на правильное место? Должен ли я сказать всем повторить мои шаги?

Сродни ли это проблеме перебазирования коммитов после их нажатия и оставлению других разработчиков с висящими объектами?

Ответы [ 2 ]

7 голосов
/ 01 апреля 2009

Я не совсем уверен, как выглядит ваше репо, но вот худший сценарий.

Предположим, ваш origin репозиторий выглядит так 

origin:
o---o---A---B---C  master

А ваш локальный репозиторий выглядит так, 

JimPuls:
o---o---A---B---C  master, origin/master
         \
          D---E---F topic1

Затем, после переименования вашей ветки, ваш локальный репозиторий выглядит так: 

JimPuls:
o---o---A---B---C  old_master, origin/master
         \
          D---E---F master

Теперь, когда вы нажмете master на origin, это будет обновление без ускоренной перемотки вперед. После толчка репозиторий origin будет выглядеть так: 

origin:
o---o---A...B...C  (B & C are orphaned commits)
         \
          D---E---F master

Это может быть жестоко по отношению к вашим друзьям, которые, возможно, совершали коммиты поверх C. Например, если Салли работала с вами, ее хранилище может выглядеть так: 

Sally:
o---o---A---B---C  origin/master
                 \
                  G---H---I master

Теперь, если вы делаете толчок без ускоренной перемотки вперед, а Салли делает fetch, ее репозиторий будет выглядеть так: 

Sally:
          D---E---F  origin/master
         /
o---o---A---B---C  
                 \
                  G---H---I  master

Теперь Салли должна выяснить, как вернуть свою работу (G, H, I) обратно в хранилище. Если она просто выполнит слияние с origin/master, тогда изменения в B и C вернутся в хранилище (упс!). Вместо этого ей придется cherry-pick или rebase, чтобы ее G-H-I сменилась на origin/master.

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

ПРИМЕЧАНИЕ: Выше приведен сценарий наихудшего случая. Если ваша ветка topic1 вышла из master в C, тогда это изменение будет ускоренной перемоткой вперед, и проблем не будет.

0 голосов
/ 01 апреля 2009

В основном ваши операции такие же, как: 

# git checkout master
# git reset --hard topic1
# git push origin master

И они будут иметь именно такой эффект: все остальные получат ветку topic1 (хотя для них она называется master) и ее происхождение до точки, где master и topic1 впервые разошлись. Тогда старая ветка master валяется в своих хранилищах и будет собирать мусор в будущем, потому что на это уже ничего не указывает.

Если topic1 - это ветвь, которая возникла из текущего HEAD из master, у вас все будет в порядке. В противном случае вы попадете в ситуацию «переписывания истории», которая может испортить ваш пример. ваши теги. Вы должны тщательно подумать о том, чего вы действительно пытаетесь достичь. Может быть, простой git merge послужит вам лучше?

...