Pull to refresh

Comments 6

А еще есть замечательный Gitlab flow.
В итоге мы ушли со всех своих велосипедов и используем суперпозицию релизных и env бранчей.

Gitlab вводит env бранчи для случая, когда вы не контролируете процесс поставки. Например в случае мобильного приложения и его поставки в апстор. В любом ином случае, я считаю, что env окружения это плохая практика.

Следовательно, мы не можем сказать, что использовали именно Git Flow.

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

1. Для реализации берется существующий процесс, тем самым сокращаем время на проектирование и “слепо” следуем процессу.
2. То на что Вы акцентировали внимание, берется процесс, который либо сразу, либо не сразу адаптируется под нужды проекта.
3. Изначально строим процесс под нужды проекта.

И в данном случае различие между вторым и третьем подходе в том, что сначала появился GIT как продукт, а затем начали создаваться процессы для удобства, введения “best practices”, экономии времени и т.д. Следовательно чаще всего, мы используем объекты GIT, для постройки максимально подходящего рабочего процесса под нужды проекта. 

Поэтому, не могу сказать, что в нашем случае так говорить лучше.
Объяснения понятны.
Хотя мне в в статье понравились хорошие иллюстрации базовых понятий Git'a: tagging, btanching, merging, за что Вам спасибо!))
Sign up to leave a comment.