Редактирование: Git

{{DISPLAYTITLE:git}}
{{Stub}}
== Руководства ==

* [[Краткое руководство по сборке с gear]]
* [[Git.alt|Руководство по git.alt]]

== Всё о 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.alt|Руководство по git.alt]]
* [[Руководство по gear]]
* [[Справочник по git.alt]]
* Справочник по gear

__TOC__

=== GEAR ===

В апреле 2006 года идея хранить исходный код пакетов в git-репозитории была реализована с помощью утилиты, которая 27-го апреля получила имя [[gear|gear]].  Напомню вкратце:

Основной смысл хранения исходного кода пакетов в git-репозитории заключается в более эффективной и удобной совместной разработке, а также минимизации трафика и места на диске для хранения архива репозитория за длительный срок.  Идея <tt>gear</tt> заключается в том, чтобы с помощью одного файла с простыми правилами (для обработки которых достаточно <tt>git</tt>+<tt>sed</tt>) можно было собирать пакеты из произвольно устроенного git-репозитория, по аналогии с [[hasher]], который был задуман как средство собирать пакеты из произвольных srpm-пакетов.

За время, прошедшее с конца апреля, многие из вас успели освоиться с <tt>gear</tt>, появилась базовая документация, семейство вспомогательных утилит и опыт эксплуатации.  Поэтому весьма вероятно, что те из вас, кому только предстоит осваивать gear, пройдут этот путь гораздо легче и быстрее чем я.  :) Например, одна только утилита <tt>gear-srpmimport</tt> позволяет на начальном этапе вообще не интересоваться синтаксисом файла <tt>.gear-rules</tt>.

На всякий случай рекомендую установить/обновить пакет <tt>gear</tt>, а также освежить в своей памяти содержимое файлов <tt>/usr/share/doc/gear-1.4.0/QUICKSTART.ru.html</tt> и <tt>/usr/share/doc/git-1.5.5.3/tutorial.html</tt>

=== Структура репозитория ===

Как уже было сказано, <tt>gear</tt> не накладывает ограничений на внутреннюю организацию git-репозитория (не считая файла с правилами). Тем не менее, у меня есть несколько соображений о том, как более эффективно и удобно организовывать git-репозитории, предназначенные для хранения пакетов:

* Одна сущность — один репозиторий.
*: Не стоит помещать в один репозиторий несколько разных пакетов, за исключением случаев, когда у этих пакетов есть общий пакет-предок. Соблюдение этого правила облегчает совместную работу над пакетом, поскольку не перегруженный репозиторий легче клонировать и в целом инструментарий git больше подходит для работы с такими репозиториями.
*:: '''Отрицательная сторона''': несколько сложнее делать «push» и «pull» в случае, когда репозиториев, которые надо обработать, много. Впрочем, push/pull в цикле выручает.
* Несжатый исходный код.
*: Сжатый разными архиваторами исходный код (как правило это tarball’ы) лучше хранить в git-репозитории в несжатом виде. Изменение файлов, которые помещены в репозиторий в сжатом виде, менее удобно отслеживать штатными средствами (<tt>git-diff</tt>). Поскольку git хранит объекты в сжатом виде, двойное сжатие редко приводит к экономии дискового пространства. Наконец, алгоритм, применяемый для минимизации трафика при обновлении репозитория по протоколу git, заметно более эффективен на несжатых данных.
*:: '''Отрицательная сторона''': поскольку некоторые виды сжатия одних и тех же данных могут приводить к разным результатам, может уменьшиться степень первозданности (нативности) исходного кода.
* Распакованный исходный код.
*: Исходный код, запакованный tar/cpio/…, лучше хранить в git-репозитории в распакованном виде, по тем же причинам (заметно удобнее отслеживать изменения, существенно меньше трафик при обновлении).
*:: '''Отрицательная сторона''': поскольку git из информации о владельце, правах доступа и дате модификации файлов хранит только исполняемость файлов, любой архив, созданный из репозитория, будет по этим параметрам отличаться от первозданного. Помимо потери нативности, изменение прав доступа и даты модификации может теоретически повлиять на результат сборки пакета. Впрочем, такие пакеты, если они будут обнаружены, всё равно надо править.
* Аккуратный changelog.
*: В changelog релизного commit’а стоит включать соответствующий текст из changelog’а пакета, как это делают утилиты <tt>gear-commit</tt> (обёртка к <tt>git-commit</tt>, специально предназначенная для этих целей) и <tt>gear-srpmimport</tt>. В результате можно будет получить представление об изменениях в пакете, не заглядывая в spec-файл самого пакета.

