Безопасный способ объединения нескольких веток

Question

Безопасный способ объединения нескольких веток

У нас есть несколько филиалов, и я хочу убедиться, что не наделал глупостей.

В ветке 1 есть: фиксация A + фиксация B

В ветви 2 есть: фиксация A + фиксация C (работа продолжается с фиксации A) + фиксация D

Ветка 3 - это новая ветка

Филиал 4 (главный)

Мне нужно объединить фиксацию A и часть фиксации C в основную ветку, поскольку были задержки с работой, связанной с фиксацией D, поэтому теперь мой клиент хочет, чтобы функция из фиксации C была выпущена по отдельному графику от фиксации D.

Я подумал о создании запроса на перенос для ветки 3 с выделением для фиксации A и фиксации C. Однако я не могу этого сделать, потому что фиксация C включает ремастер, некоторые исправления конфликтов слияния и соответствующий дополнительный код.

Questinos:

Если я просто скопирую и вставлю соответствующий код и сделаю PR в Branch 3, будут ли у меня проблемы позже, когда Branch 1, Branch 2 и Branch 3 в конечном итоге объединятся в master?
Достаточно ли умен git, чтобы подбирать копии и вставки, если я не фиксирую вишневый выбор, или возникнут проблемы с дублированием кода в основной ветке, когда все ветки в конечном итоге будут объединены?

Мне нужно использовать ветвь 3 для создания слияния, чтобы освободить запрос на перенос, и мне не разрешено касаться ветки 1. Над этим работает отдельная группа.

# git merge version-control

LightCC05 авг. 2020, в 17:54

Источник

0

«Однако я не могу этого сделать, потому что коммит C включает ремастер, некоторые исправления конфликтов слияния и соответствующий дополнительный код». Итак, коммит C - это слияние с другой веткой? И вы включили изменения кода в этот конфликт слияния? Не делай этого. Коммиты слияния должны включать только слияние и любые разрешения конфликтов. Делайте новые коммиты с любыми другими изменениями поверх этого слияния. Code-Apprentice 05 авг. 2020, в 18:25
0

Или коммит C - это сжатый коммит из PR из другой ветки? Если у вас все еще есть доступная ветка, используйте ее историю, чтобы получить «часть коммита c», которую вы хотите. Code-Apprentice 05 авг. 2020, в 18:26

Поделиться в социальных сетях:

Скопировать адрес страницы:

Ответы 2

Смежные вопросы

0Как не переносить изменения, внесенные в файлы, из ветки в другую в git

«Однако я не могу этого сделать, потому что коммит C включает ремастер, некоторые исправления конфликтов слияния и соответствующий дополнительный код». Итак, коммит C - это слияние с другой веткой? И вы включили изменения кода в этот конфликт слияния? Не делай этого. Коммиты слияния должны включать только слияние и любые разрешения конфликтов. Делайте новые коммиты с любыми другими изменениями поверх этого слияния.
Или коммит C - это сжатый коммит из PR из другой ветки? Если у вас все еще есть доступная ветка, используйте ее историю, чтобы получить «часть коммита c», которую вы хотите.

Code-Apprentice · Answer 1 · 2020-08-05T15-28-47.000Z

I need to merge commit A and part of commit C

Коммиты - это основная единица git. Вы не можете ничего сделать с «частью» коммита, включая слияние. Вам нужно будет отредактировать свою историю, чтобы разбить коммит C на более мелкие части, чтобы вы могли выбирать, что идет в других ветках. Вы разделите сgit rebase -i а затем в основном отмените фиксацию C и создайте новые коммиты C1, C2 и т. д. с меньшими частями, которые вы хотите.

В будущем я предлагаю вам создать новую ветку для каждой функции. Вы можете создавать небольшие коммиты в этой ветке по мере работы над этой функцией. Я предлагаю делать небольшие сплоченные коммиты во время работы. Затем, когда функция будет завершена, объедините ее сmaster или какое-то другое «стволовое» ответвление. Не следует просто фиксировать всю большую функцию как одну фиксацию.

If I just copy and paste the relevant code and make a PR into Branch 3 will I have issues later on when Branch 1, Branch 2, and Branch 3 are all eventually merged into master?

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

LightCC · Answer 2 · 2020-08-05T15-14-48.000Z

Вот мой совет:

Создайте новую ветку:feature_commit_c вmaster (похоже, этоbranch 3 )
Слить коммит C (там ветка не нужна, используйте хеш) вfeature_commit_c чтобы сделать свой первый коммит в этой ветке.
Внесите любые необходимые изменения, относящиеся к «только части фиксации C». Тестируйте, готовьте, делайте любые другие обновления и новые коммиты.
Создайте PR от новой ветки доmaster
Полный обзор PR по требованию команды
Слияние сmaster

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

Обратите внимание на другие ваши вопросы

Git просто смотрит на текст, он не знает, откуда он взялся. Если он такой же, то разница не покажет. Итак, как вы управляете внесением частичных изменений из C (прикрепляете ли вы их к A с помощью копирования / вставки или выборочного сброса файлов из фиксации C), зависит от вас.

После того, как вы объедините A и завершите свои частичные изменения C, разница между ветвью acd и вашей новой ветвью должна быть только остальной частью C и всем D.

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