Меню Рубрики

Установка git flow ubuntu

Про Git, Github и Gitflow простыми словами

Не самое исчерпывающее, но точно вполне доходчивое руководство по Git, Github и Gitflow – для тех, кого эти слова смущают, хотя не должны.

Если вы не поняли Боромира, значит, зашли по адресу. С системами контроля версий должен уметь работать любой программист, даже елси вы только учитесь.

Контроль версий помогает не только избежать досадных косяков при внесении изменений, но и необходим для командной работы над проектом. В этом материале мы рассмотрим основные команды для консоли и разберем самую популярную модель управления ветками проекта. И про ветки тоже поговорим.

Git – это распределенная система контроля версий (version control system – VCS).

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

Распределенность git’а отличает его от прочих vcs. Под распределенностью следует понимать, буквально, возможность использования одной системы контроля на проекте множеством разработчиков.

К слову, Git создал вот этот обходительный джентельмен:

Линус Торвальдс, создатель Git и Linux, передает привет Nvidia

С чего начнем?

Для начала, убедитесь, что у вас установлен Git.

Теперь, все что нам понадобится, чтобы создать репозиторий, это команда git init в нужном каталоге.

Откройте командную строку, и перейдите в Desctop (да, будем оригинальны), а там создайте каталог (например, proglib).

Теперь, проходим в новый каталог и выполняем git init.

Все, у нас есть пустой репозиторий.

Добавление файлов

Давайте создадим простой README.md файл, что-то вроде:

git status – простая команда, которая будет регулярно использоваться. Она показывает информацию о статусе проекта в git. Если вы выполните ее в каталоге proglib, будет видно, что файл README.md не отслеживается git’ом.

Чтобы добавить файл в контроль, используем команду git add README.md. Ну а если нужно добавить сразу много файлов, можно сказать git add . (то есть буквально add all).

Если выпонить git status еще раз, мы увидим, что теперь в системе появился новый файл, который мы добавили.

Коммитим изменения

Чтобы закомминтить изменения в локальный репозиторий, просто напишите в командной строке:

Разумеется, в сообщении можно указать что угодно. Но пожалуйста, сделайте себе одолжение, и пишите вразумительные и ясные комментарии.

Пушим в удаленный репозиторий

Мы будем пушить изменения на Github, так что если у вас вдруг не аккаунта, создайте его.

Нажмите кнопку Start a project и задайте проекту имя, остальные настройки можно оставить по умолчанию.

Так как мы только что создали репозиторий, будем использовать вариант . or push an existing.

Ветки

Git делает ветвление очень простым. Допустим, мы находимся в мастер-ветке и хотим дописать функционал, основываясь на коде из этой ветки. Для этого нужно всего лишь написать команду для создания дополнительной ветки и провести всю работу там. А как закончите, замерджить (то есть, слить ветки) все обратно в мастер.

Давайте так и сделаем. Выполните в консоли git checkout -b new_feature. Эта команда создаст новую ветку с названием new_feature от ветки мастер (или от любой вашей текущей ветки) и выполнит переход на новую ветку.

Внесите изменения в ваш README.md, сохраните их и используйте следующие команды, чтобы закоммитить изменения и замерджить их в мастер:

Теперь, когда вы знаете насколько просто работать с ветвлением, вас не удивит, что у многих людей своеобразный подход к управлению ветками.

Но есть один подход, который популярен в сообществе. Знакомьтесь, популярная модуль управления ветками Gitflow:

Схема выглядит беспорядочно, когда видишь ее впервые, так что пойдем по порядку. У нас есть две основные ветки: master и develop.

В ветке master содержится ровно тот же код, что и в рабочей (читай, продакт) версии проекта. А вся работа делается в ветке develop.

Во время работы на основе develop создаются так называемые feature-ветки. Их может быть неограниченное количество.

Далее, у нас есть ветка release, которая используется для подготовки к новому релизу проекта.

Наконец, есть ветка hotfix, которая служит для срочного исправления багов, найденных, например, на продакте.