=== Инструкция по эксплуатации git.altlinux.org ===

Для преодоления барьеров вида «админ закрыл наружу всё и оставил только прокси» ssh на git.altlinux.org доступен также и на порту 443, что можно [[fsi:SSHFirewall|использовать]].

По всем вопросам, связанным с этой частью инструкции, пишите на join@.

Клонировать к себе на компьютер свой репозиторий с git.altlinux.org (SSH предварительно [[Git.alt/Справочник#SSH-доступ|настроен]]):

 $ 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://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'а, сделать патч и отправить автору (да, в мире существуют <br />
> другие git-репозитории, помимо git.a.o). Совершенно обычный use-case для того <br />
> типа пользователя, кого сейчас в инфраструктуре совершенно игнорируют: casual <br />
> mantainers, которых почти всё устраивает, но иногда хочется написать патчик и <br />
> отправить обратно.

В принципе, даже той информации, которая есть в бинарном пакете сейчас,
уже достаточно для casual mantainers:

1. В установленном бинарном пакете есть %{SOURCERPM} (виден по rpmquery -i),
из которого однозначно вычисляется имя исходного пакета.

2. Далее, в установленном бинарном пакете есть %{CHANGELOGNAME} (виден по
rpmquery --lastchange).

3. По именам мантейнера (MAINT) и исходного пакета (PKG) можно с очень
высокой вероятностью предположить, что если пакет был собран из
git-репозитория, то этот репозиторий называется
<nowiki>http://git.altlinux.org/people/MAINT/packages/?p=PKG.git</nowiki>
{{Конец цитаты}}

=== Как вести пакет в git ===
{{Начало цитаты|источник={{man|damir}}}}
Посмотрите на 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). <br />
2. Смержить этот тег в master с -s ours <br />
3. Заменить в спеке версию с 0.1 на 0.2. <br />
4. Выполнить gear-update-tag -ac <br />
5. Дописать changelog
{{Конец цитаты}}

=== Как втащить пакет из Сизифа, если его нет на 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> в Сизифе, кто бы его ни собрал на этот раз.

=== 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) из него новые изменения.

Как это реализуется на практике?

Для поиска репозитория для клонирования используется команда <tt>find-package</tt>:
 $ ssh git.alt find-package bugzilla
 /people/vvk/packages/bugzilla.git	1168522087
 $
Склонировать репозиторий можно с помощью команды <tt>clone</tt>:
 $ 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, то <tt>git-push</tt> тоже работает:
 $ git push
 ...
 $
Нотификации производятся вручную - почтой или через bugzilla. Аналога pull request из github или gitorious на <tt>git.alt</tt> пока что нет.

Втягивание чужих изменений производится стандартными git-средствами: добавлением remote
 $ git remote add someuser ssh://git.alt/people/someuser/packages/bugzilla.git
засасыванием изменений:
 $ git fetch someuser master
наложением их:
 $ git merge someuser/master
и отправкой в <tt>git.alt</tt>:
 $ 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://freesource.info/wiki/RuslanHihin/GitTutorial1 Учебник «Введение в git» (для версии 1.5.1 или более поздней версии]
* [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://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://cworth.org/hgbook-git/tour/ A tour of git: the basics]
* '''[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/tutorial.html tutorial] по 1.5+, в частности
* [http://kernel.org/pub/software/scm/git/docs/howto/ Git Howtos]
* [http://git.or.cz/gitwiki/ GitWiki]
** [http://git.or.cz/gitwiki/GitDocumentation GitDocumentation]
** [http://git.or.cz/gitwiki/QuickStart QuickStart]
** [http://git.or.cz/gitwiki/IndexCommandQuickref IndexCommandQuickref]
** [http://git.or.cz/gitwiki/GitTips GitTips]
** [http://git.or.cz/gitwiki/GitFaq GitFaq]
** [http://git.or.cz/gitwiki/GitWorkflows GitWorkflows]
** [http://git.or.cz/gitwiki/ExampleScripts ExampleScripts]
** [http://git.or.cz/gitwiki/Aliases Aliases]
** [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://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://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.infoq.com/articles/dvcs-guide Distributed Version Control Systems: A Not-So-Quick Guide Through]
* [http://versioncontrolblog.com/ Version Control Blog]
* [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://www.rosipov.com/blog/use-vimdiff-as-git-mergetool/ Use vimdiff as git mergetool]

{{Category navigation|title=git|category=git|sortkey=*}}