Git - это распределённая система управления версиями.
Распределенная, значит, что в общем случае данные будут хранится не на одном сервере, а доступ к ним можно получить с разных устройств и из любой точки мира. Даже если у вас сломался компьютер – проделанная работа не будет потеряна.
Система контроля версий хранит историю изменений со временем. Так вы можете безбоязненно вносить абсолютно любые изменения, предварительно “сохранившись”. В любой момент времени можно откатиться на любой checkpoint в прошлом.
Принцип работы с репозиторием
Весь процесс разработки выглядит как timeline. Это непрерывная последовательность изменений в коде. В один момент времени несколько человек могут работать над одним проектом параллельно, имея у себя локальные копии.
Логично предположить, что когда два человека захотят залить результаты своей работы в общий git репозиторий могут возникать конфликты. Это называется merge conflict.
Чтобы минимизировать частоту появления конфликтов зачастую люди
- Разделяют между собой задачи так, чтобы части кода пересекались по минимуму.
- Не заливают свои изменения до того момента, как задача будет сделана целиком.
Остановимся на втором пункте чуть подробнее. Ранее мы говорили, что суть git в том, чтобы сохранить прогресс в общем репозитории. Как же быть, если фичу доделать не успеваем, а сохраниться надо?
Ветки в git репозитории
Базовая концепция git – ветки. Вы можете создать ответвление от базового timeline в определенный момент времени и сохранять всю работу в своей отдельной “вселенной”.
Когда работа будет завершена останется только слить вашу ветку с общей и разрешить merge конфликты если такие будут. Влитые без ведома остальных членов команды изменения могут стать неожиданными. И вот тут появляется такая вещь как pull request и code review.
Pull request и Code review при слиянии веток
Суть подхода в том, что перед тем как смержить ваши наработки с основной master веткой проекта дать возможность вашим коллегам посмотреть то, что вы сделали. Для этого создается pull request - запрос на добавления кода в общую ветку.
Далее начинается code review.
Ваши коллеги оставляют вам комментарии и делятся мыслями и идеями на счет вашей работы. Они могут попросить переделать тот или иной кусок кода. Главное тут – конструктивный диалог. Всем свойственно ошибаться, и вам, как автору кода, и вашим коллегам, как ревьюверам. Вы должны прийти к согласию как должно быть реализовано то или иное требование и внести изменения в вашу ветку при необходимости.
Приложения для работы с репозиторием
Весь git делится на 2 части – серверная инфраструктура, где хранится весь код и клиент для доступа к нему.
Для большинства разработчиков и небольших компаний не имеет смысла держать собственный сервер. Существует много зарекомендовавших себя облачных решений. Пожалуй самый популярные это github, bitbucket, gitlab.
Доступ к репозиторию можно осуществлять и через командную строку, но часто GUI удобнее. Мой любый клиент на данный момент – sourceTree, он бесплатный, функциональный и удобный. До этого использовал gitKraken – тоже хороший клиент, но после того, как Github сделал приватные репозитории бесплатными, gitKraken сделал их открытие платным. Это не очень красиво.
Кстати, если ваш проект содержит git submodule, то sourceTree справляется с ними чуть лучше чем gitKraken.
Полезные ссылки
Работа с ветками в git репозитории - оригинал статьи.
Git How To - интерактивный тур, который познакомит вас с основами Git.
Git Flow - немного про методологию ветвления.