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

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

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

-master
-feature

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

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

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

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

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

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

Ответы

Ответ 1

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

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

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

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

Ответ 2

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

Ответ 3

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

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

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

Ответ 4

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

Процесс следующий: -

Первый раз:

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 push origin

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

git pull
git merge dev

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

git checkout dev
git merge <feature-branch>
git push origin dev
  • Вышеупомянутые команды будут объединять файлы из основного раздела в нашей функции филиал.
  • Устранение конфликтов в нашей ветке свойств, если они есть.
  • Объединить файлы из ветки функций в главную ветвь.