Как обновить более старую ветку из кода из транка?

Question

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

Я создал ветвь функций, которую не смог объединить с мастером.

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

В ветви функции находятся все новые файлы, поэтому не должно быть конфликтов слияния.

Как бы я поступил так?

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

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

Answer 1

Извлеките свою ветвь функций и либо объедините мастер в ветвь функций (git merge master), либо перебазируйте ветку функций поверх мастер (git rebase master).

Выбор того, что вы выбираете, зависит от того, чтовы хотите, чтобы ваша история выглядела так.

Если вы объединитесь, ваши старые коммиты будут продолжать существовать в их первоначальном состоянии поверх старой версии master, с новым коммитом слияния, содержащим ваши изменения и новую версию.мастера.Некоторым людям это нравится, потому что оно точно отражает исходную историю и потому, что создает меньше конфликтов, чем перебазирование.Однако такая практика может создать запутанную историю с большим количеством коммитов слияния.Команда 'git bisect' также плохо работает с историями, которые имеют много слияний.

Если вы сделаете ребазинг, у вас будет ряд коммитов поверх вашей новой главной ревизии, и вы потеряете свои первоначальные коммиты.,Это создает прямую, линейную историю.Вы также можете использовать 'git rebase -i', чтобы очистить ваши коммиты перед публикацией или добавлением их в master (если вы решите это сделать).Поскольку конфликты должны быть разрешены для каждого из ваших коммитов, а не один раз для коммитов слияния, перебазирование порождает больше конфликтов.

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

Answer 2

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

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

last_master_commit_before_feature_merge
feature_commit1
feature_commit2
...
last_feature_commit   <-master

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

Если вы решите перебазировать, создайте резервную ветку, прежде чем делать:

git checkout my_feature_branch
git branch backup_branch
git rebase master

Это так, чтобы что-нибудьпойти ужасно неправильно, и вам нужно нажать кнопку сброса, вы можете.