Работа с ветками в git репозитории

Репозиторий git это первое, что должен создать программист при старте проекта. И не важно сколько человек у вас в команде. Поговорим о git flow, ветках и зачем вообще нужен этот репозиторий.

Для чего нужен Git

Что же такое git и почему абсолютно каждый разработчик должен им пользоваться? Гит это распределенная система управления версиями.

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

Система контроля версий хранит историю изменений со временем. Так вы можете безбоязненно вносить абсолютно любые изменения, предварительно «сохранившись». В любой момент времени можно откатиться на любой checkpoint в прошлом.

Гит это распределенная система управления версиями.

Другими словами, храня код в Git ваша работа будет всегда в сохранности и под рукой.

Принцип работы с репозиторием

Весь процесс разработки выглядит как timeline. Это непрерывная последовательность изменений в коде. В один момент времени несколько человек могут работать над одним проектом параллельно, имея у себя локальные копии.

Логично предположить, что когда два человека захотят залить результаты своей работы в общий git репозиторий могут возникать конфликты. Это называется merge conflict.

Чтобы минимизировать частоту появления конфликтов зачастую люди

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

Остановимся на втором пункте чуть подробнее. Ранее мы говорили, что суть git в том, чтобы сохранить прогресс в общем репозитории. Как же быть, если фичу доделать не успеваем, а сохраниться надо?

Ветки в git репозитории

Базовая концепция git — ветки. Вы можете создать ответвление от базового timeline в определенный момент времени и сохранять всю работу в своей отдельной «вселенной».

Когда работа будет завершена останется только слить вашу ветку с общей и разрешить merge конфликты если такие будут. Влитые без ведома остальных членов команды изменения могут стать неожиданными. И вот тут появляется такая вещь как pull request и code review.

Pull request и Code review при слиянии веток

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

Далее начинается code review.

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

Git flow как удачная модель ветвления

Единый правил по работе с git нет. Это только инструмент, который призван сделать вашу работу проще. Но есть очень удачная, широко известная и применяемая модель организации ветвления в git — git flow. Про него есть много статей и примеров.

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

Основные идеи состоят в том, что существует несколько типов веток

• master ветка — в ней хранится стабильная версия кода. Код, попадая в нее образует очередной релиз.
• develop ветка — тут находится код, над которым ведется разработка. В него не попадают промежуточные, не выполненные до конца задачи.
• feature ветки — они содержат код, относящийся к определенному функционалу, который еще рано заливать в develop
• release ветки — здесь готовятся релиз кандидаты. После наступления feature freeze отводится ветка для подготовки к очередному релизу, в которую принимаются только исправления.
• hotfix ветки — на крайний случай, если нашлись грубые ошибки в текущем релизе, отводится такая ветка, в которую добавляется только исправление критически важного функционала. Остальное ждет следующего поезда релиза.

Базовый операции для работы с Git

mkdir my_project
cd my_project
touch .gitignore
git init
git add .
git commit -m "Initial commit"
git remote add origin youruser@yourserver.com:/path/to/my_project.git
git push origin master

Все! Теперь вы готовы начинать работать.

Естественно, git внутри содержит намного больше функционала. Осваивать работы с репозиторием стоит постепенно. Документацию по работе с ним можно найти на официальном сайте.

Приложения для работы с репозиторием

Весь git делится на 2 части — серверная инфраструктура, где хранится весь код и клиент для доступа к нему.

Для большинства разработчиков и небольших компаний не имеет смысла держать собственный сервер. Существует много зарекомендовавших себя облачных решений. Пожалуй самый популярные это github, bitbucket, gitlab.

Доступ к репозиторию можно осуществлять и через командную строку, но часто GUI удобнее. Мой любый клиент на данный момент — sourceTree,  он бесплатный, функциональный и удобный. До этого использовал gitKraken — тоже хороший клиент, но после того, как Github сделал приватные репозитории бесплатными, gitKraken сделал их открытие платным. Это не очень красиво.

Кстати, если ваш проект содержит git submodule, то sourceTree справляется с ними чуть лучше чем gitKraken.

Теперь вы знаете как сохранить ваш код, иметь четкое представление что и когда изменялось и не боятся вносить изменения! Самое время почитать о процессе разработке и инструментах для андроид разработчика.