Рабочая стратегия Git - много функций, очень частые выпуски

Question

вот описание моей повседневной работы:

Два разработчика , работающие над множеством мелких функций или исправлений, скажем, 3-4 в день для каждого разработчика. Мне нужно одновременно работать с функциями A - B - C, в то время как мой коллега работает с функциями D и E.

понедельник : Функция A передается на промежуточный сервер для проверки клиентов. Функция B отправляется на тот же промежуточный сервер для проверки клиента. Функция D передается на тот же промежуточный сервер для просмотра клиентом.

вторник : Мы получаем одобрение от клиента для A и D (но не для B). И они должны немедленно начать жить с этими изменениями.

Среда : Функция C отправляется на тот же промежуточный сервер для проверки клиента. Разрешение на B наконец получено.

четверг : Функция B должна быть немедленно запущена в производство.

1024 * пятница *: В последнем производственном выпуске обнаружена ошибка, и нам нужно вернуться к предыдущей версии.

Это не может рассматриваться как Scrum-подобный процесс, потому что нет никакой возможности сгруппировать функции в истории или планирование спринта. Это больше похоже на процесс обслуживания (может быть Kanban?).

Можете ли вы привести пример того, как бы вы справились с этим с помощью Git? Предположим, что прямо сейчас у нас есть только одна основная ветвь, и всякий раз, когда мы хотим что-то перенести в стадию или производство, мы должны «сделать git pull», чтобы все изменения остались живыми (даже нежелательные). Как насчет git "cherry-pick" для получения определенных коммитов? Одна ветвь на функцию кажется слишком обременительной, поскольку у нас слишком много функций. Если бы вы могли привести конкретные примеры команд и веток Git (только для того, чтобы показать основную идею, не обязательно быть на 100% правильными), это было бы здорово.

Спасибо.

Answer 1

Из того, что вы описали, я бы принял стратегию ветки релиза и множества рабочих ветвей.

Значение: вы должны настроить свой промежуточный сервер так, чтобы он извлекал только ветку staging, пока вы ивсе ваши сотрудники работают над вашими собственными ветвями функций (A, B, C и, возможно, master)

Когда изменения вступают в силу, вы просто объединяете эту функцию с веткой staging и отправляете ее всервер - промежуточная среда затем извлекает эту ветвь и развертывает.

Получив одобрение от своего клиента, вы можете затем переместить ветку функции (которая уже была объединена в staging в другую ветку (может быть, stable), а затем разверните его в рабочей среде.

После запуска вы можете удалить ветку компонентов и начать заново ..

TLDR: Рассматривайте каждую среду какветвь, которая перемещается только тогда, когда функция должна быть туда. Таким образом, вы даже можете отменить изменения из веток / сред, которые не должны туда идти.

И я бы пошел с подходом Канбан - легче и для того, что вы, кажется, делаете лучше подходит.

Answer 2

Я наконец выбрал следующий способ обработки этого:

• Один главный удаленный репозиторий.
• Одна локальная ветвь на постановке.

• Один местный филиал по производству.

  git checkout -b staging #on staging server
git checkout -b production #on production server

Программист A должен работать над функцией / патчем A:

#local development box
git checkout master
git checkout -b issue-A
#work on the feature
git push origin issue-A
#log in to the staging server
git checkout staging
git pull origin issue-A #merge with the staging branch, changes are live on staging.

То же самое относится и к программисту B, работающему над функцией B.

Начало производства:

#log in to the production server.
git checkout production
git pull origin issue-A #merge with the production local branch, changes are live on production.

Кроме того, локальная производственная ветвь может быть переведена в мастерскую, когда изменения вступают в силу и утверждаются:

git add <files>
git commit <commit info>
git push origin master

Это то, что сработало лучше всего в нашей ситуации, надеюсь, это кому-нибудь поможет.

Answer 3

Я приспособил git-flow к этому: https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

большая разница в том, что вы запускаете все функции с одного и того же начала для спринта / перехода.

Answer 4

Мы использовали git flow для подобных сценариев.

Поскольку git flow позволяет создавать несколько функций и передавать только те, которые вы хотите, в ветки разработки и master, он должен хорошо соответствовать вашим требованиям.

вот несколько ссылок для git-flow:

https://github.com/nvie/gitflow/ http://yakiloo.com/getting-started-git-flow/