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

Question

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

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

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

ветвь 3 - новая ветка

ветка 4 (главная)

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

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

Questinos:

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

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

Answer 1

Мне нужно объединить фиксацию A и часть фиксации C

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

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

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

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

Answer 2

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

1. Создайте новую ветку: feature_commit_c at master (похоже, это branch 3)
2. Объединить фиксацию C (don Там нет необходимости в ветке, используйте ha sh) в feature_commit_c, чтобы сделать вашу первую фиксацию в этой ветке.
3. Внесите любые необходимые изменения, связанные с «только частью фиксации C». Протестируйте, подготовьте, сделайте любые другие обновления и новые коммиты.
4. Создайте PR из новой ветки на master
5. Полный обзор PR по требованию команды
6. Объединить на master

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

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

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

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

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