Языки программирования

Стратегия во время роботы с git

Если мы уже начали работать с git, то давайте наиболее эффективно использовать его главное достоинство — ветки.

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

master — это основная ветка, которая содержит исключительно релизные версии, которые находятся в режиме онлайн. Их помечаю тегами (tag) вместе с датой заливки и версией релиза (1.0, 1.0.1). От номеров версий — плохо информативных, я решил отказаться. Если при каких-то обстоятельствах на «боевом» сервере что-то сломалось (баг в логике и т. д.), то можно без проблем переключится на master. Далее делаем с него ветку, потом фиксим баг, после чего мержим обратно (плюс еще в другие ветки, чтобы в дальнейшем не пришлось фиксить тот же баг).

develop — это главная «девелоперская» ветка. Она показывает стабильное состояние разработки, оно в дальнейшем уйдет в релиз и потом будет смержено в master.

dev/* — это ветки предназначенные для отдельных фич. Многие из них являются локальными и не попадают в основной репозиторий. В них разрабатываются новые конкретные фич игры. Это может быть либо большой патч, который может вырасти до месяца и больше, либо вообще маленькие изменения на 1 или 2 комита.
fix/* — являются локальными ветками срочных фиксов. Они часто возникают от master и намного реже от develop. Они сразу мержаться туда куда нужно.

release — это временная ветка, предназначенная для релиза, которая в дальнейшем войдет в master и потом будет удалена. Она в нужное время бранчится (вливается) с develop, после чего в нее вносятся необходимые изменения (правки) перед этапом заливки.

Давайте рассмотрим алгоритм работы:

  • почти для каждого изменения заводится специальная «девелоперская«(dev/*) ветка, которая в итоге будет смержена в develop, либо ее удалят за ненадобностью;
  • ветки с большими изменениями уходят в центральный репозиторий, а мелкие в основном остаются у разработчиков. Я стараюсь контролировать слияние больших фитчей и просматриваю, при этом, все проделанные изменения. На этом этапе довольно удобно отсекать ненужный говнокод;
  • когда подготавливается релиз, соответственно, создается и ветка release, которая в дальнейшем мержится в master. Далее в ней происходят временные изменения, которые больше нигде не нужны. К примеру, когда в определенном релизе необходимо спрятать кнопку, так как функционал в настоящее время пока не готов. В процессе этого этапа лучше не иметь больших багов, так как нужно будет делать отдельную ветку с фиксами этих багов и переключатся в дальнейшем между ней и release. Когда заливка закончена, то release мержится в master и удаляется. Данное состояние master помечается тэгом вместе с датой заливки. В дальнейшем разработка продолжается.

В наше время множество разработчиков успешно пользуются технологией git-flow. Эта технология мне очень нравится, но это лично мое мнение. Хотя я все-таки рекомендую вам ознакомится с этой технологией, здесь, и в дальнейшем автоматизировать свою работу с git в целом.