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

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

В качестве исторической справки отмечу, что git это распределенная система управления версиями, а была она изначально создана ни кем иным, как самим Линусом Торвальдсом (по ссылке можно посмотреть как старина Торвальдс фигачит код в ядро, как видно понедельники самые продуктивные дни Линуса) с целью управления разработкой ядра Linux и произошло это в уже не близком 2005 году.

Хватит лирики

В общем-то давайте к практике.

.gitignore

Git по умолчанию пытается отслеживать все файлы появляющиеся в папке (и подпапках) репозитория. Очевидно, что нет никакого смысла складывать в Git библиотеки, которые вероятно вы подтягиваете каким-нибудь менеджером пакетов или например всяческие obj, bin и прочие директории и файлы которые внезапно возникают вокруг вашего кода, но для самого кода ценности никакой не несут.

Именно для таких файлов существует такая штука как .gitignore, позволяющая объяснить git’у, что именно не нужно отслеживать. И, например, ваши Gui сразу же перестанут предлагать вам включить ненужные файлы в индекс, если вы пользуетесь не чистой консолью.

Типичные файлы .gitignore в зависимости от языка или среды разработки вы сможете найти на GitHub в соответствующем проекте.

Git Flow

«Си» позволяет очень просто выстрелить себе в ногу. На «Си++» сделать это сложнее, но, когда вам это удается, ногу отрывает полностью.

Bjarne Stroustrup

Фраза отца С++ в мире разработки характеризует многое. Собственно git это такая штука, которой стрелять в ногу можно  бесконечно огромным количеством способом, зависящим в основном от вашей фантазии и психических отклонений.

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

Если кратко, то зовется это все Git Flow, и описано множество раз на просторах безграничного интернета.

Git-flow — это набор расширений git предоставляющий высокоуровневые операции над репозиторием для поддержки модели ветвления Vincent Driessen.

Установка Git flow

Для начала нужно иметь установленный git;

Если с Git все хорошо, то в зависимости от используемой операционной системы можно использовать следующие способы установить git flow.

OS X — Homebrew

$ brew install git-flow

OS X — Macports

$ port install git-flow

Linux

$ apt-get install git-flow

Windows

Все сложно

Windows SourceTree

Данный клиент поддерживает Git Flow и позволяет весьма просто управлять им из Gui-интерфейса «из коробки».

Начало работы

Для начала git flow необходимо инициализировать, настроить его для работы с конкретным проектом, причем это нужно объяснить вашему локальному git, поэтому подобные махинации необходимо повторить на каждой машине разработчика (поправьте меня, если я не прав).

В общем для инициализации нужно использовать команду

git flow init

В случае использования SourceTree все можно сделать из интерфейса (больше не буду отдельно упоминать SourceTree, по ссылке все достаточно подробно и полно).

Feature

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

Ветка типа Feature создается из основной ветки разработки (по умолчанию develop).

git flow feature start featurename

В наименовании фичи можно исходить из потребностей конкретно вашего процесса разработки. Может быть вам будет удобно использовать какой-нибудь идентификатор пользовательской истории из вашего трекера, а может краткое текстовое название. В итоге вы получите такую ветку feature/featurename.

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

• Выполнить слияние ветки фичи в ветку разработки (feature/featurename в develop в моем примере).
• Переключиться обратно в ветку разработки.
• Удалить ветки фичи.

git flow feature finish featurename

Если работа над фичей идет совместно с коллегами — опубликуйте ёё на удаленном севере.

git glow feature publish featurename

Соответственно чтобы получить кем-то опубликованную фичу необходимо выполнить

git flow feature pull origin featurename

Можно отслеживать фичу в репозитории origin выполнив

git flow feature track featurename

Release

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

Для начала релиза

git flow release

git flow release start RELEASE [BASE]

Где [BASE] вы можете указать при желании в виде sha-1 хеша коммита из которого нужно начать релиз. Этот коммит должен обязательно принадлежать ветки разработки.

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

git flow release publish RELEASE

И так же по аналогии для отслеживания нужно использовать

git flow release track RELEASE

Завершение релиза один из наиболее сложных и важных шагов всего процесса ветвления в ходе которого происходят следующие действия:

• Ветка релиза сливается в ветку мастер
• Рализ помечается тегом равным его имени
• Ветка рилаза сливается обратно в ветку разработки
• Ветка релиза удаляется

git flow release finish RELEASE

Чтобы опубликовать тэги

git push --tags

Исправления

Исправления нам необходимы в том случае, когда требуется срочное изменение состояния продакшн-версии разрабатываемого продукта. Как вы понимаете она у нас находится в ветке master и помечена тэгом версии, соответственно мы ветвим hotfix от тега на ветке мастер.

git flow hotfix start VERSION [BASENAME]

Version — определяет имя нового исправленного релиза.

[Basename] — не обязательный аргумент, указывающий на коммит, от которого произойдет ветвление.

Завершение исправления выглядит так:

git flow hotfix finish VERSION

В этот момент оно сливается в ветки develop и master, коммит в ветке master помечается тегом с версией исправления.

Резюме

Выше приведены не все возможности и не все команды git-flow, кроме того использовать git со всеми его командами возможно и далее, т.к. git flow это просто набор инструментов упрощающих ветвление.

На самом деле самое важное с фундаментальной точки зрения описано в самой модели ветвления, принципы которой можно использовать и не прибегая к помощи git-flow.

Думаю в ближайшее время подготовлю перевод этой статьи.

 

Если Вы нашли ошибку, пожалуйcта выделите ее и нажмите Shift + E или нажмите здесь чтобы информировать меня. Спасибо.