Функция синхронизации с мастером, используя rebase против слияния - PullRequest
Новая
       19

Функция синхронизации с мастером, используя rebase против слияния

0 голосов
/ 27 ноября 2018

В соответствии со стратегией слияния Атлассиана лучше всего объединить ветви объектов обратно в мастер с опцией --no-ff.Это сохраняет чистую историю git на master, что позволяет вам легко увидеть работу, которая была сделана в слиянии.Имея это в виду, имеет ли значение, если я использую ребаз или слияние, когда сливаю мастер в свою ветвь функций ?

git merge

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

git rebase

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

Как перебазирование против слияния в этом сценарии влияет на ...

  1. процесс синхронизации мастера с функцией?
  2. история мерзавцев при работе светка?
  3. git history после слияния ветки с master и удаления?

1 Ответ

0 голосов
/ 27 ноября 2018

  1. Перебирая, вы переписываете историю, поэтому вам придется принудительно нажимать на ветку функций.Если вы работаете с другими людьми, см. (2).

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

  3. История Git без перебазирования: 

    * master
|\
| * branch commit 2
|/|
* | simultaneous commit on master
| * branch commit
|/
* previous commit on master

    против перебазирования: 

    * master
|\
| * branch commit 3
| * branch commit 2
| * branch commit
|/
* simultaneous commit on master
* previous commit on master

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

Некоторые дополнительные цвета: когда я решаю, уместен ли перебаз, я часто думаю,о том, считаю ли я ветку «опубликованной».«Опубликованная» ветка - это ветка, над которой другие разработчики могли бы поработать, и разумно ожидать, что она не изменится.«Неопубликованная» ветвь - это ветка, которую я использую для организации своих изменений в один или несколько коммитов, и еще не поделился с другими разработчиками.Это черновик моей работы.

...