Работа с большим запросом тяги

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

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

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

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

Как лучше всего справиться с такой ситуацией, когда одна ветвь действительно далеко от других?

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

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

Чтобы ответить на буквальный вопрос: лучший способ справиться с такой ситуацией - не попасть в такую ​​ситуацию.

Какими способами мы можем избежать того, чтобы ветки получали очень большое количество коммитов от мастера в будущем?

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

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

«Если вы объединяетесь каждый день, внезапно вы никогда не дойдете до того момента, когда у вас будут огромные конфликты, которые трудно разрешить». - Линус Торвальдс

Это цитата из его выступления в Google, вот стенограмма и видео .

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

Если у вас есть какие-то коммиты, которые вы хотели бы объединить, но они чередуются с другими коммитами, которые не готовы к производству, то я вижу 2 возможности:

1. Создайте новую ветку, и черри выбирайте хорошие коммиты, сливайтесь с мастером.
2. Попробуйте перебазировать нежелательные коммиты наверх (возможно, в новой ветке просто для безопасности).

Что касается методов профилактики, попробуйте определить некоторые забавные правила команды, такие как «Тот, кто не слился с хозяином в течение недели, закажет пиццу на месяц».

Во-первых, посмотрите, есть ли на самом деле отдельные коммиты, которые можно объединить или выбрать из вишни, как предложено @Maciej Chalpuk. Если это так, то ситуация на самом деле не так уж и плоха, и я не буду слишком беспокоиться об этом в будущем.

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

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

Вот простое решение.

Отслеживайте функции, реализованные этим человеком, и переходите к каждому коммиту в той ветви, которая была обновлена ​​для каждой функции. Возьмите этот коммит и объедините его с мастер-репо.

Позвольте мне привести это в пример.

Пусть: Ветвь A будет ветвью от основной ветки A + = Ветвь A + новая функция 1 Ветвь A ++ = Ветвь A + новая функция 2 и так далее и так далее

Что вам нужно сделать, это вернуться к: Филиал А +

Возьмите Ветвь А + и объедините ее с Мастером.

Теперь перейдите к ветке A ++ и объедините ее с (Master + Branch A +).

Повторяйте, пока не дойдете до последней стабильной ветви A + ... +.

Поначалу этот метод может показаться нелогичным, но если вы объединяете каждую отдельную новую функцию самостоятельно с мастером, становится легко переключаться между основной веткой «для каждой добавленной функции »

Какими способами мы можем избежать того, чтобы ветки получали очень большое количество коммитов от мастера в будущем?

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

Я бы предложил использовать подход:

предварительный мастер и мастер

мастер: финал / уровень производства. Модифицируется не часто. Считается всегда стабильным

pre-master: область, где новая функция добавляется в существующий код. Тщательно протестирован для работы с существующей кодовой базой и является местом, где другие ветки могут раскошелиться для реализации новой функции.

Вам также следует попробовать объединить функции и ориентироваться на версию.

Ориентация на версии. Укажите произвольное число, которое будет заполнять главную ветвь. «В версии 1.0.0 мы хотим реализовать функции X, Y, Z. В версии 1.0.0 также будут доступны все эти функции: ...»

Поддерживая версию против master, она также может быть способом поддержания стабильности «master» и готовности к производству в любое время.

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

Если вы работаете в рамках Agile или SCRUM, команде действительно следует спросить, почему эта функция не была завершена и объединена как часть итерации / спринта. Если он был «слишком большим», чтобы поместиться в итерации, его следовало бы разбить на более мелкие куски.

Это также поднимает вопрос о владении кодом - в вашей команде отдельные разработчики владеют своей собственной работой по отдельности, или вся команда работает вместе, чтобы обеспечить выполнение заданий?

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

Во многих отношениях это становится вопросом процесса. Может быть, ваш необходимый процесс включает в себя периодическую (еженедельную? Ежемесячную?) Проверку на наличие долгосрочных, непогруженных веток. Некоторые инструменты упрощают визуальную проверку; например, на github перейдите по ссылке "ветки", и она показывает, насколько далеко впереди / позади каждая ветка.