Вот как в теории, происходит рабочий процесс в Gitflow:

1. Создается репозиторий
2. Репозиторий инициализируется
3. Начинается работа на ветке develop
4. Возникает необходимость опробовать новую штуку – создается feature-ветка и делаются коммиты
5. Закончив работу на feature-ветке, вы сливаете ее с develop
6. Если вы довольны текущей версией, но хотите продолжить работу, создается ветка release, куда перемещается текущая версия. Правка багов будет происходить на этой же ветке.
7. Когда с веткой release покончено, время слить ее в master и продолжить работу с develop
8. Кроме того, этот момент можно отметить на master-ветке

Gitflow как инструмент

Проделаем описанное выше шаг за шагом, но для начала убедитесь, что у вас есть gitflow-avh – инструмент для работы с Gitflow. На маке его можно установить с помощью homebrew:

gitflow-avh – это коллекция расширений для git, которая помогает избежать многих повторяющихся операций и вообще делает жизнь проще (это не точно). К примеру, при работе с feature-веткой, утилита проверит, слилась ли она в develop и удалит ее, если все прошло хорошо. Конечно, можно следовать модели Gitflow и самостоятельно, делая операции руками, но ведь проще же использовать готовое решение, так?

Как условие для начала работы, нам нужен git репозиторий. Если вы не начали читать статью с этого места, то у вас один уже есть. Теперь выполним команду git-flow init, как для git.

Далее будет несколько вопросов, но если оставить опции по умолчанию, эта команда просто создаст и назовет ветки в соответствие с моделью Gtiflow.

Когда все закончится, вы увидите, что находитесь на ветке develop. Теперь, создадим новую feature-ветку:

Затем, откроем README.md и внесем изменения. После, сделаем коммит:

Теперь, если мы всем довольны, закончим с этой веткой:

Как можно видеть в выводе в консоли, эта команда сделала следующее:

1. Слила ветки new_docs и develop
2. Удалила new_docs
3. Выполнила переход на ветку develop, чтобы можно было продолжать работу

Допустим, новая фича нас устраивает, она оттестирована и работает исправно. Теперь нам нужно сделать релиз.

Для начала, необходимо выполнить команду:

Здесь можно внести любые последние потенциальные исправления, обновить версию (имеет значение при разработке мобильных приложений) и так далее.

Когда работа закончена, просто напишем:

Вам нужно будет добавить несколько сообщений и меток, а потом утилита сделает следующее:

1. Сольет release и master
2. Пометит release как 2.0
3. Сольет release и develop
4. Удалит release
5. Выполнит переход на develop

Совместная работа

Иногда совместная работа напоминает классику:

На гитхабе вы можете добавить кого-то, кого вы знаете в сотрудники в настройках Settings-Collaborators. Приглашенные таким образом участники получат разрешение пушить в ваш репозиторий или вы можете создать команду разработчиков и регулировать уровни доступа от проекта к проекту.

Читайте также:  Установка и настройка maximenu ck

Но даже если вы хорошо знаете человека, вам не всегда может понравится, что кто-то делает коммиты в мастер без вашего ведома. Для таких случаев в github сущестуют pull-request’ы и code review.

Работает это следующим образом: вы делаете какое-то улучшение или фикс на featire-ветке, делаете pull request, кто-то из старших разработчиков, курирующих проект смотрит ваш код (читай, делает code review), возможно, делает какие-то замечания и, в конечном итоге добавляет ваш код в мастер-ветку (или куда-то еще).

Выглядит неплохо, НО

На деле отношение к код ревью может быть разным. Буквально, от

И как же к относится к code review? Кончено, это очень важная штука и нужно иметь терпение и делать ревью всех пул реквестов, если речь идет о вашем проекте, например. В долгосрочной перспективе это окупится. И, конечно, легко сказать «just do it», но в некоторых случаях сложившиеся традиции в команде разработчиков могут заставить пересмотреть свое отношение к некоторым вещам.

Проверяем на практике

