git/start

Начинаем работать с git.alt

Эта страничка предназначена в помощь тем, кто только озадачился применением git, gear и git.altlinux.org в своём майнтейнерском труде. Она пытается ответить на вопросы "зачем это мне?" и "как здесь принято?" с точки зрения mike@ (которая имеет ровно один плюс -- сам таким не шибко давно озадачивался) и наверняка может и должна быть скорректирована более опытными людьми.

Далее по тексту git.alt == git.altlinux.org с доступом поверх авторизованного ssh.

зачем это мне?

git представляет собой решение двух проблем в одном флаконе:

• с одной стороны, это система контроля версий программного кода;
• с другой -- инструмент облегчения совместной разработки.

Соответственно и польза от него бывает двоякая:

• для пакета, которым активно (более-менее синхронно или периодами) занимается несколько человек -- реально облегчающий вникание в происходящее у других и сведение веток в нечто более-менее общее git fetch/merge/pull;
• но и для пакета, которым занимается исключительно один человек, бывает удобней и спокойней работать над спеком да патчами, когда фиксировать наработки можно командой git commit, а не сборкой "удачной" src.rpm с откладыванием в сторонку, а делать побочные эксперименты по ходу пьесы -- делая git checkout различных git branch, а не ненароком перетирая эти самые отложенные пакетики изрядно перехаканными ;-)

Опять же git diff и git log -p очень сильно помогают в оценке своих и чужих изменений в коде -- как "что я сделал с последнего коммита", так и "кто тут вообще чего налопатил". Есть и другие инструменты -- например, tig и gitk -- но о них, как и о тонкостях, лучше смотреть документацию и примеры в страничках по соседству.

как здесь принято?

• на одну сущность (e.g. пакет) -- один репозиторий
• желательно, чтобы имя репо совпадало с именем пакета
• если не уверены, посмотрите на то, как делает репозиторий gear-srpmimport
• посмотреть можно или поставив пакет gear, почитав gear-srpmimport(1) и напустив его на несколько src.rpm, или сделав нечто вроде

git clone git://git.altlinux.org/archive/a/apt-conf-sisyphus.git
cd apt-conf-sisyphus
git branch
git log -p
gitk

типичные неприятности

мегакоммит

Если сделать множество изменений, особенно тематически несвязанных, и потом закоммитить их одним куском -- те, кто может заинтересоваться только в части изменений, но быть несогласным с остальными, будут вынуждены либо отказаться от всего куска, либо потратить много труда на перелопачивание коммита с целью разделения мух и котлет (чужие коммиты лопатить при этом сложнее, чем свои -- надо ж сперва понять, что делалось-то).

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

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

Правила коммитов в общем-то аналогичны правилам работы с любой системой контроля версий. Коммитить надо часто, цельными кусками, по возможности так, чтобы после каждого коммита пакет собирался через gear. Это полезно во время поиска регрессий через git-bisect.

код и спек

Частным случаем мегакоммита является оформление изменений в коде/патчах и spec-файле одним коммитом. Зачастую это вроде как разумно -- если пакет своей же разработки, то %changelog пакета может документировать изменения в новой версии -- но проблема возникает тогда, когда кто-то ещё отслеживает производимые правки с целью портирования на существенно другую ветку (такое нередко наблюдал с модулями alterator: например, правки в backend обычно имеют свойство быть общеполезными, а вот фронтэнды за год-полтора разницы веток могут существенно разъехаться, чтобы вести их отдельно).

Поэтому при малейшей возможности лучше также коммитить код отдельно, потом спек -- отдельно. Даже если commit message придётся скопировать в %changelog (кстати, забрать его уже оттуда для commit message собственно по спеку умеет gear-commit).

--amend

Стоит принять за правило: семь раз commit, один раз push. И уж после этого никаких commit --amend (правка последнего коммита) -- если нет особого желания устроить лишнее веселье себе (при push) и другим (при pull/fetch).

мелкие предложения

именование бранчей

Свой основной бранч стоит держать под именем master (дефолтное имя бранча в репозиториях git): тогда намного проще понять, кто что делает с каким пакетом (например, на http://git.altlinux.org по умолчанию показывается сводка изменений именно master-бранча, до других ещё добраться надо). Для чужих -- используйте git-remote(1), см. тж. girar-clone, girar-download.

Теги

Воспользовавшись утилитой gear-create-tag, можно создать красивый тег типа %version-%release на текущем коммите. С тех пор, как введена в эксплуатацию система сборки из git, такие теги обязательны и сборка в репозиторий производится по ним.