git с развитием, стадиями производства и производства

This article sounds interesting, but I'm pretty sure the diagrams are wrong. http://guides.beanstalkapp.com/version-control/branching-best-practices.html

Shouldn't it be DEVELOPMENT > STAGING > PRODUCTION?

Слияния должны проходить только в одном направлении: от функции и исправлений ошибок   сделанные в их собственной ветке или в разработке в стадию тестирования.   После тестирования вы можете объединить эти изменения с   производство. </р>

Здесь я немного смущен. Итак, я объединил постановку на Мастер или Мастер на постановку?

Я использую клиент под названием SmartGit, и я запутался в этом вопросе. Обычно я делаю ветку для функции, фиксирую ее, затем переключаюсь на мастер и объединяю ее с веткой (вперед). Поэтому в этом новом рабочем процессе с Staging and Production я создаю эти две дополнительные ветки, а затем создаю ветку от master (aka dev) для моей функции. Закрепите его, затем переключитесь на Staging и слейте (вперед) в свою ветку функций? Правильно ли это звучит?


Actually what made this so confusing is that the Beanstalk people stand behind their very non-standard use of Staging (it comes before development in their diagram, and it's not a mistake! https://twitter.com/Beanstalkapp/status/306129447885631488

Решили забыть о Beanstalk и просто с Гитубом.


Поскольку я опубликовал это, люди Beanstalk приняли мой намек и переименовали их этапы, теперь называя Development «Stable».

49
Классические ветвящиеся рабочие процессы нелегко применять к Git, поскольку ветви в Git намного более легкие. Они всего лишь указатели на (одиночные) совершают в истории, которая сама может разветвляться во многих направлениях. Вот почему трудно видеть ветви как «линию» раздельного развития (это также относится к диаграммам в «Успешной модели ветвления Гит»).
добавлено автор poke, источник
Вы хотели бы объединить исправления от постановки на производство. Слияние с стадией с целью тестирования, а затем слияние разработки с производством, когда тестирование завершено, открывает возможность дополнительной работы над разработкой, которая сливается с производством, которое никогда не сливалось со стадией.
добавлено автор wadesworld, источник
Точный вопрос, который я искал. Искал Google и получил это на первом номере. Yaay (y)
добавлено автор NullPointer, источник
да, это не совсем плавающие полосы. Но мой вопрос более конкретно: переключиться на Staging и merge на dev или наоборот? Я новичок в git и запутался в этом. Возможно, мне стоит обратиться к вопросу непосредственно к разработчикам SmartGit, моему клиенту windows git.
добавлено автор Max Hodges, источник

5 ответы

Мысль здесь заключается в том, что вы проводите большую часть своего времени в development . В процессе разработки вы создаете ветвь feature (выключен development ), завершаете эту функцию, а затем снова объединяетесь в development . Затем его можно добавить к окончательной производственной версии, объединив ее в production .

Подробнее об этом подходе см. Успешная модель ветвления Git .

56
добавлено
Вы выиграли миллион сердец за ссылку «Успешная линия дробления». Yaay (y)
добавлено автор NullPointer, источник
+1 для «Успешной модели ветвления Гит». Это в основном стало стандартом, поскольку git workflows идет.
добавлено автор Mike Weller, источник
спасибо @JosefKufner Статья потока github была очень полезной
добавлено автор Max Hodges, источник
«Успешная модель ветвления Git» немного сложна для небольших проектов, в которых участвуют всего несколько человек. Я предпочитаю более простой метод, когда разработка выполняется в мастер-ветке, а стабильные версии помечены в главной ветви, и при необходимости они имеют стабильную ветвь для патчей. См. stackoverflow.com/questions/14858075/… и scottchacon.com/2011/08/31/github-flow.html
добавлено автор Josef Kufner, источник
@eykanal Вы объединяете development в production или функцию в production ?
добавлено автор endo64, источник

Мы делаем это по-другому. IMHO мы делаем это проще: в master мы работаем над следующей крупной версией.

Каждая более крупная функция получает свою собственную ветвь (полученную от мастера) и будет автоматически перегружаться (+ сила) на вершине мастера разработчиком. Rebasing работает только отлично, если один разработчик работает над этой функцией. Если функция закончена, она будет только что переустановлена ​​на master, а затем мастер переадресован на последнюю фиксацию функции.

Чтобы избежать перезагрузки/принудительного нажатия, вы также можете регулярно объединять основные изменения с ветвью функций, и если она завершена, объедините ветвь функции в мастер (обычное слияние или сквош-слияние). Но IMHO делает эту ветку менее ясной и затрудняет переупорядочивание/очистку коммитов.

Если новый релиз подходит, мы создаем боковую ветвь из мастера, например. release-5 , где исправляются только ошибки.

5
добавлено
Что конкретно вы не понимаете?
добавлено автор Mot, источник
Я понятия не имею, что это значит.
добавлено автор Max Hodges, источник

Фактически, что сделало это настолько запутанным, так это то, что люди Beanstalk стоят за своим нестандартным использованием Staging (это происходит до разработки на их диаграмме, и это не ошибка!

https://twitter.com/Beanstalkapp/status/306129447885631488

3
добавлено

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

1
добавлено

Из сообщение в моем блоге :

Рабочий процесс «gitflow» из nvie имеет две проблемы: он смущает   изменяет значение «ведущей» ветви, и это не ясно   оправдать стоимость дополнительной долгоживущей ветви. Обе проблемы   может быть разрешено [...]

1
добавлено
Более подробная информация необходима здесь, а не только на внешнем источнике. Внешние источники приходят и уходят.
добавлено автор rhand, источник
Git — русскоговорящее сообщество
Git — русскоговорящее сообщество
588 участник(ов)

Обсуждаем git, его фичи, хаки, надстройки и экосистему. Правила: http://telegra.ph/ru-chat-rules-06-19 https://git.wtf/

pro.git::next
pro.git::next
44 участник(ов)

Обсуждение системы контроля версий git и инструментов для работы с ней.