Как правильно работать с Git в команде?

Question

[Николай Фомин]

Добрый день.

Осваиваю git, решил поиграться с ветками и создать для отдельной логики в приложении свои ветки. Удаленный репозиторий хранится на Bitbucket. Собственно, проблема вот в чем: с каждой ветки я делаю pull request на master, далее на одной любой ветке merge и после этого на других ветках начинаются конфликты, потому что на них висит прошлая версия репозитория.

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

Как такие проблемы обходят в командной работе? Возможно есть какие-либо структуры веток?

Спасибо за ответы.

Answer 1

[Яков Е]

создать для отдельной логики в приложении свои ветки

Вы явно не поняли суть Git и делаете не правильно.

Вот отличный учебник.

Answer 2

[Pavel Ivanov]

После того как определенная логика будет реализована, делаете merge с мастером, а ветку по сути можно удалять. Не пойму какие у Вас конфликты возникают, Вы постоянно переключаетесь между ветками что ли?

Answer 3

[Думай Головой]

для начала нужно научиться работать с одной веткой
add
commit
pull
push
достаточно

Comments

[Макс]

checkout & revert

Answer 4

[z0rgoyok]

используем gitflow, очень довольны

Comments

[Константин Чухломин]

используем trunk-based-development, очень довольны

[el_script]

Константин Чухломин: обычно это то, от чего уходят. Можно поподробнее, как так получилось, что вы очень довольны этим?

[Константин Чухломин]

el_script: конечно.
Что у нас было: gitflow, 5 разработчиков. Пул-реквесты, тянущиеся до недели. Деплой раз в неделю.
Что мы сделали: покрыли самые рискованные/важные классы юнит-тестами.
Как сейчас: все работают в одной ветке, назовем её mainline. Перед написанием когда желательно удостовериться что этот кусок кода покрыт тестами. Вместо feature-branch у нас feature-bits/feature toggle. То есть любое изменение оборачивается в условие "если этот флаг включен в файле, тогда выполняй новый код". Соответственно если проходят все тесты, изменение становится сразу доступным на DEV и STG. Релизиться можно от любого состояния этой главной метк, прошедшего тесты (у нас – ежедневно). По-умолчанию флаг выключен на PRD. Как только QA скажут, что все работает хорошо (а они могут посмотреть как код работает с включенным флагом и без и сравнить), то мы включаем флаг на PRD, где он живет неделю, затем мы вычищаем код. Ревью проходит перед релизом на прод двумя релиз инженерами которые проверяют что все условия соблюдены: флаг можно выключить, новый код покрыт тестами. Если что-то пошло не так на проде, флаг выключается (а не версия откатывается) за секунды.
Ну и ссылки:
* paulhammant.com/2013/04/05/what-is-trunk-based-dev...
* www.amazon.com/dp/0321601912?tag=contindelive-20
* martinfowler.com/articles/continuousIntegration.html
* martinfowler.com/bliki/FeatureToggle.html