Git слияние указанных коммитов

Question

В классическом ветвлении TFVC; все проверки разработки вносятся в ветку DEV. И когда разработчик хочет отправить свои изменения в среду TEST, он объединяет свои изменения с веткой TEST. И когда он хочет отправить эти изменения в производство, он объединяет свои изменения с веткой PROD. Он вручную выбирает эти изменения в графическом интерфейсе TFS. Этот метод хорош тем, что " Если я не объединю свое изменение, я уверен, что оно не будет развернуто в соответствующей среде ".

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

В Git, как я могу создать стратегию ветвления, чтобы я мог выбрать, какие коммиты объединить?

Answer 1

Просто чтобы добавить несколько комментариев к превосходному ответу @ jessehouwing.

Существует множество религиозных высказываний "сбор вишни - это не мерзкий путь".Совершенно верно, что git merging работает лучше в git, на самом деле это будет проще в любой системе контроля версий из-за проблем с конфликтами файлов, которые могут возникать гораздо легче при неправильном выборе вишен.Но только то, что что-то проще, или потому что это работает для определенных рабочих процессов с открытым исходным кодом, не означает, что это единственный способ или даже то, что он по своей сути лучше.

Маршрут выбора вишни определенно сложнее,и вы должны быть уверены, что ваши процессы по какой-либо причине нуждаются в такой дополнительной сложности.Иначе это точно не стоит.Но если вы это сделаете ...

Самая большая проблема со сбором вишни, которая, к сожалению, не обсуждается в статье Microsoft, заключается в том, что вы гораздо чаще сталкиваетесь с конфликтами.Несколько изменений изменяют одну и ту же строку кода, и вы пытаетесь портировать их не по порядку ... конфликты.Если вы большая организация, вы можете столкнуться с этим лотом .Совет, который я бы дал вам на данный момент, таков:

1. Вы не можете разрешить разрешение конфликтов вручную.Это потому, что если у вас есть одно ручное разрешение конфликта, ветки источника и назначения различаются, и вы только что усугубили свои будущие проблемы конфликта.Вместо этого вам нужно убедиться, что любые «блокирующие» коммиты сначала выбираются из ветки назначения.(*)
2. Вам нужно будет создать инструменты для автоматической попытки выбора всех возможных коммитов, выявления потенциальных блокирующих коммитов и обеспечения того, чтобы все блокирующие коммиты в цепочке были «готовы к работе» (независимо от того, что определено в вашемпроцесс).(Человек, которому поручено выполнить эту работу, будет быстро ошеломлен.)

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

(*) В зависимости от вашего рабочего процесса это может быть невозможно.Если что-то не было готово к сбору вишни, потому что это, к примеру, еще не требует одобрения регулирующих органов.Но если это всего лишь «тестер еще не проверил его», то его следует поощрять к тестированию как можно скорее.

Answer 2

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

Однако шаблон ветвей уровня продвижения немного устарел и не очень хорошо подходит для распределенной природы Git (в мире управления распределенными версиями, в какой среде, где слили код, где в мире). Вы можете посмотреть на ряд других моделей. Имея возможность выполнять двоичное продвижение (используя одни и те же байты для запуска в DEV, TEST и PROD), контейнеризацию (где даже инфраструктура хоста движется по этому пути), Infra как код и Config как код, позволяющие легко раскручивать среды, не нужно полагаться только на конвейер через фиксированный набор сред; это и способность git изолировать более мелкие ветви функций гораздо проще, чем в TFVC, старая модель ветвей уровня продвижения больше не соответствует требованиям. Извините; /

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

GitHub также выпустил документацию по процессу ветвления / слияния. Они назвали это GitHub Flow .

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

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