Как эффективно работать с Git

Отличная статья о Git и политике создании веток в Git-репозитарии.

По своему личному опыту Git мне сначала показался слишком сложным в сравнении с SVN. Все эти merge, reset, rebase, pull, push, commit были некими излишними концепциями, когда в Subversion было только update и commit. Но привыкание к Git наступило примерно через месяц активной работы, особенно потому, что переход на Git в нашем проекте был проведен насильно и возврата к Subversion в проекте не предполагалось. Теперь я с уверенностью могу сказать, что Git в большой команде и большом проекте — вещь просто незаменимая.

Самая главная и вкусная вещь в Git — это дешевизна создания веток.

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

В Git создание ветки требует секунды. Все коммиты изменений в каждую ветку остаются на вашей машине и появляются в репозитарии только после push из вашей локальной копии репозитария в удаленную. Переключаться между ветками можно прямо в той же копии проекта без всяких потерь изменений. Это значительно ускоряет работу разработчика и повышает его производительность. Удобства вытекающие из этой фичи трудно переоценить. К работе с Git надо просто привыкнуть. После этого SVN и CVS покажутся каменным веком.

Разумеется вторая главная фича Git-а — это его распределённая система работы с репозитарием. Вы делаете локальную копию репозитария на своей машине и для дальнейшей работы — создание веток и коммитов — вам больше не требуется постоянное соединение с удаленным репозитарием. Когда у вас появляется возможность, вы выталкиваете (push) свои коммиты в удаленный репозитарий и они там появляются для просмотра другими разработками. Когда вы работаете в офисе, отсутствие соединения с удаленным репозитарием выглядит не слишком нужным, ведь ваш компьютер постоянно поключен к сети, но для других проектов с распределенной командой эта фича может оказаться очень полезной.

Настоятельно советую пощупать Git и освоить работу с ним. Это можно сделать совершенно свободно, используя GitHub как удаленный репозитарий и установив Git для Windows на своей локальной машине. Кстати, наличие аккауна на GitHub, своих проектов в нем, и ссылка на них в резюме положительно оценивается при интервью. Наниматель может посмотреть, как вы пишете код своих собственных программ. Или оценить ваш вклад в другие open source-проекты.

Вдогонку

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