Git-ветвление для agile команд
Переход на Git открывает новый уровень гибкости для команд разработчиков программного обеспечения - вот почему
Освободившись от неуклюжих кодов и монолитных мега-слияний, которые мешают централизованному управлению версиями, разработчики могут с лёгкостью изолировать текущую работу и создавать узкие вертикальные фрагменты. Разветвления и слияния с Git настолько безболезненны, что многие команды создают новые ветки для каждой пользовательской истории или исправления багов, которые они реализуют. Эта модель быстро становится новым золотым стандартом для agile команд - и для этого есть все основания!
Из наших самых популярных вебинаров Вы узнаете:
- Как модель ветвления на проблему помогает командам предоставлять рабочий код в непрерывном потоке.
- Как выглядит рабочий процесс для разработчиков.
- Как это интегрируется с вашими существующими методами непрерывной интеграции и проверки кода
- Компромиссы, которые следует учитывать при оценке этой модели.
Смотреть и учиться
ВИДЕО
Вопросы и ответы
Хорошие вещи, верно?
Теперь, если вы похожи на меня, вы редко принимаете участие в вопросах и ответах вебинара. Это нормально, вы можете это признать. Поэтому я переписал несколько вопросов, которые вы можете просмотреть и прочитать на досуге.
Вопрос: Как вы работаете с номерами версий во всех этих ветках? Как вы различаете эти строки кода?
Ответ: Команды обычно дают название ветке после соответствующей версии релиза. Например, когда команда, которая делает Stash, готовит свой выпуск 2.9, они создали стабильную ветку с именем stash-2.9, поэтому, когда они видят ее в своем репозитарии, очень ясно, что это за ветка. Вы можете использовать любое соглашение об именах, которое подходит для вашей команды - просто укажите где-нибудь номер версии.
Вопрос: В ваших примерах один человек работал над каждой веткой. Какова правильная структура ветви и соглашение об именах, когда два человека работают над историей?
Ответ: У вас может быть два человека, работающих над одной и той же веткой задач. Просто следуйте базовым правилам общего этикета ветвления, таким как отказ от перебазирования, и, как правило, избегайте действий с локальной копией ветки, которые будут создавать головные боли для другого человека. Другой вариант - каждый сотрудник должен создать собственную ветку для этой задачи, а затем часто объединять их. Соглашение об именах для этого может быть следующим: <имя / инициалы> - <ключ задачи> - <описание> (например, sarah-DEV-1234-company-name-name-misspelled-on-homepage), которое более или менее совпадает с тем, что мы используем для веток одного разработчика.
Вопрос: Как вы обрабатываете зависимости, если вы не объединяете каждое изменение в одну ветку, как только оно сделано в ветке разработки?
Ответ: Если оба компонента находятся в стадии разработки, разработчики, работающие над каждым фрагментом кода, часто объединяют свои изменения. И вы можете сделать это в Git, не объединяя сначала одну ветку с централизованной веткой - вы и другой разработчик можете просто объединить свои ветви. Другой вариант - использовать ветку общей интеграции, о которой мы говорили ранее.
Вопрос: Некоторое время назад Мартин Фаулер выступил против ветвления функций, заявив, что это мешает рефакторингу и что, пока ветвь объектов жива, вы выполняете непрерывное построение, но не непрерывную интеграцию.
Ответ: Да, я знаком с его постом на эту тему. Это было довольно давно - возможно, в 2008 или 2009 году. Я думаю, что наши возможности для запуска CI в функциональных ветвях с тех пор значительно расширились. И, как я сказал в части «соображения» этого вебинара, подход «ветвь на задачу» означает, что вы не используете чистый CI. Вы делаете непрерывное построение и непрерывное тестирование, но не непрерывную интеграцию. Однако вы можете приблизиться к чистой CI, включив в свою схему ветвления общую ветвь интеграции.
По материалам Agile Coach "Git branching video"