Пожалуйста, рассмотрите следующий случай:
- В настоящее время используется целостность исходного кода MKS (да, это больно).
- Два раза в неделю некоторые разработчики регистрируют функцию (или частьэто) в ветку разработки.
- Регистрация для одной функции переплетается с регистрацией других функций.
- пример: версии 1, 3, 5 для функции A, версии 2 для функции B, версии 4 дляфункция C.
- Раз в неделю проверенные функции регистрируются в производственной ветви.
- Чаще всего требуется объединить изменения из неподтвержденных объектов.
- пример: функция A (сверху) идет в производство, но не функция B и C, поэтому мы не хотимвзять rev 1, 3, 5 (отбросить 2 и 4), но также, rev 3, возможно, потребовалось объединение с изменениями из rev 2, когда он был в разработке;это слияние будет отменено.
Переезд в Git (Yay!).Какой рабочий процесс будет соответствовать этому ограничению?
Я много читал об этом, и каждый рабочий процесс, кажется, основан на предположении, что в момент времени t будут выполнены функции A, B и C.Если нет, то я думаю, что t задерживается.
В моем случае, нет никакой необходимости вовремя завершать функции.Каждый разработчик работает над одной или несколькими функциями.Если он готов, он идет в производство.Если это не так, продолжайте совершенствовать.Каждую неделю происходит сборка производства.Крайне редко, никаких новых изменений в коде, идущих в производство, но оно все равно создается.Чаще всего десяток функций идут в производство.
Надеюсь, это достаточно ясно.Дайте мне знать, если вам нужно больше деталей!
(РЕДАКТИРОВАТЬ) Рабочий процесс рассмотрен:
- Работа над функцией в частной ветке
- Первый раз нажмите для разработки,в виде одного отдельного коммита
- Продолжить работу в частной ветке
- Внести еще несколько изменений в разработку, все еще в виде одного отдельного коммита
- Функция готова к работе;объединить частную ветвь с производственной ветвью
Рабочий процесс перебазирования:
На шаге 2 частная ветвь может быть перебазирована в последней главе разработки, перед отправкой.Но при этом, что произойдет при повторном ребазинге на шаге 4?Все изменения, произошедшие с первой перебазировкой, теперь частью разработки, будут удалены из недавно перебазированной частной ветки, не так ли?Это создаст проблему при запуске в производство.
Рабочий процесс объединения:
На шаге 2 частная ветвь может быть объединена с последней версией разработки;
коммит слияния может быть отброшен в частной ветке, что не затронет частную ветку тем, что происходит в ветке разработки.Но, делая это, можно будет снова и снова выполнять одно и то же слияние, каждый раз, когда что-то проверяется в разработке.
фиксация слияния может быть сохранена, и для продвижения к разработке потребуется толькослиться с тем, что является новым с момента последней регистрации.Но при переходе на производство частная ветвь теперь будет нести изменения по сравнению с другими функциями.Выбор Cherry можно использовать для выбора только соответствующих наборов изменений, но для этого потребуется, чтобы разработчик вручную определил, какие проверки выполнялись и подвержен ошибкам.