tgoop.com/dev_easy_notes/235
Last Update:
{1/2} Немного отойдем от разговора о языке и поговорим о инженерных практиках, а конкретно про работу с гитом. Так уж получилось что если говорить о гите, то у нас два стула, основных подхода как можно с ним работать (нет шутка про стулья меня еще не заебала): • Старый дедовские Git Flow • Адекватный Trunk Base
Все остальные системы ветвления так или иначе сводятся к этим двум. Подробно разбирать тонкости я тут не буду, лишь обозначу по верхам в чем суть.
В Git Flow, есть ветка dev, ветка master и ветки(feature/bug/tech). Разработка ведется в ветках feature, которые начинаются всегда от dev. В ветке feature мы разрабатываем фичу, затем на этой же ветке ее тестируем и после сливаем в dev. В момент релиза мы из ветки dev делаем ветку release, проводим всякие регрессы, делаем небольшие фиксы, если нашли баги. Затем мержим ветку release в master и в dev. При этом в момент мержа в мастер ставим tag с версией релиза. Чтобы в случае чего мы могли быстро к нему откатится и все такое.
Проблемы у подхода в том, что он излишне формальный. Куча движений нужно как на релиз, так и на простую задачу. Git Flow не выдерживает большого количества людей в команде. Долгоживущие ветки, вероятно будут приводить к конфликтам, которые придется часто разруливать. Код ревью таких веток может и будет длиться вечность.
Этот подход хорош тогда, когда у нас продукт в котором очень важно выпустить очень сильно протестированное ПО. Или у нас вообще сложная доставка нашего ПО, вроде того как раньше распространяли все через диски. В веб разработке и в частности в мобильной ПО уже давно доставляется через инет.
BY Dev Easy Notes
Share with your friend now:
tgoop.com/dev_easy_notes/235