Создадим новую feature-ветку:

Повторим процесс изменения документа и создания коммита.

А теперь сделаем кое-что новенькое:

То есть, отправим пул-реквест. Если зайти на гитхаб, можно его увидеть.

Теперь, нажмите кнопку Compare & pull request:

Здесь можно добавить комментарий к пул-реквесту.

На этом моменте, кто-то из вашей команды должен прийти и проверить ваш код. Вы даже можете дать об этом знать кому следует через инструмент управления проектом, которым ваша команда пользуется (JIRA, Trello, Leankit, Kanbanflow, etc) добавив таск/карточку в соответствующую колонку.

Когда пул-реквест будет подтвержден, вы как автор, должны сделать следующее:

Вы увидите, что Github закрыл пул-реквест и удалил ветку.

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

источник

Шпаргалка по git-flow

эффективное ветвление с помощью git-flow от Vincent Driessen

Введение

git-flow — это набор расширений git предоставляющий высокоуровневые операции над репозиторием для поддержки модели ветвления Vincent Driessen. узнать больше

Эта шпаргалка показывает основные способы использования операций git-flow.

Общие замечания

  • Git flow предоставляет превосходную командную строку со справкой и улучшенными выводом. Внимательно читайте его, чтобы знать, что происходит.
  • Клиент для macOS/Windows Sourcetree — отличный GUI для Git — также поддерживает git-flow
  • Git-flow основан на слиянии. Для слияния веток фич не используется rebase.

Установка

macOS

Linux

Windows (Cygwin)

$ wget -q -O — —no-check-certificate https://raw.github.com/petervanderdoes/gitflow-avh/develop/contrib/gitflow-installer.sh install stable | bash

Вам потребуется wget и util-linux для установки git-flow.

Подробные инструкции по установке git flow смотрите на git flow wiki.

Приступая к работе

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

Инициализация

Для начала использования git-flow проинициализируйте его внутри существующего git-репозитория:

Вам придётся ответить на несколько вопросов о способах именования ваших веток.
Рекомендуется оставить значения по умолчанию.

  • Разработка новых фич для последующих релизов
  • Обычно присутствует только в репозиториях разработчиков

Начало новой фичи

Разработка новых фич начинается из ветки «develop».

Для начала разработки фичи выполните:

git flow feature start MYFEATURE

Это действие создаёт новую ветку фичи, основанную на ветке «develop», и переключается на неё.

Завершение фичи

Окончание разработки фичи. Это действие выполняется так:

  • Слияние ветки MYFEATURE в «develop»
  • Удаление ветки фичи
  • Переключение обратно на ветку «develop»

git flow feature finish MYFEATURE

Публикация фичи

Вы разрабатываете фичу совместно с коллегами?
Опубликуйте фичу на удалённом сервере, чтобы её могли использовать другие пользователи.

git flow feature publish MYFEATURE

Получение опубликованной фичи

Получение фичи, опубликованной другим пользователем.

git flow feature pull origin MYFEATURE

Вы можете отслеживать фичу в репозитории origin с помощью команды git flow feature track MYFEATURE

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

  • Поддержка подготовки нового релиза продукта
  • Позволяет устранять мелкие баги и подготавливать различные метаданные для релиза

Начало релиза

Для начала работы над релизом используйте команду git flow release Она создаёт ветку релиза, ответляя от ветки «develop».

git flow release start RELEASE [BASE]

При желании вы можете указать [BASE] -коммит в виде его хеша sha-1, чтобы начать релиз с него. Этот коммит должен принадлежать ветке «develop».

Желательно сразу публиковать ветку релиза после создания, чтобы позволить другим разработчиками выполнять коммиты в ветку релиза. Это делается так же, как и при публикации фичи, с помощью команды:

git flow release publish RELEASE

Вы также можете отслеживать удалённый релиз с помощью команды
git flow release track RELEASE

Завершение релиза

