Перезаписать ветку изменениями из другой ветки

Question

Здравствуйте, товарищ git пользователи!

У меня возникла следующая проблема, и я не знаю, как лучше и правильнее ее избежать. Итак, здесь я объясню:

Я работаю с 2 разными ветками:

• master -> production

• dev -> разработка

В настоящее время я использую следующий рабочий процесс:

1. Изменения внесены в dev ветку
2. Изменения протестированы и одобрены
3. Оформить заказ master и объединить dev, чтобы включить новые изменения

Пока ничего сумасшедшего, правда?

Сейчас , через несколько недель появился следующий сценарий go:

1. Изменения внесены в dev ветку

2. Изменения протестированы и утверждены

3. Оформить заказ master и объединить dev, чтобы включить новые изменения

4. Кто-то понял, что часть этих изменений не должна быть в master (производство)

5. В master ветке мы прокомментировали эти изменения, поэтому они не включены в master

Текущая ситуация:

• Все изменения в dev

• Все изменения в master, но часть из них отключена

• Пока все хорошо

Несколько дней спустя произошло следующее:

1. В * 1088 были добавлены еще несколько изменений *

2. Изменения были протестированы и одобрены

3. Оформить заказ master и объединить dev, чтобы включить последние новые изменения и также часть изменения, которая теперь комментируется в master.

4. В результате все включено в master , но изменение, которое было прокомментировано по-прежнему прокомментировано в master.

Сначала я ожидал, что master будет перезаписан версией dev, но затем Я понял, что это не имеет особого смысла, поскольку слияние фактически объединяет изменения из обеих веток, поэтому результат имеет абсолютный смысл. Однако это не то, что мне нужно.

Что было бы лучшим решением для этого? Я думал о следующих вариантах:

1. Полностью запретить вносить изменения в ветку master. Таким образом, любое изменение (например, комментирование части кода) должно быть выполнено сначала в dev, а затем с go на master.

2. При слиянии с master для использования параметр, говорящий: игнорировать все изменения в текущей ветке и просто брать все, что идет из dev ветки . Это было бы здорово, и, очевидно, я не знаю, как это сделать в git.

В любом случае, ваши комментарии будут очень признательны.

Спасибо!

Answer 1

Прочтите, пожалуйста, на GitFlow оригинальный блог Винсента Дриссена об этом .

Здесь не хватает того, что вы сделали коммиты непосредственно в master. Никогда не делай этого! :)

У вас есть несколько вариантов, в зависимости от конкретной ситуации, но если вы следите за GitFlow, вот ответ:

1. Когда будете готовы к выпуску, сделайте release_xxx ветка, которая, по сути, является кандидатом на выпуск для новой версии.
2. Используйте выпускную ветвь во время интеграции и тестирования системы с другими репозиториями / кодом и т. Д. c.
3. Если требуется изменение, сделайте его до release, но затем объедините это изменение с dev.
4. Когда release полностью протестирован, слейте его с мастером, завершив его.

Если вам обычно не требуется какое-либо дополнительное время для ветки выпуска, вы можете создать ветвь hotfix, которая после тестирования будет объединена как с master, так и dev. Ветви исправлений обычно предназначены для производственных проблем из того, что уже выпущено в производство - это похоже на ветвь функций, которая сливается с dev, за исключением того, что предназначена для прямого слияния обратно с master (в дополнение к dev, поэтому все ветки разработки получают

Это позволяет продолжить параллельную разработку в dev без необходимости вставлять sh новые вещи с dev в master, оставляя только те изменения, которые необходимы для исправление должно произойти в ветке release или hotfix, и вы можете управлять его перемещением обратно в dev отдельно, чтобы убедиться, что оно включается в любую параллельную работу.

Credit: Vincent Driessen

Для решения текущей проблемы

Вы должны объединить master в dev, устранить все различия (т.е. добавить или удалить комментарии и т. Д. c.), А затем снова объединить *1047* в *1048*. 1049 *. Если вы просто хотите очистить, вы можете сделать это и направить pu sh на освоение, но лучше иметь PR с обзором коллег в dev, чтобы обеспечить отслеживаемость и четко показать, что было сделано в истории git .

Answer 2

Это то, что вы должны были сделать

Вы должны были объединить свои master с dev (своего рода исправление, и это нормально) сразу после того, как вы внесли изменения в master.

Затем на dev вы должны были отменить фиксацию (git revert commit-id), которая закомментировала вещи в master.

Затем, когда вы перешли к слиянию dev в master снова, все будет хорошо.

Теперь, когда все пошло дальше, вы можете:

1. [НАИЛУЧШИЙ ПОДХОД] попробовать описанные выше шаги; если изменения, сделанные в dev, недостаточно глубоки и / или не касаются тех же мест, что и фиксация , скорее всего, все будет правильно; или

2. в master ветке go для возврата (git revert) фиксации .