#git
#git
Вопрос:
Ну, я не следовал лучшим практикам, и теперь я как бы застрял, не зная, что именно делать.
Я работал над главной веткой, и другой разработчик сделал то же самое. Он перенес свои изменения в origin / master. Я не нажимал на свою, а просто сделал пару коммитов на локальном. В моем рабочем каталоге больше не ведется разработка. Как я могу это очистить?
Достаточно ли выполнить выборку на моей стороне, чтобы выполнить последнее изменение в origin / master, не испортив все дело?
Ответ №1:
Вы должны быть в состоянии просто выполнить git-извлечение из источника. Это объединит новый материал в вашу локальную ветку. Затем вы также можете отправить свои зафиксированные локальные изменения в origin. Если возникнут какие-либо конфликты, git предупредит вас об этом и пометит их, чтобы вы могли разрешить их вручную. Не нужно беспокоиться, поскольку это именно то, для чего создан git и в чем он превосходит.
Комментарии:
1. Возможно, вы захотите прояснить, что точка, в которой у вас могут возникнуть конфликты, находится после слияния, а не при нажатии, поскольку это часто является источником путаницы.
2. Вы правы, git покажет конфликты при слиянии. Если во время нажатия что-то не так, он просто откажется от нажатия.
3. Смысл был в том, что вы должны отредактировать свой ответ, чтобы сделать его однозначным.
Ответ №2:
Если вы запустите git fetch origin , это обновит origin/master и все другие ветки удаленного отслеживания. (По сути, они похожи на кэши состояния этих ветвей на origin .)
Теперь, если вы просто сделаете git merge origin/master , вы должны быть в состоянии сделать, git push origin master поскольку теперь ваша master история будет включать историю master from origin .
Если вас беспокоит сохранение линейной истории (что, похоже, волнует многих людей), вы бы сделали git rebase origin/master перед нажатием кнопки.
В качестве (приблизительных) сокращений для выполнения git fetch origin а затем git merge origin/master или git rebase origin/master вы можете сделать:
git pull origin master
… или:
git pull --rebase origin master
… но лично я думаю, что понятнее выполнять выборку и объединение / перебазирование по отдельности.
Комментарии:
1. Спасибо, что обратили мое внимание на опцию —rebase для извлечения. Никогда не использовал эту
2. @mark-longair, я тоже не знаком с опцией перебазирования. Могу ли я сделать это только потому, что мои локальные изменения уже были внесены? Что, если в моем локальном рабочем репозитории была какая-то незавершенная разработка?
3. @Luc: git не позволит вам выполнить перебазирование, если у вас нет чистого рабочего дерева, так что, да, сначала вам нужно зафиксировать свою работу. Поскольку
git rebaseпереписывается история вашей ветки, я, вероятно, придерживался бы простогоgit merge origin/masterилиgit pull origin master, пока вы не будете более уверены в git.
Ответ №3:
Перенесите свои изменения поверх новой ветки master, затем нажмите
git rebase origin/master
git push origin
Конечно, если возникнут какие-либо конфликты слияния, вам придется их разрешить (после разрешения git rebase --continue , но инструмент подскажет вам, как это сделать, когда это произойдет).
Если вы предпочитаете, вы можете объединить ветви (это все еще ваша ветка, даже если вы когда-либо клонировали ее из master):
git merge origin/master
git push origin
У вас будут те же слияния и, возможно, те же конфликты, но история будет немного отличаться: перебазирование «группирует» все ваши коммиты в конце новой главной ветки, тогда как при слиянии они будут отображаться чередующимися (с хронологическим журналом, а не в топологическом порядке), поскольку они произошли вовремя.
Приветствия