Попытка понять / определить основной рабочий процесс Git - PullRequest
0 голосов
/ 21 ноября 2018

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

Я думаю, что справился, но я все еще немного потерян,Вот мое текущее понимание ...

У нас есть две ветви, которые всегда будут оставаться активными.

  • Мастер: Здесь я отправлю код, который фактически будет развернут на моем рабочем сервере, ибыть использованы моими пользователями.
  • Разработка: это будет ответвление от основной ветки.Он будет включать все мои новые функции, исправления ошибок и т. Д., Которые будут добавлены в следующий выпуск.

У нас есть несколько веток тем, которые будут разветвляться из ветки разработки (я думаю).Как только тема, например, ошибка исправлена, мы объединяем эту ветку с веткой разработки.Некоторые примеры:

  • Ветка темы 1: feature-ajaxify-shoping-cart
  • Ветка темы 2: bugfix-navbar-font-overlapping

Подготовка релиза

  • У нас есть 1 ветвь релиза за раз, которая будет ветвиться из ветви функций.
  • Теперь мы извлекаем / объединяем все функции, исправления ошибок и т. Д., Которые мы хотим добавить в следующий выпуск.
  • Мы можем оставить некоторые функции, над которыми мы работали, которые не будут присутствовать в следующем выпуске(Думаю).

Создание релиза

  • После того, как релизы будут удовлетворены, мы можем затем объединить эту ветку релиза с основной веткой и присвоить коммиту что-то вроде 'v1.2.0.
  • Мы также хотим пометить этот коммит с помощью 'v1.2.0', чтобы мы могли легко вернуться во времени и посмотреть релизы.

Дополнительные замечания, которые я выучил

Основная ветка всегда хороша и чиста, и содержит только коммиты, которые являются релизами (я думаю, поэтому у нас есть отдельная ветвь релиза, верно?).

Пожалуйста, дайте мне знать, где я что-то напутал или неправильно истолковал и т.д. Спасибо!

1 Ответ

0 голосов
/ 21 ноября 2018

Ваше резюме является точным: вы можете найти иллюстрированные в этой таблице .

Имейте в виду, что для того, чтобы протестировать вашу функцию с другими, вы должны объединить их для разработки(git flow feature finish MYFEATURE).
Существует еще один рабочий процесс ( рабочий процесс Git ), который позволяет лучше продвигать функции (разрабатывать, а затем выпускать)

Разница:

  • с потоком git, несколько ветвей feature объединяются в devel (где они обнаруживают, могут ли они работать вместе или нет), затем создается release из devel (в этот моментудаление функций становится сложным) перед объединением обратно в develmaster).
  • с gitworkflow :
    • feature ветви объединяются в "public "альфа" ветвь, которая сбрасывается после каждого выпуска (имеется в виду, удаляется / воссоздается поверх нового выпуска)
    • , затем подмножество тех же самых feature ветвей объединяются в "next "(" бета ") ветка для интеграции / приемочных испытаний.Эта ветвь "next" ("бета") аналогичным образом воссоздается поверх master после каждого нового выпуска.
    • , а затем подмножество feature ветвей объединяются в master, чтобыподготовьте следующий выпуск.

Ветви "public" и "next" (он же 'devel') никогда не объединяются в master.Они являются «временными» или «эфемерными», всегда удаляются / воссоздаются.
Только ветки feature объединяются с ветвями жизненного цикла (public, next, master).Это означает, что в любой момент вы можете выбрать feature между одним этапом жизненного цикла разработки и следующим.

...