Что такое версионные ветки на GitHub?

Вот краткое объяснение того, как работают ветки и теги и как их лучше всего использовать.

1. Филиалы

Филиалы позволяют разделить ваш код на разные потоки разработки. Изначально вы начинаете с одной основной ветки (будь то master, trunk или другие распространенные имена). По мере развития вашего проекта вам нужна определенная стабильность во время разработки.

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

2. Теги

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

3. Работа с филиалами и освобождение от них

Представьте, что у вас несколько клиентов. Предположим, ClientA заключил с вами контракт, по которому они будут платить за использование версии 1.2.3, а ClientB - новый клиент, заинтересованный в вашей новаторской работе над некоторыми функциями в версии 2.x что ClientA не так сильно превозносится и поэтому не желает переходить на него. В вашем контракте указано, что каждый клиент получает обслуживание в течение года после оплаты ваших лицензий. Да, обычно компании должны подталкивать своих клиентов к обновлению до более новых версий своих продуктов / услуг, но довольно часто клиентами являются крупные организации, в которых темп работы и принятия решений намного медленнее, чем хотелось бы.

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

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

3.1. Ветвление и тегирование в среде с несколькими ветвями

Предположим, у вас есть следующие ветки:

• master: последняя разработка (3.x)

• 1.x: для ваших клиентов, которые настаивают на использовании более старых версий вашего кода

• 2.x: для более актуальных клиентов.

Ветвь 1.x будет использоваться для освобождения 1.x-SNAPSHOT - ов; 2.0 для 2.x-SNAPSHOT и мастера - за вашу еще неизданную работу над 3.x. Обычно рекомендуется иметь ветку для каждой основной версии, которую вы активно поддерживаете. Для несовершеннолетних вы должны отделиться от этой ветви (например, версия 2.0.3 будет от ветви 2.0.x). Когда ваша работа над данной итерацией функций считается завершенной и достаточно стабильной, вы создаете тег в этой ветке для версии, находящейся в разработке, и переносите версию вашей текущей разработки на следующую вспомогательную версию. Я говорю абстрактно, поскольку вы не упомянули, какой инструмент сборки вы используете. В случае Maven, например, версия, которая сейчас находится в разработке, будет SNAPSHOT, и если ваша текущая выпущенная версия была из ветки 2.x, а ваша разрабатываемая версия была 2.3-SNAPSHOT, то ваша недавно выпущенная версия будет будет 2.3, а ваша следующая разрабатываемая версия будет 2.4-SNAPSHOT.

Надеюсь, теперь все это имеет больше смысла.