Правильный рабочий процесс Git для ветки общих функций?

Question

Я пытаюсь определить правильный рабочий процесс для этой ситуации:

В общем репо у нас есть следующие ветки:

-master
-feature

Ветвь feature является веткой shared , так как многие разработчики совместно работают над новой функцией. Они активно продвигают свои изменения в ветви функций.

Я пытаюсь избежать «ада конфликта» в тот день, когда функция наконец-то снова объединится с master . В данный момент вижу несколько вариантов:

1) Активно объединить master в feature и делать это часто. Однако это не рекомендуется в git docs, и я начинаю чтобы понять почему. Когда я пытаюсь это сделать, мне кажется, что я снова и снова решаю одни и те же конфликты.

2) Как-нибудь использовать rebase. Я читал об этом, но похоже, что он не будет работать, поскольку ветвь feature фактически используется совместно. Все, что требуется, - это один разработчик, чтобы выполнить 2 ребазинга, а у других разработчиков могут возникнуть конфликты из несоответствующей истории.

3) Превратите ветку feature в интеграционную ветвь, , и пусть разработчики используют свои собственные независимые ветки Feature с перебазированием, чтобы сохранить разумность.

4) Что-то совершенно другое?

Answer 1

Для общей ветки я бы выбрал # 3 и использовал бы ее как "интеграционную" ветвь для консолидации своей работы.
Разработчики должны будут использовать rebase, чтобы постоянно воспроизводить свою ветвь private поверх feature, прежде чем объединить свою работу с feature, таким образом:

• решение любого конфликта слияния локально (в своем репо)
• превращение окончательного слияния (от их private ветви до feature) тривиального (обычно быстрая перемотка вперед)

(как описано в "git rebase против merge" ответ)

Идея заключается в том, что после объединения feature в master вклад больше не принимается в feature (ветвь «заморожена»), и вы можете безопасно перебазировать его поверх master сначала или объедините его непосредственно с master.
А затем вы запускаете новую ветку feature (которая может фактически начинаться параллельно предыдущей ветви feature, если необходимо)

Answer 2

Вы можете использовать rerere для обработки конфликтов слияния, которые вы видите несколько раз.

Answer 3

Рабочий процесс Git для ветви функций

Процесс выглядит следующим образом: -

Первый раз:

git pull
git checkout -b sprint-4
git pull origin sprint-4

• Приведенные выше команды извлекут все файлы из git

• Создадут ветку с именем sprint-4 на нашей локальной машине.

• Перетянет файлы с сервера в нашу ветку sprint-4.

Для каждой новой функции: -

git checkout -b <feature-branch>,  example: git checkout -n fer-181
git push -u origin <local-branch>:<remote-branch>, example git push -u     
origin fer-181:fer-181

• Создайте удаленную ветку для этой локальной ветки на сервере.
• Переместит файлы из нашей локальной ветки в удаленную ветку.

Ежедневно: (в вашей ветке функций)

git pull
git merge dev

• разрешать конфликты, если таковые имеются

• выполнять свою работу в течение дня

  git pushorigin

Функция завершена:

git pull
git merge dev

разрешить конфликты, если таковые имеются

git checkout dev
git merge <feature-branch>
git push origin dev

• ВышеКоманды объединят файлы из основной ветви в нашей ветви функций.
• Устраните конфликты в нашей ветви функций, если таковые имеются.
• Объедините файлы из ветви компонентов в основную ветвь.

Answer 4

(Я не слишком заинтересован в вариантах 1, 2 или 3, поэтому я пытаюсь найти лучший рабочий процесс; поэтому ниже я описываю, как я подхожу к проблеме в надежде, что кто-топосоветуете мне)

1. Превратите ветку функции в очередь исправлений, используя один из инструментов очереди исправлений git.
2. Использование отдельного репозитория git для управления версиями очереди исправлений
3. Использование обычных подходов git для совместной работы в очереди исправлений.

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