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

Ответ 1

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

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

Git rebase является только грубым эквивалентом слияния git. Он ничего не получает удаленно. На самом деле он также не выполняет надлежащего слияния, он повторяет фиксации ветки, на которой вы стоите, после того, как новые коммиты со второй ветки.

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

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

У меня есть 2 ветки: master и mybranch. Когда я нахожусь на моей ветке, я могу бежать

git rebase master

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

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

git rebase mybranch

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

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

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

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

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

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

Удачи!

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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