В настоящее время наша компания использует простую модель ветвления ствола / выпуска / исправления и хотела бы узнать, какие модели ветвления лучше всего подходят для вашей компании или процесса разработки.
Рабочие процессы / модели ветвления
Ниже приведены три основных описания этого, которые я видел, но они частично противоречат друг другу или не заходят достаточно далеко, чтобы разобраться с последующими проблемами, с которыми мы столкнулись (как описано ниже). Таким образом, наша команда пока что не так уж и хороша. Вы делаете что-то лучше?
Слияние с перебазированием (запутанный против последовательной истории)
Стоит ли
pull --rebase
ждать или ждать слияния с основной линией, пока ваша задача не будет завершена? Лично я склоняюсь к слиянию, поскольку это сохраняет наглядную иллюстрацию того, на каком основании задача была начата и завершена, и я даже предпочитаюmerge --no-ff
для этой цели. Однако у него есть и другие недостатки. Также многие не осознали полезного свойства слияния - то, что оно не коммутативно (слияние ветки темы в мастер не означает слияние мастера с веткой темы).Я ищу естественный рабочий процесс
Иногда ошибки случаются, потому что наши процедуры не фиксируют конкретную ситуацию с простыми правилами. Например, исправление, необходимое для более ранних выпусков, должно, конечно, базироваться достаточно нисходящим, чтобы можно было объединить восходящий поток со всеми необходимыми ветвями (достаточно ли ясно использование этих терминов?). Однако бывает, что исправление попадает в мастер до того, как разработчик поймет, что его следует поместить дальше вниз по течению, и, если оно уже выдвинуто (еще хуже, объединено или что-то на его основе), то оставшаяся опция - выбор вишни, с связанные с этим опасности. Какие простые правила, как такие, вы используете?Также сюда входит неловкость одной тематической ветви, обязательно исключая другие тематические ветви (при условии, что они разветвлены от общей базовой линии). Разработчики не хотят завершать функцию, чтобы начать еще одно чувство, будто только что написанного кода больше нет
Как избежать возникновения конфликтов слияния (из-за cherry-pick)?
Что похоже на верный способ создать конфликт слияния - это выбрать между ветвями вишню, они никогда не смогут снова слиться? Может ли применение одной и той же фиксации к возврату (как это сделать?) В любой из ветвей разрешить эту ситуацию? Это одна из причин, по которой я не осмелюсь настаивать на в значительной степени основанном на слиянии рабочем процессе.
Как разложить на актуальные ветки?
Мы понимаем, что было бы здорово собрать законченную интеграцию из веток тем, но часто работа наших разработчиков не была четко определена (иногда так просто, как "возиться"), и если какой-то код уже вошел в раздел "Разное", это не может быть удалено оттуда снова, согласно вопросу выше? Как вы работаете с определением / утверждением / окончанием / выпуском веток вашей темы?
Правильные процедуры, такие как проверка кода и выпуск , конечно, были бы хороши.
Но мы просто не можем держать вещи достаточно распутанными, чтобы справиться с этим - какие-либо предложения? интеграционные ветки, иллюстрации?
Ниже приведен список связанных вопросов:
- Каковы хорошие стратегии, позволяющие исправлять развернутые приложения?
- Описание рабочего процесса для использования Git для собственной разработки
- Git workflow для разработки корпоративного ядра Linux
- Как вы поддерживаете код разработки и производственный код? (спасибо за этот PDF!)
- управление релизами git
- Git Cherry-pick против Merge Workflow
- Как выбрать несколько коммитов
- Как вы объединяете отдельные файлы с помощью git-merge?
- Как черри выбрать диапазон коммитов и слить в другую ветку
- ReinH Git Рабочий процесс
- рабочий процесс git для внесения изменений, которые вы никогда не вернете к началу
- Вишневый пик слияния
- Правильный рабочий процесс Git для комбинированной ОС и частного кода?
- Ведение проекта с помощью Git
- Почему нельзя изменить файл слияния Git с измененным родителем / хозяином.
- Git ветвление / перебазирование хороших практик
- Когда "git pull --rebase" доставит мне неприятности?
- Как DVCS используется в больших командах?
Также посмотрите, что Plastic SCM пишет о разработке , ориентированной на задачи , и если Plastic не ваш выбор, изучите модель ветвления nvie и его вспомогательные сценарии .