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

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

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

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

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

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


git merge branch
person Jim Puls    schedule 31.03.2009    source источник

Ответы (2)


arrow_upward
6
arrow_downward

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

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

person Pat Notz    schedule 01.04.2009

arrow_upward
0
arrow_downward

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

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

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

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

person Bombe    schedule 01.04.2009