Alt linux install git

Alt linux install git

На самом деле не про git как таковой, а про git применительно к ALT Linux и git.alt; некое подобие QuickStart по git@ALT для присматривающихся участников team — здесь.

В качестве введения в git смотрите Управление исходным кодом с помощью Git (на русском языке) и Everyday GIT (на английском языке).

Примечание: все примеры команд, указываемых через дефис (например, git-clone) на последних версиях Git следует применять без дефиса, заменив его пробелом: git clone.

• 1 Руководства
• 2 Всё о GIT, со слов ldv@
  • 2.1 GEAR
  • 2.2 Структура репозитория
  • 2.3 Инструкция по эксплуатации git.altlinux.org
  • 3.1 «Как найти мейнтейнера?»
  • 3.2 Как вести пакет в git
  • 3.3 Как втащить пакет из Сизифа, если его нет на git.alt/people
  • 3.4 workflow
  • 6.1 По-русски
  • 6.2 Вводные статьи
  • 6.3 Официальная документация
  • 6.4 tips&tricks
  • 6.5 Разное

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

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

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

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

  Клонировать к себе на компьютер свой репозиторий с git.altlinux.org (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 archive --format=tar --prefix=directory-branchXXX branchXXX:directory | tar xf -

  $ git tar-tree branchXXX:directory directory-branchXXX | tar xf -

  Ответы на часто забываемые вопросы

  «Как найти мейнтейнера?»

  > Слить сорцы из git’а, сделать патч и отправить автору (да, в мире существуют
  > другие git-репозитории, помимо git.a.o). Совершенно обычный use-case для того
  > типа пользователя, кого сейчас в инфраструктуре совершенно игнорируют: casual
  > mantainers, которых почти всё устраивает, но иногда хочется написать патчик и
  > отправить обратно.

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

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

  2. Далее, в установленном бинарном пакете есть % (виден по 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 тоже работает:

  Нотификации производятся вручную - почтой или через bugzilla. Аналога pull request из github или gitorious на git.alt пока что нет.

  Втягивание чужих изменений производится стандартными git-средствами: добавлением remote

  $ git fetch someuser master

  Удаление удалённых веток в git

  Если вы хотите удалить ветку из репозитория, располагающегося не на вашей машине — сделайте в него push из «никакой» ветки:

  git push origin :no-longer-needed-branch

  или если хотите удалить тег:

  git push origin :no-longer-needed-tag

  Полная форма push выглядит так:

  где — имя локальной ветки, из которой берутся данные, а — имя ветки в удалённом репозитории, куда происходит их передача с замещением имеющегося. Привычный вид git push является лишь одной из реализаций этой полной формы.

  Апстрим в SVN

  Ссылки

  По-русски

  • Учебник «Введение в git» (для версии 1.5.1 или более поздней версии
  • 20 повседневных команд git
  • Главы из руководства пользователя git
  • git guts (внутренности git)
  • Введение в структуру хранилища git (полезно для понимания происходящего)
  • Практическое введение в git (нечто вроде quickstart без привязки к специфике ALT)
  • Pro git (перевод второго издания вышедшей недавно книги, без привязки к специфике ALT)
  • Использование Git для разработки в Etersoft
  • Правила хорошего тона при работе с git в многопользовательском окружении

  Вводные статьи

  Официальная документация

  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

  Источник

  Читайте также:  Linux самые тяжелые папки