Завершение релиза — один из самых больших шагов в git-ветвлени. При этом происходит несколько действий:

  • Ветка релиза сливается в ветку «master»
  • Релиз помечается тегом равным его имени
  • Ветка релиза сливается обратно в ветку «develop»
  • Ветка релиза удаляется

git flow release finish RELEASE

Не забудьте отправить изменения в тегах с помощью команды git push —tags

Исправления

  • Исправления нужны в том случае, когда нужно незамедлительно устранить нежелательное состояние продакшн-версии продукта
  • Может ответвляться от соответствующего тега на ветке «master», который отмечает выпуск продакшн-версии

git flow hotfix start

Как и в случае с другими командами git flow, работа над исправлением начинается так:

git flow hotfix start VERSION [BASENAME]

Аргумент VERSION определяет имя нового, исправленного релиза.

При желании можно указать BASENAME-коммит, от которого произойдёт ответвление.

Завершение исправления

Когда исправление готово, оно сливается обратно в ветки «develop» и «master». Кроме того, коммит в ветке «master» помечается тегом с версией исправления.

git flow hotfix finish VERSION

Команды

Последние замечания

  • Здесь описаны не все доступные команды, только наиболее важные
  • Вы можете продолжать использовать git и все его команды, как обычно, git flow — это просто набор дополнительных инструментов
  • Возможности «support»-веток пока в beta-версии, использовать их не рекомендуется

источник

GitHub Flow: рабочий процесс Гитхаба

Захватывающе интересная статья одного из разработчиков о принятом в компании рабочем процессе потребовала употребить пару специальных терминов при переводе.

То понятие, для которого на английском языке достаточно одного слóва на русский приходится переводить словосочетанием — Ничего лучше не знаю ни сам я, ни при помощи так что и мне, и читателям придётся с этим мириться, хотя бы и поневоле.

Другое понятие, «deploy», на русский часто переводят словом «развёртывание», но в моём переводе я решил вспомнить оборот из советского делопроизводства — «внедрение инноваций и стану говорить именно новых фич. Дело в том, что описанный ниже рабочий процесс не имеет «выпусков» (releases), что делает несколько неудобными и речи

К сожалению, некоторые переводчики бывают склонны грубо убивать сочную метафору «иньекции» (или даже «впрыскивания», если угодно), содержающуюся в термине так что и его также переводят словосочетанием Эта путаница огорчает меня, но ничего не могу поделать. Просто имейте в виду, что здесь «внедрением кода» я стану назвать внедрение его именно в производство (на продакшен), а не чужой код.

Я стремился употреблять словосочетание «в Гитхабе» в значении «в компании GitHub Inc.», в значении «на сайте Правда, иногда разделять их сложновато.

Проблемы git-flow

Повсюду путешествую, преподавая Git людям — и почти на каждом уроке и семинаре, недавно мною проведённом, меня спрашивали, что я думаю Я всегда отвечал, что думаю, что этот подход великолепен — он взял систему (Git), для которой могут существовать мириады возможных рабочих процессов, и задокументировал один проверенный и гибкий процесс, который для многих разработчиков годится при довольно простом употреблении. Подход этот также становится стандарта, так что разработчики могут переходить от проекта к проекту и из компании в компанию, оставаясь знакомыми с этим стандартизированным рабочим процессом.

Однако и у git-flow есть проблемы. Я не раз слыхал мнения людей, выражавших неприязнь к тому, что ветви фич отходят или к манере обращения с хотфиксами, но эти проблемы сравнительно невелики.

Для меня одной из более крупных проблем стала его сложность — бóльшая, чем на самом деле требуется большинству разработчиков и рабочих групп. Его сложность ужé привела к появлению для поддержания рабочего процесса. Само по себе это круто, но проблема в том, что помощник работает не из GUI Git, а из командной строки, и получается, что те самые люди, которым необходимо действительно хорошо выучить сложный рабочий процесс, потому что им вручную придётся пройти все шаги его — людей система и недостаточно удобна для того, чтобы использовать её из командной строки. Вот что становится крупною проблемою.

