Повышаем свою стоимость: Git и git-flow

"WTF?" - подумали шарящие ребята. Статья про Git, seriously? Ишо как сириосли. То, что кажется очевидным для опытных программистов, таковым не является для начинающих.

За примером далеко ходить не надо. У нас на третьем курсе преподавали основы гита. Ну как преподавали - бросали в начале пары текстовый документ с объяснениями, заданием и оставляли на всю пару одних. Разумеется, мы "усердно познавали тайны распределенной системы контроля версий", то есть, играли в "CS 1.6". Мы так громко матерились, что нас слышали в соседних аудиториях. Благо, там преподов тоже не было - они все чаи и кофеи гоняли на кафедре. Вот тебе, бабушка, и высшее образование. Ссанина козья.

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

Пше... то есть, Git

По идее, почти каждый прогер знает или хотя бы слышал, что такое гит, но на всякий случай кину определение с Википедии:

Git (произнoсится «гит»[да ладно, че в натуре?]) — распределённая система управления версиями. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux, первая версия выпущена 7 апреля 2005 года. 

Какой же клевый дядька Линус Торвальдс, не перестаю им восхищаться. Прикиньте, пока делал линуху, заодно прицепом и гит запилил. Ну гений же.

Короче, в чем проблема? Пока вы изучаете программирование самостоятельно, или в ВУЗе, но не объединяясь в команды, вам гит как-то не особо важным кажется. На первый взгляд.

Однако, даже программируя в одиночку, гит может сильно упростить вам жизнь. Например, вы можете вести основную разработку в одной ветке, но ежели захочется провести эксперимент, но боитесь поломать все к херам (а именно к этому приводят эксперименты, к гадалке не ходи), то можно переключиться на другую ветку, а потом грохнуть её нафиг, когда все сломается. Затем еще раз сделать новую ветку и так по кругу.

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

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

По-настоящему гит показывает себя в командной разработке. Представьте, какая наркомания творилась до появления систем контроля версий (а гит ведь не единственный в своем роде, из известных помню SVN и Mercurial) в командах разработки. Один здоровый проект удобно раскидать между несколькими людьми и разрабатывать частями, но как согласовывать эти части? А что, если два программиста внесли изменения в один и тот же файл? Как потом соединить части в одно целое? Говорю же, наркомания. Не представляю, как раньше обходились без систем контроля версий.

А почему именно гит? А вы откройте тот же Head Hunter. Практически все вакансии указывают в плюсах умение обращаться с гитом. Вот как-то сложилось в этой жизни, что гит рулит балом. Будь это меркуриал, советовал бы изучать меркуриал. А мы же смотрим не на свои хотелки, а на рынок.

Короче, кто в курсе, тот знает, кто не в курсе, держите книжку по гиту. Она здоровая, как нос кота после укуса пчелы:

Я сам её до сих пор не всю прочитал, но это и не требуется. Например, никогда не читал "Git на сервере", потому что не было нужны поднимать свой сервак с гитом и плюшками. А вот основы must read. И заклинаю вас - учитесь пользоваться гитом в консоли. Потом уже, когда уверенно себя будете чувствовать, подберете GUI для него. Я пользуюсь Smart Git. Есть еще Sourcetree и TortoiseGit. А также git из коробки поддерживают Visual Studio Code и WebStorm. Мало ли, куда вас жизнь занесет и вам придется работать с терминальной линухой, где вкусный GUI вам никто не даст. Консоль решает, как ни крути.

Гит-поток

Если о гите почти все слышали, то о git-flow уже не все могли услышать, "вернее, не только лишь все, мало кто это делал".

Когда куча компаний и команд делают примерно одинаковые вещи при разработке, что из этого вытекает? Правильно, общие рекомендации. Гит хорош тем, что вы можете организовать распределенную работу как угодно, однако, со временем, каждая команда приходит к пониманию организации определенного потока. И об этом git-flow.

В чем суть? Представьте, что вы начали новый проект. Вы захерачили Initial Commit в мастер ветку, сделали от неё новую ветку develop. И она становится мастер веткой для разработки, самые свежие фичи и фиксы находятся в ней. Каждый разработчик при реализации своей фичи создает от ветки develop ветку feature. Прикол в том, что от каждой фичи можно сделать другие фичи, до тех пор, пока не лопнете.

Все радуются, каждый в своей фиче пишет код, потом все дружно делают Pull Requests, устраивают срач, переделывают, как надо, и наконец заливают в develop.

Наступает страшное событие под названием "релиз". Все, затаив дыхание, смотрят, как тим лид создает ветку "release", мержит в неё develop, ставит заветный тег с версией "1.0.0", и все идут радостные бухать и пытаться под кокаином научить офисного хомячка извлекать квадратный корень из отрицательного числа.

Но вот беда - тестировщики провафлили критический баг, и теперь его срочно нужно пофиксить. Че делать-то? Спокуха, гит-поток все знает. Создаем ветку от release под названием hotfix, быстро правим в ней этот критический баг и мержим сразу в релиз. Последний штрих - замержить из release в develop, дабы этот критический баг не вылез снова, когда зальют новую версию из develop в release.

Кроме того, git-flow говорит, что мы можем создать ветку support для поддержки определенных версий продукта. Удобно, когда вы внезапно (иначе же быть не может) решаете сделать версию 2.0.0 без обратной совместимости. А многие пользователи, заразы такие, не хотят переходить на новую версию, им старая по душе. И вот для таких пользователей нужно держать в рабочем состоянии старую версию. Также пилить фичи, фиксить баги, только все от ветки support идет. И параллельно уговаривать их, как детишек скушать брокколи, перейти на новую версию.

Git-flow не заставляет вас делать именно так. Но вы все равно, рано или поздно, придете к примерно такому потоку сами, потому что он логичный. А если все равно придете, зачем откладывать - изучите сразу и применяйте на практике. Я даже в одиночку тружусь над своим проектом - все равно использую git-flow, пушто удобно жи.

Итого

Git и git-flow довольно плотно засели в IT сфере и вряд ли вылезут оттуда в обозримом будущем. Потому шарящий в них программист будет гораздо ценнее того, кто понятия не имеет ни о первом, ни о втором.

Напоследок акцентирую внимание на командах, одни из которых знать нужно, потому что пользоваться придется ими каждый день, другие в теории или через практику, не важно, ибо вылезти нужда в них может ой как внезапно: status, add, commit, push, fetch, pull, merge, rebase, stash, checkout, branch, cherry-pick, revert. Для начала хватит, дальше git book вам в помощь.