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 работает с идентификаторами коммитов, все коммиты (от master), которые были только что воспроизведены поверх моих новых изменений, имеют новые идентификаторы.

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

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

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

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

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

Удачи вам!

Answer 2

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

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

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

Answer 3

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

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

Answer 4

Ознакомьтесь с отличными Gitcasts на Ветвление и слияние а также перебазирование.

Answer 5

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

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