Все эти проблемы можно без труда преодолеть, следуя гораздо более простому рабочему процессу. Мы не пользуемся в Гитхабе. Наш рабочий процесс основан (и всегда был основан) на более простом подходе к Git.

Простота его имеет несколько достоинств. людям проще понять его, так что они быстрее начинают использовать его, реже (или вовсе никогда не) допускают ошибки, требующие отката. Кроме того, не требуется помогающий следовать процессу, так что употребление GUI не создаёт проблем.

Рабочий процесс Гитхаба

Итак, почему мы в Гитхабе не используем Главная проблема в том, что у нас принято беспрестанное внедрение изменений. Рабочий процесс создавался в основном в помощь «выпускам» нового кода. А у нас нет «выпусков», потому что код поступает (основной рабочий сервер) ежедневно — иногда по нескольку раз в день. Мы можем подавать для этого команды боту в той же в которой отображаются итоги CI (интеграционного тестирования). Мы стремимся сделать процесс тестирования кода и его внедрения как можно проще, чтобы каждому сотруднику он был удобен в работе.

У такого частого внедрения новинок есть ряд достоинств. Если оно случается каждые несколько часов, то почти невозможно возникнуть большому количеству крупных багов. Небольшие недочёты случаются, но они могут быть исправлены (а исправления, в свою очередь, внедрены) очень быстро. Обычно пришлось бы делать «хотфикс» отступать от нормального процесса, но для нас это становится просто частью нормального процесса: в рабочем процессе Гитхаба нет разницы между хотфиксом и небольшою фичею.

Другим достоинством беспрерывного внедрения изменений становится возможность быстро отреагивать на проблемы любого рода. Мы можем откликаться на сообщения о проблемах с безопасностью или исполнять небольшие (но интересные) просьбы о новых фичах — но тот же самый процесс работает и при внесении изменений, связанных с разработкою фичи нормального (или даже крупного) размера. Процесс один и тот же и он очень прост.

Как мы это делаем

