Ветвь разработки и тестирования в модели ветвления Git @nvie?

Я читал о модели ветвления git @nvie и gitflow, и я думаю, что это хорошая модель для использования в проекте (веб-приложении), над которым я сейчас работаю.

Я-ведущий разработчик проекта, и я развиваюсь в локальной среде (MAMP-like). Всякий раз, когда я делаю что-то, чтобы показать клиенту, Я поручаю свою работу и передаю ее центральному хосту Git. Оттуда я разворачиваю его на сервере, подключенном к интернету. Тогда мой клиент сможет увидеть изменения.

A второй разработчик только начал работать над проектом. Он разрабатывает отдельные функции за один раз и передает их центральному хосту Git, когда они готовы. Я просматриваю его работу, прежде чем развернуть ее.

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

У меня есть следующие вопросы:

  1. Я часто работаю над несколькими задачами одновременно. Когда часть функции готова, я иногда хочу показать ее своему клиенту, прежде чем продолжить работу над этой функцией. Однако, насколько я понимаю, особенность (ветвь) будет объединена в develop только тогда, когда она будет завершена и запланирована к выпуску. Как я могу показать клиенту (в среде разработки) функции, которые находятся в стадии разработки (или еще не запланированы к выпуску)?

  2. Из какой ветви следует выполнить развертывание в среде тестирования? Должен ли я вручную выбрать ветвь выпуска этого момента, или может быть выделенная ветвь тестирования?

2 2
version-control branch git-flow

2 ответа:

Вот мой взгляд на это:

  1. Вы можете развернуть ветвь функций, которую хотите показать среде разработки. Просто не забудьте развернуть ветку разработки после того, как клиент увидит новую функцию.

  2. Для среды тестирования используется ветвь release. После завершения периода тестирования и выпуска приложения вы развернете главную ветвь в среде тестирования до следующего выпуска график.

Отказ от ответственности : я являюсь разработчиком git-flow (AVH Edition)
Что вам нужно помнить, так это то, что оригинальное программное обеспечение gitflow не удаляет удаленные функции и выпускает ветви. Поэтому, когда вы заканчиваете функцию или выпуск с оригинальным gitflow, вам нужно вручную удалить удаленные ветви. В git-flow (AVH Edition) Об этом заботится программное обеспечение.

3

Ветви функций могут быть переключены в любое время с помощью 1 команды (git checkout). Иногда (в rails, режиме разработки я поддерживаю сервер приложений и переключаю код, даже не перезапуская сервер!). независимо от того, в какой отрасли я нахожусь, я все еще нахожусь в режиме "развития".
Так что переключитесь на нужную вам ветку и продемонстрируйте ее. затем переключитесь обратно на master или любую другую ветвь, которую вы хотите.
Сначала я работал в мастер-классе в некоторых организациях, но теперь я делаю всю свою работу-функции, домашние задания или ошибки в ветви. Часто я помечаю название филиала и / или текст фиксации идентификатором из системы отслеживания (Pivotal Tracker в нашем случае).
Хитрость заключается в том, чтобы держать ветви в курсе частых git fetch'ов последнего мастера и git merge master (в то время как в ветке "тема").

Для других сред у меня есть настроенные пульты дистанционного управления, например mycoolapp-stage, и я толкаю код к ним отдельно. У меня есть около 6 различных пультов дистанционного управления для 1 Приложения, 4 из них используются для тестирования.

Что касается тестирования, то тестировщик может либо снять изменения и работать локально в среде разработки (работает как для программистов, так и для тестировщиков QA), либо он может просто использовать тестовую или промежуточную область, в которую вы отправляете код в качестве удаленного.

В целом, вы работаете в ветвях, а затем проталкиваете материал через master. Смотрите дополнительную информацию в моем ответе на процесс по адресу git branch, fork, fetch, merge, rebase и clone, каковы различия?

3