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

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

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

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

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

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

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

Для начала, убедитесь, что у вас установлен 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-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. Приглашенные таким образом участники получат разрешение пушить в ваш репозиторий или вы можете создать команду разработчиков и регулировать уровни доступа от проекта к проекту.

Но даже если вы хорошо знаете человека, вам не всегда может понравится, что кто-то делает коммиты в мастер без вашего ведома. Для таких случаев в 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 закрыл пул-реквест и удалил ветку.

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