Git - это тянуть или перезагружать при работе на ветках с другими людьми

Question

Так что, если я использую ветви, которые являются удаленными (отслеживаемыми) ветвями, и я хочу получить последние, мне все еще неясно, следует ли мне делать git pull или git rebase. Мне показалось, что я прочитал, что, когда вы работаете над веткой с другими пользователями, git rebase может сбить их с толку или перебазировать. Это правда? Должны ли мы все использовать git pull?

Answer 1

Git pull - это комбинация из 2 команд

• git fetch (синхронизирует локальное репо с новейшими материалами на пульте)
• git merge (объединяет изменения из удаленной ветви, если они есть, с вашей локальной ветвью отслеживания)

git rebase является лишь грубым эквивалентом git merge. Он ничего не извлекает удаленно. Фактически, он также не выполняет надлежащего слияния, он воспроизводит коммиты ветви, на которой вы находитесь, после новых коммитов из второй ветви.

Его цель - дать вам более чистую историю. Многим людям не нужно много слияний, прежде чем история в gitk станет ужасно похожей на спагетти.

Лучшее графическое объяснение можно увидеть в первых 2 графиках здесь . Но позвольте мне объяснить здесь на примере.

У меня есть 2 филиала: мастер и филиал. Стоя на ветке я могу бегать

git rebase master

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

Проблема, на которую вы ссылаетесь, возникает, если я перебазирую в «неправильном» направлении. Если я только что получил самый последний мастер (с новыми изменениями) и от мастера я перебазировался следующим образом (перед синхронизацией своей ветви):

git rebase mybranch

Теперь я только что вставил свои новые изменения где-то в прошлом мастера. Основная линия коммитов изменилась. А благодаря тому, как git работает с идентификаторами коммитов, все коммиты (от мастера), которые были только что воспроизведены поверх моих новых изменений, имеют новые идентификаторы.

Ну, это немного сложно объяснить только словами ... Надеюсь, это имеет смысл: -)

В любом случае, мой собственный рабочий процесс такой:

• 'git pull' новые изменения с пульта
• переключиться на mybranch
• 'git rebase master', чтобы внести новые изменения мастера в мою историю коммитов
• переключиться обратно на мастер
• 'git merge mybranch', который ускоряется только тогда, когда все в master также находится в mybranch (таким образом, избегая проблемы переупорядочения коммитов в публичной ветви)
• 'git push'

Последнее слово. Я настоятельно рекомендую использовать rebase, когда различия тривиальны (например, люди, работающие с разными файлами или по крайней мере с разными строками). У него есть то, что я пытался объяснить, но это делает историю намного чище.

Как только могут возникнуть значительные конфликты (например, коллега переименовал что-то в кучу файлов), я настоятельно рекомендую объединить. В этом случае вам будет предложено разрешить конфликт, а затем зафиксировать разрешение. С положительной стороны, слияние гораздо проще разрешить при наличии конфликтов. Недостатком является то, что вашей истории может стать трудно следить, если много людей все время сливается: -)

Удачи!

Answer 2

Git rebase - переписывание истории. Вы никогда не должны делать это на ветвях, которые являются «общедоступными» (то есть ветвями, которыми вы делитесь с другими). Если кто-то клонирует вашу ветку, а затем вы перебазируете эту ветку - тогда они больше не смогут извлекать / объединять изменения из вашей ветки - им придется выбросить свою старую ветку и заново потянуть.

Эта статья о программном обеспечении для упаковки с git очень полезна для чтения. Это больше об управлении дистрибутивами программного обеспечения, но это довольно технический и говорит о том, как филиалы могут использоваться / управляться / совместно использоваться. Они говорят о том, когда нужно перебазировать, а когда тянуть и каковы различные последствия каждого из них.

Короче говоря, у них обоих есть свое место, но вам действительно нужно почувствовать разницу.

Answer 3

git pull выполняет слияние, если у вас есть коммиты, которых нет в удаленной ветке. git rebase переписывает любые существующие коммиты, которые вы должны иметь относительно кончика удаленной ветви. Они похожи в том, что оба они могут вызвать конфликты, но я думаю, что использование git rebase, если вы можете, позволяет более гладкое сотрудничество. Во время операции rebase вы можете уточнить свои коммиты, чтобы они выглядели так, как будто они были применены к последней ревизии удаленной ветви. Возможно, объединение больше подходит для более длительных циклов разработки в ветви, в которой больше истории.

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

Answer 4

Проверьте отличные Gitcasts на Ветвление и слияние , а также ребазинг .

Answer 5

Если вы хотите получить исходный код без влияния на удаленные ветви и без каких-либо изменений в локальной копии, лучше всего использовать git pull.

Я полагаю, что если у вас есть рабочая ветвь, в которую вы внесли изменения, используйте git rebase, чтобы изменить базу этой ветки на последний удаленный мастер, вы сохраните все изменения вашей ветки, однако ветка теперь будет ветвиться. из основного местоположения, а не из того места, где он был ранее разветвлен.