git/start
Материал из ALT Linux Wiki
Ilis (обсуждение | вклад) |
|||
Строка 62: | Строка 62: | ||
==== Теги ==== | ==== Теги ==== | ||
- | Воспользовавшись утилитой gear-create-tag, можно создать красивый тег типа %version-%release на текущем коммите. Когда будет завершен долгострой нашей эпохи и будет введена в эксплуатацию система сборки из git, такие теги будут скорее всего обязательными, и сборка в | + | Воспользовавшись утилитой gear-create-tag, можно создать красивый тег типа %version-%release на текущем коммите. Когда будет завершен долгострой нашей эпохи и будет введена в эксплуатацию система сборки из git, такие теги будут скорее всего обязательными, и сборка в репозиторий будет производиться только из них. |
{{Category navigation|title=git|category=git|sortkey={{SUBPAGENAME}}}} | {{Category navigation|title=git|category=git|sortkey={{SUBPAGENAME}}}} |
Версия 11:58, 6 января 2009
Начинаем работать с 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-бранча, до других ещё добраться надо). Ну и всякие мелочи вроде "утащить чужой бранч на посмотреть" работают одинаковым образом:
mkdir -p ~/git cd ~/git git clone git://git.altlinux.org/people/inger/packages/installer cd installer U=slazav; git fetch git://git.altlinux.org/people/$U/packages/$(basename `pwd`) master:$U U=boyarsh; git fetch git://git.altlinux.org/people/$U/packages/$(basename `pwd`) master:$U git branch
Теги
Воспользовавшись утилитой gear-create-tag, можно создать красивый тег типа %version-%release на текущем коммите. Когда будет завершен долгострой нашей эпохи и будет введена в эксплуатацию система сборки из git, такие теги будут скорее всего обязательными, и сборка в репозиторий будет производиться только из них.