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

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

Эта статья является частью моей серии Основы разработки программного обеспечения, обязательно ознакомьтесь с моей предыдущей статьей, в которой обсуждаются ежедневные встречи Scrum, если вы ее пропустили.

Тем не менее, давайте погрузимся.

Рабочий процесс слияния просто означает, что функциональная ветка снова сливается с ветвью разработки после того, как работа сделана. На самом деле это имеет несколько немного разных значений или вариаций. Одно из решений - всегда ли создавать коммит слияния (отключив быстрое слияние). Другой вариант касается того, как обновлять функциональную ветку. Альтернативы включают слияние ветки разработки или перебазирование. В терминах GitHub рабочий процесс слияния выполняется с помощью параметров Запрос на включение слияния или Сжатие и слияние.

Запрос на вытягивание можно сжать вручную с помощью клиента git или с помощью опции GitHub «Squash and merge», чтобы объединить несколько коммитов функции в одну. Это может сделать историю версий чище.

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

«Рабочий процесс перебазирования» означает, что функциональная ветка перебазируется поверх ветки разработки после завершения работы. Преимущество в том, что фиксация слияния не создается. В терминах GitHub рабочий процесс перебазирования выполняется с помощью «Rebase and merge».

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

Любой рабочий процесс git - это командная политика, и как основные рабочие процессы, так и их различные варианты имеют своих сторонников, минусов и плюсов. Рабочий процесс слияния, вероятно, более распространен.

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

Преимущества рабочего процесса rebase включают чистую линейную историю, лишенную коммитов слияния и отвлекающих ветвлений. К недостаткам можно отнести более частое переписывание истории, что иногда (но редко) может привести к потере важной части контекста. Разработчикам также труднее понять ребейзинг. Кроме того, отменить функцию сложнее, поскольку нет единой фиксации слияния, которую можно было бы отменить.

Я предпочитаю сочетание двух рабочих процессов. Мне нравится использовать рабочий процесс rebase, если функциональная ветка содержит только одну фиксацию. В противном случае я использую поток слияния и всегда создаю коммит слияния. Эта политика пытается сохранить положительные стороны двух разных рабочих процессов, делая историю относительно чистой, но также упрощая возврат функций множественной фиксации. Обратной стороной является инструментарий - GitHub и другие не поддерживают это из коробки. Это означает, что разработчики должны помнить об использовании правильной стратегии слияния при завершении запроса на перенос.

Какой бы рабочий процесс ни выбрала ваша команда, важно, чтобы ваш рабочий процесс был последовательным и четко документированным.