Итак, каков рабочий процесс Гитхаба?

  • Содержимое ветви master всегда работоспособно (deployable).
  • Начиная работу ответвляйте новую ветвь, имя которой соответствует её предназначению (например,
  • Закоммитив в эту ветвь локально, отправляйте регулярно свою работу и в одноимённую ветвь на сервере.
  • Когда вам понадобится отзыв, или помощь, или когда вы сочтёте ветвь готовою ко слиянию, отправьте запрос на слияние.
  • После того, как кто-то другой просмотрел и одобрил фичу, вы можете слить вашу ветвь
  • После того, как ветвь master пополнилась новым кодом, вы можете немедленно внедрить его сделать это.

Вот и весь рабочий процесс. Он очень прост и результативен, он работает для довольно крупных рабочих групп — в Гитхабе сейчас работает 35 человек, из которых, может быть, пятнадцать или двадцать одновременно работают над одним и тем же проектом Думаю, что большинство команд разработчиков (групп, одновременно работающих с логикою одного и того же кода, что может порождать конфликты) имеют такой же размер — или меньше такого. Особенно группы, достаточно прогрессивные для того, чтобы заниматься быстрым и последовательным внедрением.

Итак, давайте по порядку рассмотрим каждый шаг.

Содержимое ветви master всегда работоспособно (deployable)

В общем-то это единственное жёсткое правило во всей системе. Есть только одна ветвь, имеющая всегда некоторое особенное значение, и её мы назвали master. Для нас это значит, что код этой ветви либо внедрён на продакшен, либо, в худшем случае, окажется внедрён в течение нескольких часов. Эта ветвь очень редко подвергается откручиванию на несколько коммитов назад (для отмены работы): если возникает проблема, то отменяются изменения из коммитов или совершенно новые коммиты исправляют проблему, но сама ветвь почти никогда назад не откручивается.

Ветвь master стабильна. Внедрение её кода на продакшен или создание новых ветвей на её основе — это всегда, всегда безопасно. Если от вас поступает неоттестированный код или он ломает сборку, то вы нарушили «общественный договор» команды разработчиков и у вас на душé должны кошки поскрести по этому поводу. Каждая ветвь подвергается у нас тестированию, а итоги поступают так что, если вы не тестировали её локально, то можете запушить ветвь (даже с единственным коммитом) на сервер и подождать, пока Jenkins не сообщит, все ли тесты успешно пройдены.

Ответвляйте новые ветви, имена которых соответствуют предназначению

Когда хотите поработать ответвляйте от стабильной новую ветвь, имя которой соответствует предназначению. (Например, в коде Гитхаба прямо сейчас есть ветви Такое наименование имеет несколько достоинств. Например, достаточно подать команду fetch, чтобы увидеть, над какими темами работают остальные. Кроме того, оставив ветвь время и возвратившись к ней позднее, по имени проще припомнить, о чём она была.

И это приятно, потому что, когда на Гитхабе заходим на страницу со списком ветвей, то легко видеть, над какими ветвями недавно поработали каков был объём работы).

Это почти как список будущих фич с грубою оценкою нынешнего состояния их. Если не пользуетесь этой страницею, то знайте — у ней классные возможности: она вам показывает только те ветви, в которых была проделана работа, уникальная по отношению к выбранной вами в настоящий момент ветви, да ещё и сортирует таким способом, чтобы ветви с наиболее недавнею работою были сверху. Если захочется полюбопытствовать, то я могу нажать на кнопку «Compare» и поглядеть на точный объединённый diff и на список коммитов, уникальных для этой ветви.

Сейчас, когда я это пишу, у нас в репозитории 44 ветви с невоссоединённым кодом, но также видно, что из них только в девять или в десять поступал код за последнюю неделю.

Постоянно отправляйте код именованных ветвей на сервер

Другое крупное отличие мы беспрерывно ветвей на сервер. С точки зрения внедрения приходится беспокоиться только о ветви master, так что push никого не озадачит и ничего не поломает: всё, что это просто код, над которым идёт работа.

Этим создаётся страховочная копия на случай утраты ноутбука или выхода жёсткого диска из строя. Этим поддерживается, что ещё важнее, постоянный обмен сведениями между разработчиками. Простой командою можно получить список тех TODO, над которыми все сейчас работают.

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

В любое время создавайте запрос на слияние

GitHub снабжён поразительною системою обзора кода, которая называется запросами на слияние; боюсь, недостаточно разработчиков вполне знают о ней. Многие пользуются ею в обыкновенной работе над открытым исходным кодом: форкнул проект, обновил код, отправил запрос на слияние к хозяину проекта. Однако эта система также может употребляться как средство внутрикорпоративной проверки кода, и так её используем мы.

Её мы, собственно, скорее используем как средство просмотра и обсуждения ветвей, чем как запрос на слияние. GitHub поддерживает отсылку запроса на слияние из одной ветви в другую в одном и том же проекте (открытом или приватном), так что в запросе можно сказать «мне нужна подсказка или обзор этого кода», а не только «прошу принять этот код».

На этой иллюстрации вы можете видеть, как Джош просит Брайана взглянуть на код, и тот является с советом по поводу одной из строк кода. Ниже можно видеть, как Джош соглашается с соображениями Брайана и пополняет код, чтобы отреагировать на них.

Можно, наконец, видеть и то, что код находится ещё на стадии испытаний: это ещё не ветвь, подготовленная ко внедрению, мы используем запросы на слияние для рассмотрения кода задолго до того, как захотим действительно слить его и отправить на внедрение.

Если ваша работа над фичею или ветвью застревает и нужна помощь или совет, или если вы — разработчик, а на вашу работу надо бы посмотреть и дизайнеру (или наоборот), или даже если кода у вас мало (или вовсе нет), но есть композиция скриншотов и общих идей, то вы открываете запрос на слияние. Система Гитхаба позволяет добавлять людей к обсуждению так что если обзор или отклик нужен от конкретного человека, то можно в запросе упомянуть его (вы видели выше, как Джош сделал это).

И это круто, потому что в запросах на слияние можно комментировать отдельные строки объединённого диффа, или отдельные коммиты, или весь запрос в целом — и копии реплик сложатся в единое обсуждение. Также можно продолжать пополнение ветви кодом, так что если укажет на ошибку или на позабытую возможность в коде, то можно поместить исправление в ту же ветвь, и GitHub покажет новые коммиты в обсуждении, так что и вот так можно трудиться над ветвью.

Если ветвь существует слишком долго и вы ощущаете, что код в ней рассогласовывается с кодом ветви то можно код влить в вашу ветвь и продолжить работу. В обсуждении запроса на слияние или в списке коммитов без труда видно, когда ветвь последний раз обновляли кодом, взятым

Когда работа над ветвью целиком и полностью окончена и вы ощущаете её готовою ко внедрению, тогда можете переходить к следующему шагу.

Слияние только после обзора запроса

Мы не работаем непосредственно в ветви но и работу из именованной ветви мы не подвергаем слиянию сразу после того, как сочтём её оконченною — сперва мы стараемся получить одобрение от других сотрудников компании. Оно обычно имеет форму или комментария нам надо привести поглядеть на ветвь.

Когда одобрение получено, и ветвь прошла CI, мы можем слить её и на внедрение; в этот момент запрос на слияние будет закрыт автоматически.

Внедрение непосредственно после обзора

Наконец, ваш труд окончен, а плоды его — на ветви master. Это означает, что, даже если прямо сейчас вы не станете внедрять их, то они всё равно станут основою для ветвей других сотрудников, и что следующее внедрение (которое, скорее всего, случится через несколько часов) запустит новинку в дело. И так как бывает очень неприятно обнаружить, что запустил ваш код и пострадал от этого (если код поломал), то людям свойственно самим заботливо проверять стабильность итогов совершённого ими слияния, самостоятельно внедрять результаты.

Наш campfire-бот, по имени hubot, может внедрять код по указанию от любого из сотрудников. Достаточно подать в чате команду hubot deploy github to production, и код поступит на продакшен, где начнётся перезапуск (с нулевым даунтаймом) всех необходимых процессов. Можете сами судить о том, как часто это случается на Гитхабе:

Как видите, шесть разных человек (среди которых один саппорт и один дизайнер) внедряли код более двух дюжин раз за сутки.

Всё вышеописанное я совершал для ветвей с одним коммитом, содержащим однострочное изменение. Процесс прост, бесхитростен, масштабируем и силён. То же самое можно делать и с ветвью фичи, содержащей полсотни коммитов, потребовавших двухнедельной работы, и с одним коммитом, изготовленным минут за десять. Процесс настолько прост и настолько не тяготит, что его необходимость не раздражает даже в однокоммитном случае, так что люди редко пропускают или обходят отдельные шаги его — разве что речь идёт об изменении настолько малом и незначительном, что это никакого значения не имеет.

Наш рабочий процесс обладает и силою, и невероятною простотою. Думаю, многие согласятся, что GitHub — очень стабильная платформа, что на её проблемы мы реагируем быстро (если они вообще возникают), что новые фичи внедряются в быстром темпе. Там нет таких компромиссов в отношении качества или стабильности, которые могли бы увеличить скорость и простоту рабочего процесса или уменьшить число его шагов.

Заключение

Git сам по себе довольно сложен для понимания. Если его ещё и употреблять в рабочем процессе более сложном, чем это необходимо, то дело кончится ежедневным чрезмерным усилием рассудка. Я всегда буду отстаивать употребление простейшей из возможных систем, пригодных для работы вашей группы, и до тех пор, пока система эта не перестанет работать; только тогда добавляйте сложность, когда никак не удаётся избежать этого.

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

Для групп, труд которых строится вокруг доставки кода, которые ежедневно обновляют продакшен, беспрерывно тестируют и внедряют фичи, я рекомендовал бы более простой рабочий процесс — такой,

источник

Добавить комментарий