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

Question

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

На общем репо, у нас есть эти ветви:

-master 
-feature 

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

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

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

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

3) Включите функцию ветвь в интеграции отрасли, и есть разработчики используют свои собственные независимые ветви функций с перебазирования, чтобы держать вещи в своем уме.

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

Answer 1

Для общей ветви я бы пошел с № 3 и использовал ее как ветку «интеграции» для консолидации своей работы.
Разработчики должны использовать Rebase постоянно переигрывать свою private ветвь на вершине feature до слияния обратно свою работу feature, таким образом они являются:

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

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

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

Answer 2

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

Answer 3

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

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

Возможно, было бы разумно, чтобы люди возвращали очередь патчей обратно в ветвь свойств локально.

Answer 4

Гит Поток операций для Feature ветви

Процесс следующим образом: -

В первый раз:

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

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

• Откроется филиал с именем sprint-4 на нашем локальном компьютере.

• Вытащите файлы с сервера на наш ветвь спринт-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 pull 
git merge dev 

разрешения конфликтов, если какой-либо

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

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