Как происходит работа с Git в крупных проектах?

Question

[The_good_game]

Я не совсем понимаю принцип работы с Git в моём проекте.
В проекте имеются ветви: master, dev, release и features. Я создал feature от master и, при попытке слияния с dev, вижу, что моя ветка отстаёт от dev на 200 коммитов и имеет множество конфликтов слияния. Как я понимаю, это значит, что ветки qa и master сильно разошлись. Я не могу сделать rebase feature branch от dev, поскольку после тестирования мне нужно будет замержить её в release, которая на данный момент является копией master.
Разве такие конфликты с веткой dev не будут происходить постоянно? Будет ли корректно скопировать мою ветку, а потом сделать rebase от dev для тестирования (но я не уверен, что тестирование будет корректным, если ветки уже разные)?
Я ни разу не работал с Git в команде и в крупных проектах, поэтому не знаю, что нужно делать.

Answer 1

[mayton2019]

Я ни разу не работал с git в команде и в крупных проектах, поэтому не знаю, что нужно делать.

Тебе и не нужно это знать. И мы не сможем перечислить все роли и задачи участников на проекте и все их возможные комбинации поэтому заранее рассказывать об этом бесполезно.

Git - это просто инструмент. Но как делается review или кто его делает. Или голосуют. Или мержат или ребейзят.
Или создают теги или бранчи. Или сколько делают осей разработки master/trunk, dev/stg/prod - это все частные договоренности. GitFlow, GitLabFlow. Интеграция Atlassian. С Gerrit. Это все-все частные случаи управления версиями кода на частных проектах. Нету общих рекомендаций.

Узнать их можно на проекте. Пришел. Прочитал Developers process guide. И начал работать.

А управление процессами разработки с помощью Git это большая и частная тема.

Поэтому оставь в покое крупные проекты. И лучше задай просто про git. Про команды git например.

Answer 2

[Saboteur]

В проекте имеются ветви: master, dev, release и features. Я создал feature от master и, при попытке слияния с dev, вижу, что моя ветка отстаёт от dev на 200 коммитов

Тогда может надо было создавать feature от dev, а не от master?
или выяснить почему ваш dev так отстает от master

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

200 коммитов разницы это довольно много, или слишком долго висел feature или реально бардак в проекте.

Answer 3

[SymphoGraph]

Есть такая штука - культура разработки. Для каждой команды она своя.
Когда команда сыграна, она может себе позволить отказаться от GitFlow в пользу Trunk-based и даже пушить в мастер.
Поэтому, если команда ищет человека с определёнными профессиональными навыками, маловероятно, что знание внутрикомандной культуры разработки будет важным критерием.
Однако, чем чаще коммитятся и пушатся изменения, тем лучше.

Answer 4

[Михаил Ливач]

Предположу, что в показанной Вами схеме в ветку release идут только мержи от master, в ветку master - только мержи от dev, а вот в dev создаются feature-ветки. Тогда это имеет смысл