Рабочий процесс Git: разъяснение и обход антипаттернов

Question

Я нахожусь в процессе разработки рабочего процесса Git для проекта веб-приложения, над которым я работаю. Я использовал Git в течение нескольких лет, но только как сольный разработчик. Я собрал набор процедур вместе, и вчера наткнулся на эту статью на HN: http://sandofsky.com/blog/git-workflow.html

На основании статьи я скорректировал свои процедуры и был бы признателен за некоторые отзывы. Я хочу убедиться, что я правильно истолковываю статью и не помогаю решать проблемы в будущем. Исходя из рассматриваемой статьи и желания обеспечить хорошие рабочие стандарты, есть ли проблемы со следующими процедурами?

---

Основы

• основная ветвь - основная, рабочая ветвь, в которой весь код развитие объединено. Это представляет самые последние дополнения к кодовая база из отдельных веток разработки.
• ветки 'dev_' - Локальные, частные ветки разработки должны использоваться для разработки новых функции. Если вам нужно подтолкнуть ветку на сервер (так что вы можете легко переключаться между компьютерами) убедитесь, что ветка dev name включает имя пользователя, например, dev_andy_authentication.
• промежуточная ветвь - перед развертыванием определенного кода из основной ветки, код должен быть протестирован в среде, которая соответствует производству окружающая среда как можно ближе. Код из мастер ветки есть объединены в промежуточную ветку, протестированы и после прохождения тестов право на производство.
• производственная ветвь - Стабильный код из промежуточной ветки интегрируется в производственную ветвь, помечается номером версии выпуска и затем развертывается на рабочих серверах.

---

Разработка

Филиал: мастер

• Используйте локальные, частные ветви функций для разделения кода:
  • Переключиться на ветку 'master': git checkout master
  • Создать новую частную ветвь функций: git checkout -b dev_newfeaturename
  • Внесение дополнений в функции.
  • Стадия изменений: git add.
  • Подтвердить изменения в «dev_newfeaturename»: git commit -m «commit description»
• Чтобы интегрировать изменения из ветки 'dev_newfeaturename':
  • Переключиться на «главную» ветку: git checkout master
  • Проверка удаленных изменений в «master»: git pull --rebase origin master
  • Если изменения в ветке 'dev_newfeaturename' относительно невелики:
    • Интегрировать изменения из ветки dev_newfeaturename в master: git merge --squash dev_newfeaturename
    • Напишите подробное сообщение о внесении изменений, внесенных из ветки 'dev_newfeaturename': git commit -v
  • Если изменения в ветке 'dev_newfeaturename' являются более сложными, требуя, чтобы в истории оставалось несколько коммитов:
    • Переключиться на ветку «dev_newfeaturename»: git checkout dev_newfeaturename
    • Реинтегрируйте любой измененный «главный» код в ветку «dev_newfeaturename»: git rebase --interactive master
    • Чтобы очистить историю путем объединения коммитов, измените операцию с «выбора» на «сквош», которая раздавливает второй коммит в первый
    • Переключиться на ветку 'master': git checkout master
    • Push-изменения на удаленном «master»: git push origin master
  • Проверьте наличие удаленных изменений в «master»: git pull --rebase origin master
  • Передать все изменения в 'master' обратно на сервер: git push origin master
• «Мастер» становится рабочим деревом всех разрабатываемых в настоящее время функций.
• Периодически извлекать «основные» изменения с удаленного компьютера: git pull --rebase origin master

---

Постановка

Филиал: постановка

• После того, как запланировано выпуск определенного количества функций / исправлений ошибок, убедитесь, что «мастер» функционирует должным образом, затем объединитесь в «этап»:
  • Переключиться на ветку 'staging': git checkout staging
  • Интеграция изменений из «master» в «staging»: git merge --no-ff master
  • Push 'staging' для удаленного репо: git push origin staging
• Развертывание «промежуточной» ветки на промежуточном сервере и тщательное тестирование - промежуточный сервер должен максимально точно реплицировать производственную среду.
• Если какое-либо тестирование не пройдено, вернитесь в ветку «master», исправьте все связанные проблемы и перезапустите промежуточный процесс.
• Если все испытания пройдены, переходите к производственному процессу.

---

Производство

Отрасль: производство

• Как только код в промежуточной ветке был протестирован и пройден, переключитесь на ветку «production»: git checkout production
• Интеграция изменений из 'staging' в производство: git merge --no-ff staging
• Код тега с номером версии последовательного выпуска: git tag -a 0.1
• Push 'production' для удаленного репо: git push origin production
• Разверните «производственную» ветку на производственном сервере и протестируйте, чтобы обеспечить правильное развертывание.

Answer 1

Вы писали:

Если изменения в ветке 'dev_newfeaturename' более сложны, для сохранения нескольких фиксаций в истории:

• Переключиться на 'dev_newfeaturename 'branch: git checkout dev_newfeaturename
• Реинтегрировать любой измененный код' master 'в ветку' dev_newfeaturename ': git rebase --interactive master
• Чтобы очистить историю путем объединения фиксаций, измените операциюот «пика» до «сквоша», в результате чего второй коммит попадает в первый
• Переключение на ветку 'master': git checkout master
• Перемещение изменений в удаленный режим * master ': git push origin master

Я думаю, что вы забыли о быстром слиянии 'dev_newfeaturename' в 'master':
Перебазировка позволяет вам воспроизвести 'dev_newfeaturename 'поверх' master ', очистка коммитов в этом процессе.Это хорошо.
Но если вы хотите отодвинуть мастер назад к удаленному, мастеру нужны эти очищенные коммиты в его истории: `git merge dev_newfeaturename

---

Относительно ветви на состояние разработки (этап,prod), я бы не рекомендовал такой подход, если вы не производите новые коммиты в этих ветках.
Помните предложение о no-ff в статье, на которую вы ссылаетесь:

Единственное, что осталосьаргументом для –no-ff является «документация».
Люди могут использовать коммиты слияния для представления последней развернутой версии производственного кода.
Это антипаттерн.Используйте теги .