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

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

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

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

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

Вопросы у меня следующие:

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

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


git branch git-flow version-control branching-strategy
person Jonathan    schedule 21.11.2012    source источник

Ответы (2)


arrow_upward
3
arrow_downward

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

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

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

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

person Peter van der Does    schedule 22.11.2012
comment
Беданкт (спасибо) за ваш ответ! Проблема с переключением между (функциональными) ветвями в размещенной среде заключается в том, что у меня нет доступа по SSH. Я использую Deploy для развертывания через FTP и не уверен, что можно (легко) переключаться между ветви. Из-за этого я надеялся на решение, которое не включало бы переключение между несколькими ветвями. - person Jonathan; 22.11.2012
comment
Я только что разветвил инструмент git-ftp на Github и внес некоторые изменения, чтобы он хорошо работал с git-поток. Инструмент выполняет развертывание через FTP, но загружает только различия между фиксациями. - person Peter van der Does; 24.11.2012

arrow_upward
3
arrow_downward

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

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

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

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

person Michael Durrant    schedule 22.11.2012
comment
Вы говорите, что у вас есть удаленная ветвь, настроенная для каждой размещенной среды? Звучит интересно. В этом случае я мог бы использовать ветку master для производственной среды, ветку release (содержащую последний выпуск перед запуском) для среды тестирования и ветку test для функций, которые находятся в стадии разработки. Как вы думаете, это хорошая (или приемлемая) установка? - person Jonathan; 22.11.2012
comment
@ Джонатан, вы использовали реализацию, предложенную выше в вашем комментарии? Что-нибудь, что сработало хорошо или пошло не так, как планировалось из-за этого? Я планирую внедрить аналогичную модель для дальнейшего развертывания, но не могу найти ссылки на эту модель с обсуждением плюсов и минусов. - person Hassan; 11.12.2017
comment
@Hassan У меня еще нет подходящего рабочего процесса для этого. Я часто просто работаю в ветке develop и отправляю ее в тестовую среду (для клиента). Для большего количества функций я использую ветки функций, которые в этом случае я нажимаю вручную. Это не безупречно, но, учитывая масштаб нашей команды (все еще я и еще один человек), это выполнимо. - person Jonathan; 11.12.2017