Вход:  Пароль:  
FreeSource: AltLinux/Sisyphus/devel/git/start ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |
Эта страница была перенесена на altlinux.org. Текст на freesource.info заморожен.

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


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


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


Оглавление документа

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

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


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


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

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

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

мегакоммит

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


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


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

код и спек

Частным случаем мегакоммита является оформление изменений в коде/патчах и 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-бранча, до других ещё добраться надо). Ну и всякие мелочи вроде «утащить чужой бранч на посмотреть» работают одинаковым образом:


Страницы, ссылающиеся на данную: AltLinux/Sisyphus/devel/git


 
Файлов нет. [Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]