git
Материал из ALT Linux Wiki
м (→Разное: +1 (vimdiff)) |
|||
(45 промежуточных версий не показаны.) | |||
Строка 1: | Строка 1: | ||
- | + | {{DISPLAYTITLE:git}} | |
{{Stub}} | {{Stub}} | ||
- | + | == Руководства == | |
- | + | ||
- | == | + | |
* [[Краткое руководство по сборке с gear]] | * [[Краткое руководство по сборке с gear]] | ||
+ | * [[Git.alt|Руководство по git.alt]] | ||
- | == Всё о GIT, со слов ldv == | + | == Всё о GIT, со слов ldv@ == |
- | + | На самом деле не про git как таковой, а про git применительно к ALT Linux и git.alt; некое подобие QuickStart по git@ALT для присматривающихся участников team — [[git/start|здесь]]. | |
- | + | В качестве введения в git смотрите [http://www.ibm.com/developerworks/ru/library/l-git/index.html?S_TACT=105AGX99&S_CMP=GR01 Управление исходным кодом с помощью Git] (на русском языке) и [http://www.kernel.org/pub/software/scm/git/docs/everyday.html Everyday GIT] (на английском языке). | |
- | '' | + | '''Примечание:''' все примеры команд, указываемых через дефис (например, <tt>git-clone</tt>) на последних версиях Git следует применять без дефиса, заменив его пробелом: <tt>git clone</tt>. |
- | + | NB: эту страницу (а также [[gear]], [[git/start2]], [[gear/geartags]], [[gear/ImportUpstreamVBranch]], [[gear/ImportSeparateUpstream]], [[git/recommit]], [[git/gitnotes]], [[git/SomeDestReposViaBranches]], [[git/MergingBranches]], [[git/BranchInGit]]) надо творчески раскромсать на: | |
* Введение в git + ссылки | * Введение в git + ссылки | ||
- | * Руководство по git.alt | + | * [[Git.alt|Руководство по git.alt]] |
- | * | + | * [[Руководство по gear]] |
- | * Справочник по git.alt | + | * [[Справочник по git.alt]] |
* Справочник по gear | * Справочник по gear | ||
__TOC__ | __TOC__ | ||
- | |||
=== GEAR === | === GEAR === | ||
- | В апреле | + | В апреле 2006 года идея хранить исходный код пакетов в git-репозитории была реализована с помощью утилиты, которая 27-го апреля получила имя [[gear|gear]]. Напомню вкратце: |
Основной смысл хранения исходного кода пакетов в git-репозитории заключается в более эффективной и удобной совместной разработке, а также минимизации трафика и места на диске для хранения архива репозитория за длительный срок. Идея <tt>gear</tt> заключается в том, чтобы с помощью одного файла с простыми правилами (для обработки которых достаточно <tt>git</tt>+<tt>sed</tt>) можно было собирать пакеты из произвольно устроенного git-репозитория, по аналогии с [[hasher]], который был задуман как средство собирать пакеты из произвольных srpm-пакетов. | Основной смысл хранения исходного кода пакетов в git-репозитории заключается в более эффективной и удобной совместной разработке, а также минимизации трафика и места на диске для хранения архива репозитория за длительный срок. Идея <tt>gear</tt> заключается в том, чтобы с помощью одного файла с простыми правилами (для обработки которых достаточно <tt>git</tt>+<tt>sed</tt>) можно было собирать пакеты из произвольно устроенного git-репозитория, по аналогии с [[hasher]], который был задуман как средство собирать пакеты из произвольных srpm-пакетов. | ||
Строка 37: | Строка 35: | ||
=== Структура репозитория === | === Структура репозитория === | ||
- | Как уже было сказано, <tt>gear</tt> не накладывает ограничений на внутреннюю организацию git-репозитория (не считая файла с правилами). | + | Как уже было сказано, <tt>gear</tt> не накладывает ограничений на внутреннюю организацию git-репозитория (не считая файла с правилами). Тем не менее, у меня есть несколько соображений о том, как более эффективно и удобно организовывать git-репозитории, предназначенные для хранения пакетов: |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
+ | * Одна сущность — один репозиторий. | ||
+ | *: Не стоит помещать в один репозиторий несколько разных пакетов, за исключением случаев, когда у этих пакетов есть общий пакет-предок. Соблюдение этого правила облегчает совместную работу над пакетом, поскольку не перегруженный репозиторий легче клонировать и в целом инструментарий git больше подходит для работы с такими репозиториями. | ||
+ | *:: '''Отрицательная сторона''': несколько сложнее делать «push» и «pull» в случае, когда репозиториев, которые надо обработать, много. Впрочем, push/pull в цикле выручает. | ||
* Несжатый исходный код. | * Несжатый исходный код. | ||
- | + | *: Сжатый разными архиваторами исходный код (как правило это tarball’ы) лучше хранить в git-репозитории в несжатом виде. Изменение файлов, которые помещены в репозиторий в сжатом виде, менее удобно отслеживать штатными средствами (<tt>git-diff</tt>). Поскольку git хранит объекты в сжатом виде, двойное сжатие редко приводит к экономии дискового пространства. Наконец, алгоритм, применяемый для минимизации трафика при обновлении репозитория по протоколу git, заметно более эффективен на несжатых данных. | |
- | * | + | *:: '''Отрицательная сторона''': поскольку некоторые виды сжатия одних и тех же данных могут приводить к разным результатам, может уменьшиться степень первозданности (нативности) исходного кода. |
- | + | ||
* Распакованный исходный код. | * Распакованный исходный код. | ||
- | + | *: Исходный код, запакованный tar/cpio/…, лучше хранить в git-репозитории в распакованном виде, по тем же причинам (заметно удобнее отслеживать изменения, существенно меньше трафик при обновлении). | |
- | * | + | *:: '''Отрицательная сторона''': поскольку git из информации о владельце, правах доступа и дате модификации файлов хранит только исполняемость файлов, любой архив, созданный из репозитория, будет по этим параметрам отличаться от первозданного. Помимо потери нативности, изменение прав доступа и даты модификации может теоретически повлиять на результат сборки пакета. Впрочем, такие пакеты, если они будут обнаружены, всё равно надо править. |
- | + | ||
* Аккуратный changelog. | * Аккуратный changelog. | ||
- | + | *: В changelog релизного commit’а стоит включать соответствующий текст из changelog’а пакета, как это делают утилиты <tt>gear-commit</tt> (обёртка к <tt>git-commit</tt>, специально предназначенная для этих целей) и <tt>gear-srpmimport</tt>. В результате можно будет получить представление об изменениях в пакете, не заглядывая в spec-файл самого пакета. | |
=== Инструкция по эксплуатации git.altlinux.org === | === Инструкция по эксплуатации git.altlinux.org === | ||
Строка 62: | Строка 57: | ||
Клонировать к себе на компьютер свой репозиторий с git.altlinux.org: | Клонировать к себе на компьютер свой репозиторий с git.altlinux.org: | ||
- | $ git | + | $ git clone git.alt:packages/vitmp.git |
remote: Generating pack... | remote: Generating pack... | ||
remote: Done counting 12 objects. | remote: Done counting 12 objects. | ||
Строка 70: | Строка 65: | ||
Клонировать к себе на компьютер чужой репозиторий с git.altlinux.org: | Клонировать к себе на компьютер чужой репозиторий с git.altlinux.org: | ||
- | $ git | + | $ git clone git.alt:/people/ldv/packages/vitmp.git |
Залить на git.alt свой ранее созданный git-репозиторий: | Залить на git.alt свой ранее созданный git-репозиторий: | ||
Строка 82: | Строка 77: | ||
Далее зафетчим этот бранч к нам с одноименным названием: | Далее зафетчим этот бранч к нам с одноименным названием: | ||
- | $ git | + | $ git fetch git.alt:/people/foo/packages/bar.git bar-bugfree:bar-bugfree |
Дальше работаем с ним как хотим ;) | Дальше работаем с ним как хотим ;) | ||
Строка 90: | Строка 85: | ||
Копирование файлов из одного бранча в другой: | Копирование файлов из одного бранча в другой: | ||
- | $ git | + | $ git archive --format=tar --prefix=directory-branchXXX branchXXX:directory | tar xf - |
и устаревший способ: | и устаревший способ: | ||
- | $ git | + | $ git tar-tree branchXXX:directory directory-branchXXX | tar xf - |
== Ответы на часто забываемые вопросы == | == Ответы на часто забываемые вопросы == | ||
- | === «Как найти | + | === «Как найти мейнтейнера?» === |
- | + | # [http://sisyphus.ru/srpm/spt/gear http://sisyphus.ru/srpm/spt/gear] (с датами и ссылками) | |
- | + | # [http://git.altlinux.org/people-packages-list http://git.altlinux.org/people-packages-list] | |
- | + | # см. ниже: | |
- | + | {{Начало цитаты|источник=[http://lists.altlinux.org/pipermail/devel/2007-March/043158.html ldv@]}} | |
- | > другие git-репозитории, помимо git.a.o). Совершенно обычный use-case для того | + | > Слить сорцы из git'а, сделать патч и отправить автору (да, в мире существуют <br /> |
- | > типа пользователя, кого сейчас в инфраструктуре совершенно игнорируют: casual | + | > другие git-репозитории, помимо git.a.o). Совершенно обычный use-case для того <br /> |
- | > mantainers, которых почти всё устраивает, но иногда хочется написать патчик и | + | > типа пользователя, кого сейчас в инфраструктуре совершенно игнорируют: casual <br /> |
+ | > mantainers, которых почти всё устраивает, но иногда хочется написать патчик и <br /> | ||
> отправить обратно. | > отправить обратно. | ||
+ | |||
В принципе, даже той информации, которая есть в бинарном пакете сейчас, | В принципе, даже той информации, которая есть в бинарном пакете сейчас, | ||
уже достаточно для casual mantainers: | уже достаточно для casual mantainers: | ||
+ | |||
1. В установленном бинарном пакете есть %{SOURCERPM} (виден по rpmquery -i), | 1. В установленном бинарном пакете есть %{SOURCERPM} (виден по rpmquery -i), | ||
из которого однозначно вычисляется имя исходного пакета. | из которого однозначно вычисляется имя исходного пакета. | ||
+ | |||
2. Далее, в установленном бинарном пакете есть %{CHANGELOGNAME} (виден по | 2. Далее, в установленном бинарном пакете есть %{CHANGELOGNAME} (виден по | ||
rpmquery --lastchange). | rpmquery --lastchange). | ||
+ | |||
3. По именам мантейнера (MAINT) и исходного пакета (PKG) можно с очень | 3. По именам мантейнера (MAINT) и исходного пакета (PKG) можно с очень | ||
высокой вероятностью предположить, что если пакет был собран из | высокой вероятностью предположить, что если пакет был собран из | ||
git-репозитория, то этот репозиторий называется | git-репозитория, то этот репозиторий называется | ||
- | http://git.altlinux.org/people/MAINT/packages/?p=PKG.git</ | + | <nowiki>http://git.altlinux.org/people/MAINT/packages/?p=PKG.git</nowiki> |
- | + | {{Конец цитаты}} | |
=== Как вести пакет в git === | === Как вести пакет в git === | ||
- | = | + | {{Начало цитаты|источник={{man|damir}}}} |
- | + | Посмотрите на http://git.altlinux.org/people/damir/packages/?p=liblazy.git;a=summary | |
Там правда апстрим git-овый, но это сути не меняет. | Там правда апстрим git-овый, но это сути не меняет. | ||
Строка 133: | Строка 133: | ||
При переезде на новую версию надо будет всего лишь: | При переезде на новую версию надо будет всего лишь: | ||
- | 1. Поставить нужный тег на апстримной ветке (например liblazy-0.2). | + | 1. Поставить нужный тег на апстримной ветке (например liblazy-0.2). <br /> |
- | 2. Смержить этот тег в master с -s ours | + | 2. Смержить этот тег в master с -s ours <br /> |
- | 3. Заменить в спеке версию с 0.1 на 0.2. | + | 3. Заменить в спеке версию с 0.1 на 0.2. <br /> |
- | 4. Выполнить gear-update-tag -ac | + | 4. Выполнить gear-update-tag -ac <br /> |
- | 5. Дописать changelog | + | 5. Дописать changelog |
+ | {{Конец цитаты}} | ||
=== Как втащить пакет из Сизифа, если его нет на git.alt/people === | === Как втащить пакет из Сизифа, если его нет на git.alt/people === | ||
- | Пакет, который давно не собирался или заброшен, или его | + | Пакет, который давно не собирался или заброшен, или его мейнтейнер не пользуется git.alt, можно найти в [http://git.altlinux.org/archive/ архиве Сизифа]. Архив Сизифа содержит последние версии когда-либо собиравшихся в Сизиф пакетов (с историей) и доступен по <tt>ssh git.alt</tt> в каталоге <tt>/archive</tt>. Для удобства хранилища собраны в двухуровневое дерево (по первой букве), без различия мейнтейнеров. |
Таким образом ''на сегодня'' <tt>git-clone git.alt:/archive/m/mkimage</tt> отдаст хранилище, соответствующее текущему пакету <tt>mkimage</tt> в Сизифе, кто бы его ни собрал на этот раз. | Таким образом ''на сегодня'' <tt>git-clone git.alt:/archive/m/mkimage</tt> отдаст хранилище, соответствующее текущему пакету <tt>mkimage</tt> в Сизифе, кто бы его ни собрал на этот раз. | ||
Строка 185: | Строка 186: | ||
Втягивание чужих изменений производится стандартными git-средствами: добавлением remote | Втягивание чужих изменений производится стандартными git-средствами: добавлением remote | ||
- | $ git remote add someuser ssh://git.alt/people/someuser/bugzilla.git | + | $ git remote add someuser ssh://git.alt/people/someuser/packages/bugzilla.git |
засасыванием изменений: | засасыванием изменений: | ||
$ git fetch someuser master | $ git fetch someuser master | ||
Строка 193: | Строка 194: | ||
$ git push | $ git push | ||
- | == | + | == Удаление удалённых веток в git == |
- | + | ||
- | + | ||
- | + | ||
- | + | Если вы хотите удалить ветку из репозитория, располагающегося не на вашей машине — сделайте в него <tt>push</tt> из «никакой» ветки: | |
- | + | ||
- | + | ||
- | + | ||
+ | git push origin :no-longer-needed-branch | ||
+ | |||
+ | или если хотите удалить тег: | ||
+ | |||
+ | git push origin :no-longer-needed-tag | ||
+ | |||
+ | Полная форма <tt>push</tt> выглядит так: | ||
+ | git push <remote repository> [<local branch>:]<remote branch> | ||
+ | |||
+ | где <tt><local branch></tt> — имя локальной ветки, из которой берутся данные, а <tt><remote branch></tt> — имя ветки в удалённом репозитории, куда происходит их передача с замещением имеющегося. Привычный вид <tt>git push <remote repo> <remote branch></tt> является лишь одной из реализаций этой полной формы. | ||
+ | |||
+ | ==Апстрим в SVN== | ||
+ | {{main|Git/svn}} | ||
+ | |||
+ | <div id="links"></div> | ||
== Ссылки == | == Ссылки == | ||
- | * [http:// | + | === По-русски === |
- | * [http:// | + | * [http://freesource.info/wiki/RuslanHihin/GitTutorial1 Учебник «Введение в git» (для версии 1.5.1 или более поздней версии] |
- | * [http:// | + | * [http://freesource.info/wiki/RuslanHihin/20povsedevnyxkomandgit 20 повседневных команд git] |
- | * [ | + | * [http://freesource.info/wiki/RuslanHihin/GitUserManual Главы из руководства пользователя git] |
- | * [ | + | * [http://los-t.livejournal.com/tag/git%20guts git guts] (внутренности git) |
- | * [ | + | * [http://blog.tarantsov.com/2008/11/essential-git.html Введение в структуру хранилища git] (полезно для понимания происходящего) |
- | * [http:// | + | * [http://admdev.blogspot.com/2009/02/git.html Практическое введение в git] (нечто вроде quickstart без привязки к специфике ALT) |
- | + | * [http://git-scm.com/book/ru/v2 Pro git] (перевод второго издания вышедшей недавно книги, без привязки к специфике ALT) | |
+ | * [http://wiki.etersoft.ru/UsesGit Использование Git для разработки в Etersoft] | ||
+ | * [http://www.opennet.ru/base/dev/git_kung_fu.txt.html Правила хорошего тона при работе с git в многопользовательском окружении] | ||
+ | |||
+ | === Вводные статьи === | ||
* [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control (Illustrated]) | * [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control (Illustrated]) | ||
- | * [http:// | + | * [http://cworth.org/hgbook-git/tour/ A tour of git: the basics] |
- | * [http://www. | + | * '''[http://www.kernel.org/pub/software/scm/git/docs/giteveryday.html Everyday Git] With 20 Commands Or So''' |
- | * | + | * [http://git.or.cz/course/svn.html ...для SVN-щика] |
- | * | + | |
- | * | + | === Официальная документация === |
+ | * [http://www.kernel.org/pub/software/scm/git/docs/user-manual.html Git User's Manual] | ||
+ | * [http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html gittutorial(7)] | ||
+ | * [http://kernel.org/pub/software/scm/git/docs/howto/ Git Howtos] | ||
* [http://git.or.cz/gitwiki/ GitWiki] | * [http://git.or.cz/gitwiki/ GitWiki] | ||
** [http://git.or.cz/gitwiki/GitDocumentation GitDocumentation] | ** [http://git.or.cz/gitwiki/GitDocumentation GitDocumentation] | ||
Строка 228: | Строка 245: | ||
** [http://git.or.cz/gitwiki/Aliases Aliases] | ** [http://git.or.cz/gitwiki/Aliases Aliases] | ||
** [http://git.or.cz/gitwiki/GitGlossary GitGlossary] | ** [http://git.or.cz/gitwiki/GitGlossary GitGlossary] | ||
+ | |||
+ | === tips&tricks === | ||
+ | * [[git/recommit|Как переделать commit, в котором сразу же нашёлся ляп]] | ||
+ | * [[git/MergingBranches|Как мержить бранчи]], поддерживая пакет с N пересекающимися патчами | ||
* [http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html Zack Rusin: Git cheat sheet] ([http://www.samlown.com/uploads/documents/git-cheat-sheet-a4.pdf A4]) | * [http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html Zack Rusin: Git cheat sheet] ([http://www.samlown.com/uploads/documents/git-cheat-sheet-a4.pdf A4]) | ||
+ | * [http://tomayko.com/writings/the-thing-about-git The Thing About Git] | ||
+ | * [http://article.gmane.org/gmane.comp.version-control.git/31625 Branching and merging with git] | ||
+ | * [http://www.ndpsoftware.com/git-cheatsheet.html Wonderful git cheatsheet] | ||
+ | |||
+ | === Разное === | ||
+ | * [http://github.com/guides GitHub: Git Guides] | ||
+ | * [http://www.gitcasts.com/ GitCasts] | ||
+ | * [http://gitfu.wordpress.com/ git-fu] | ||
+ | * [http://lwn.net/Articles/245678/ Линкдамп] по документации git | ||
+ | * [http://www-cs-students.stanford.edu/~blynn/gitmagic/index.html Git Magic] | ||
* [http://linux.yyz.us/git-howto.html Kernel Hackers' Guide to git] | * [http://linux.yyz.us/git-howto.html Kernel Hackers' Guide to git] | ||
- | * [http:// | + | * [http://osteele.com/archives/2008/05/my-git-workflow My Git Workflow] |
+ | * [http://www.opensolaris.org/os/community/tools/scm/git-report-final.txt Обзор git] для сообщества OpenSolaris | ||
* [http://www.sourcemage.org/Git_Guide Git Guide - SourceMage Wiki] | * [http://www.sourcemage.org/Git_Guide Git Guide - SourceMage Wiki] | ||
- | * [http://www | + | * [http://www.infoq.com/articles/dvcs-guide Distributed Version Control Systems: A Not-So-Quick Guide Through] |
- | + | ||
* [http://versioncontrolblog.com/ Version Control Blog] | * [http://versioncontrolblog.com/ Version Control Blog] | ||
- | * [http:// | + | * [http://thread.gmane.org/gmane.comp.video.dri.devel/34739/focus=34744 Linux kernel "clean history" tips] |
- | + | * [http://krlmlr.github.io/using-gitattributes-to-avoid-merge-conflicts/ Using .gitattributes to avoid merge conflicts] (по NEWS и подобным) | |
- | * [http:// | + | * [http://www.rosipov.com/blog/use-vimdiff-as-git-mergetool/ Use vimdiff as git mergetool] |
- | * [http:// | + | |
+ | {{Category navigation|title=git|category=git|sortkey=*}} |
Текущая версия на 15:00, 31 мая 2017
Руководства
Всё о GIT, со слов ldv@
На самом деле не про git как таковой, а про git применительно к ALT Linux и git.alt; некое подобие QuickStart по git@ALT для присматривающихся участников team — здесь.
В качестве введения в git смотрите Управление исходным кодом с помощью Git (на русском языке) и Everyday GIT (на английском языке).
Примечание: все примеры команд, указываемых через дефис (например, git-clone) на последних версиях Git следует применять без дефиса, заменив его пробелом: git clone.
NB: эту страницу (а также gear, git/start2, gear/geartags, gear/ImportUpstreamVBranch, gear/ImportSeparateUpstream, git/recommit, git/gitnotes, git/SomeDestReposViaBranches, git/MergingBranches, git/BranchInGit) надо творчески раскромсать на:
- Введение в git + ссылки
- Руководство по git.alt
- Руководство по gear
- Справочник по git.alt
- Справочник по gear
Содержание |
GEAR
В апреле 2006 года идея хранить исходный код пакетов в git-репозитории была реализована с помощью утилиты, которая 27-го апреля получила имя gear. Напомню вкратце:
Основной смысл хранения исходного кода пакетов в git-репозитории заключается в более эффективной и удобной совместной разработке, а также минимизации трафика и места на диске для хранения архива репозитория за длительный срок. Идея gear заключается в том, чтобы с помощью одного файла с простыми правилами (для обработки которых достаточно git+sed) можно было собирать пакеты из произвольно устроенного git-репозитория, по аналогии с hasher, который был задуман как средство собирать пакеты из произвольных srpm-пакетов.
За время, прошедшее с конца апреля, многие из вас успели освоиться с gear, появилась базовая документация, семейство вспомогательных утилит и опыт эксплуатации. Поэтому весьма вероятно, что те из вас, кому только предстоит осваивать gear, пройдут этот путь гораздо легче и быстрее чем я. :) Например, одна только утилита gear-srpmimport позволяет на начальном этапе вообще не интересоваться синтаксисом файла .gear-rules.
На всякий случай рекомендую установить/обновить пакет gear, а также освежить в своей памяти содержимое файлов /usr/share/doc/gear-1.4.0/QUICKSTART.ru.html и /usr/share/doc/git-1.5.5.3/tutorial.html
Структура репозитория
Как уже было сказано, gear не накладывает ограничений на внутреннюю организацию git-репозитория (не считая файла с правилами). Тем не менее, у меня есть несколько соображений о том, как более эффективно и удобно организовывать git-репозитории, предназначенные для хранения пакетов:
- Одна сущность — один репозиторий.
- Не стоит помещать в один репозиторий несколько разных пакетов, за исключением случаев, когда у этих пакетов есть общий пакет-предок. Соблюдение этого правила облегчает совместную работу над пакетом, поскольку не перегруженный репозиторий легче клонировать и в целом инструментарий git больше подходит для работы с такими репозиториями.
- Отрицательная сторона: несколько сложнее делать «push» и «pull» в случае, когда репозиториев, которые надо обработать, много. Впрочем, push/pull в цикле выручает.
- Не стоит помещать в один репозиторий несколько разных пакетов, за исключением случаев, когда у этих пакетов есть общий пакет-предок. Соблюдение этого правила облегчает совместную работу над пакетом, поскольку не перегруженный репозиторий легче клонировать и в целом инструментарий git больше подходит для работы с такими репозиториями.
- Несжатый исходный код.
- Сжатый разными архиваторами исходный код (как правило это tarball’ы) лучше хранить в git-репозитории в несжатом виде. Изменение файлов, которые помещены в репозиторий в сжатом виде, менее удобно отслеживать штатными средствами (git-diff). Поскольку git хранит объекты в сжатом виде, двойное сжатие редко приводит к экономии дискового пространства. Наконец, алгоритм, применяемый для минимизации трафика при обновлении репозитория по протоколу git, заметно более эффективен на несжатых данных.
- Отрицательная сторона: поскольку некоторые виды сжатия одних и тех же данных могут приводить к разным результатам, может уменьшиться степень первозданности (нативности) исходного кода.
- Сжатый разными архиваторами исходный код (как правило это tarball’ы) лучше хранить в git-репозитории в несжатом виде. Изменение файлов, которые помещены в репозиторий в сжатом виде, менее удобно отслеживать штатными средствами (git-diff). Поскольку git хранит объекты в сжатом виде, двойное сжатие редко приводит к экономии дискового пространства. Наконец, алгоритм, применяемый для минимизации трафика при обновлении репозитория по протоколу git, заметно более эффективен на несжатых данных.
- Распакованный исходный код.
- Исходный код, запакованный tar/cpio/…, лучше хранить в git-репозитории в распакованном виде, по тем же причинам (заметно удобнее отслеживать изменения, существенно меньше трафик при обновлении).
- Отрицательная сторона: поскольку git из информации о владельце, правах доступа и дате модификации файлов хранит только исполняемость файлов, любой архив, созданный из репозитория, будет по этим параметрам отличаться от первозданного. Помимо потери нативности, изменение прав доступа и даты модификации может теоретически повлиять на результат сборки пакета. Впрочем, такие пакеты, если они будут обнаружены, всё равно надо править.
- Исходный код, запакованный tar/cpio/…, лучше хранить в git-репозитории в распакованном виде, по тем же причинам (заметно удобнее отслеживать изменения, существенно меньше трафик при обновлении).
- Аккуратный changelog.
- В changelog релизного commit’а стоит включать соответствующий текст из changelog’а пакета, как это делают утилиты gear-commit (обёртка к git-commit, специально предназначенная для этих целей) и gear-srpmimport. В результате можно будет получить представление об изменениях в пакете, не заглядывая в spec-файл самого пакета.
Инструкция по эксплуатации git.altlinux.org
Для преодоления барьеров вида «админ закрыл наружу всё и оставил только прокси» ssh на git.altlinux.org доступен также и на порту 443, что можно использовать.
По всем вопросам, связанным с этой частью инструкции, пишите на join@.
Клонировать к себе на компьютер свой репозиторий с git.altlinux.org:
$ git clone git.alt:packages/vitmp.git remote: Generating pack... remote: Done counting 12 objects. remote: Deltifying 12 objects. remote: 100% (12/12) done remote: Total 12, written 12 (delta 2), reused 12 (delta 2)
Клонировать к себе на компьютер чужой репозиторий с git.altlinux.org:
$ git clone git.alt:/people/ldv/packages/vitmp.git
Залить на git.alt свой ранее созданный git-репозиторий:
cd ~/package $ git push --all git.alt:packages/package.git
Представим, что некий foo сделал какие-либо изменения для нашего пакета bar в бранче bar-bugfree и выложил их на git.alt. Узнаем, как называется его этот бранч:
$ git ls-remote git.alt:/people/foo/packages/bar.git
Далее зафетчим этот бранч к нам с одноименным названием:
$ git fetch git.alt:/people/foo/packages/bar.git bar-bugfree:bar-bugfree
Дальше работаем с ним как хотим ;)
Удалить бранч на git.alt (задав пустое имя локального бранча):
$ git push ... :branch
Копирование файлов из одного бранча в другой:
$ git archive --format=tar --prefix=directory-branchXXX branchXXX:directory | tar xf -
и устаревший способ:
$ git tar-tree branchXXX:directory directory-branchXXX | tar xf -
Ответы на часто забываемые вопросы
«Как найти мейнтейнера?»
- http://sisyphus.ru/srpm/spt/gear (с датами и ссылками)
- http://git.altlinux.org/people-packages-list
- см. ниже:
ldv@:
> Слить сорцы из git'а, сделать патч и отправить автору (да, в мире существуют
> другие git-репозитории, помимо git.a.o). Совершенно обычный use-case для того
> типа пользователя, кого сейчас в инфраструктуре совершенно игнорируют: casual
> mantainers, которых почти всё устраивает, но иногда хочется написать патчик и
> отправить обратно.В принципе, даже той информации, которая есть в бинарном пакете сейчас, уже достаточно для casual mantainers:
1. В установленном бинарном пакете есть %{SOURCERPM} (виден по rpmquery -i), из которого однозначно вычисляется имя исходного пакета.
2. Далее, в установленном бинарном пакете есть %{CHANGELOGNAME} (виден по rpmquery --lastchange).
3. По именам мантейнера (MAINT) и исходного пакета (PKG) можно с очень высокой вероятностью предположить, что если пакет был собран из git-репозитория, то этот репозиторий называется http://git.altlinux.org/people/MAINT/packages/?p=PKG.git
Как вести пакет в git
Посмотрите на http://git.altlinux.org/people/damir/packages/?p=liblazy.git;a=summary
Там правда апстрим git-овый, но это сути не меняет. .gear-rules там состоит из одной строчки - вот такой:
tar.bz2: @name@-@version@:.
@name@ и @version@ берутся из спека. @name@ - это liblazy. а @version@ - это 0.1
На ветке upstream присутствует тег liblazy-0.1. Поэтому апстримный тарбол будет браться из этого тега.
При переезде на новую версию надо будет всего лишь:
1. Поставить нужный тег на апстримной ветке (например liblazy-0.2).
2. Смержить этот тег в master с -s ours
3. Заменить в спеке версию с 0.1 на 0.2.
4. Выполнить gear-update-tag -ac
5. Дописать changelog
Как втащить пакет из Сизифа, если его нет на git.alt/people
Пакет, который давно не собирался или заброшен, или его мейнтейнер не пользуется git.alt, можно найти в архиве Сизифа. Архив Сизифа содержит последние версии когда-либо собиравшихся в Сизиф пакетов (с историей) и доступен по ssh git.alt в каталоге /archive. Для удобства хранилища собраны в двухуровневое дерево (по первой букве), без различия мейнтейнеров.
Таким образом на сегодня git-clone git.alt:/archive/m/mkimage отдаст хранилище, соответствующее текущему пакету mkimage в Сизифе, кто бы его ни собрал на этот раз.
workflow
Совместная работа над пакетами в git строится по следующей схеме:
[ user A ] [ user B ] | [repo A/X] | | | | | |----------+-->[repo B/X] -- B клонирует репозиторий A/X в свой B/X | | | | | | |------>| -- B работает над содержимым репозитория | | |------>| | | |------>| -- B решает, что результат ему нравится |<-----------------| | -- B оповещает A о том, что в B/X | | | | имеется что-то новое |-------+<-----------------| -- A добавляет (pull/push) содержимое | | | | B/X в A/X
При дальнейшей работе сценарий повторяется, за исключением того, что B не клонирует репозиторий A/X, а подтягивает (pull) из него новые изменения.
Как это реализуется на практике?
Для поиска репозитория для клонирования используется команда find-package:
$ ssh git.alt find-package bugzilla /people/vvk/packages/bugzilla.git 1168522087 $
Склонировать репозиторий можно с помощью команды clone:
$ ssh git.alt clone /people/vvk/packages/bugzilla.git Initialized empty Git repository in /people/dottedmag/packages/bugzilla.git/ $
Эта команда создаст вашу копию репозитория на сервере git.alt. Для работы с ним необходимо склонировать этот репозиторий на локальную машину:
$ git clone ssh://git.alt/people/dottedmag/packages/bugzilla.git Initialized empty Git repository in /home/dottedmag/bugzilla/.git/ .... $
С этим git-репозиторием можно работать как обычно: править, делать commit и так далее. Поскольку для склонированного репозитория создаётся remote с названием origin, то git-push тоже работает:
$ git push ... $
Нотификации производятся вручную - почтой или через bugzilla. Аналога pull request из github или gitorious на git.alt пока что нет.
Втягивание чужих изменений производится стандартными git-средствами: добавлением remote
$ git remote add someuser ssh://git.alt/people/someuser/packages/bugzilla.git
засасыванием изменений:
$ git fetch someuser master
наложением их:
$ git merge someuser/master
и отправкой в git.alt:
$ git push
Удаление удалённых веток в git
Если вы хотите удалить ветку из репозитория, располагающегося не на вашей машине — сделайте в него push из «никакой» ветки:
git push origin :no-longer-needed-branch
или если хотите удалить тег:
git push origin :no-longer-needed-tag
Полная форма push выглядит так:
git push <remote repository> [<local branch>:]<remote branch>
где <local branch> — имя локальной ветки, из которой берутся данные, а <remote branch> — имя ветки в удалённом репозитории, куда происходит их передача с замещением имеющегося. Привычный вид git push <remote repo> <remote branch> является лишь одной из реализаций этой полной формы.
Апстрим в SVN
Ссылки
По-русски
- Учебник «Введение в git» (для версии 1.5.1 или более поздней версии
- 20 повседневных команд git
- Главы из руководства пользователя git
- git guts (внутренности git)
- Введение в структуру хранилища git (полезно для понимания происходящего)
- Практическое введение в git (нечто вроде quickstart без привязки к специфике ALT)
- Pro git (перевод второго издания вышедшей недавно книги, без привязки к специфике ALT)
- Использование Git для разработки в Etersoft
- Правила хорошего тона при работе с git в многопользовательском окружении
Вводные статьи
- Intro to Distributed Version Control (Illustrated)
- A tour of git: the basics
- Everyday Git With 20 Commands Or So
- ...для SVN-щика
Официальная документация
tips&tricks
- Как переделать commit, в котором сразу же нашёлся ляп
- Как мержить бранчи, поддерживая пакет с N пересекающимися патчами
- Zack Rusin: Git cheat sheet (A4)
- The Thing About Git
- Branching and merging with git
- Wonderful git cheatsheet
Разное
- GitHub: Git Guides
- GitCasts
- git-fu
- Линкдамп по документации git
- Git Magic
- Kernel Hackers' Guide to git
- My Git Workflow
- Обзор git для сообщества OpenSolaris
- Git Guide - SourceMage Wiki
- Distributed Version Control Systems: A Not-So-Quick Guide Through
- Version Control Blog
- Linux kernel "clean history" tips
- Using .gitattributes to avoid merge conflicts (по NEWS и подобным)
- Use vimdiff as git mergetool