20 повседневных команд git 

Перевод Everyday GIT With 20 Commands Or So

Команды работы с [Базисные команды репозитория] нужны всем, у кого есть репозиторий, т.е. любому, работающему с git хранилищем.

Кроме того, важное значение для всех, кто создаёт коммиты, даже если он работает один, важное значение имеют комады [Индивидуальная разработка (Автономный режим)].

Если вы работаете совместно с другими людьми, вам потребуются команды, перечисленные в разделе [Индивидуальная разработка (Совместный режим)].

Людям, которые играют роль [Интегратора], необходимо знать помимо этого ещё несколько команд..

Команды [Администрирование репозитория] важны для системных администраторов которые несут ответственность за работоспособность git репозиториия.

Обратите внимание: в современных выпусках git man-страницы остались по-прежнему (man git-log), а вот команда теперь одна — например, вместо git-init и git-add применяйте git init и git add.

Базисные команды репозитория

Эти команды повседневно используются при работе с git репозиторием.

* git-init(1) и git-clone(1) создают новый репозиторий.

* git-fsck(1), проверяет репозиторий на ошибки.

* git-gc(1) to do common housekeeping tasks such as repack and prune.

* git-gc(1) решает общие задачи сохранения репозитория, такие как переупаковки и «убирание мусора».

Примеры

Проверка «здоровья» репозитория и удаление из него мусора.

$ git fsck ( ¹ )

$ git count-objects ( ² )

$ git gc ( ³ )

( ¹ ) Даже запуская без --full, вы легко и надёжно проверяете «здоровье» репозитория.

( ² ) Проверка, сколько объектов будет потеряно и объём освобождаемого места при перепаковке репозитория.

( ³ ) переупаковка локальных репозиториев и другие виды повседневныз задач.

Упаковка небольших проектов в один пакет.

$ git gc ( ¹ )

( ¹ ) . паковать все объекты доступные из «ссылок» (refs) в одну упаковку, затем удалить другие упаковки.

Индивидуальная разработка (Автономный режим)

Автономный индивидуальный разработчик не обменивается патчами с другими людьми, а работает только в одном репозитории, используя

следующие команды.

* git-show-branch(1) – посмотреть где вы (в какой ветке).

* git-log(1) – посмотреть что в логах.

* git-checkout(1) и git-branch(1) – переключение ветвей.

* git-add(1) – управление файлом индекса.

* git-diff(1) и git-status(1) – посмотреть что вы уже сделали в течении работы.

* git-commit(1) зафиксировать (создать коммит) в текущей ветке.

* git-reset(1) и git-checkout(1) (с параметрами пути) – отмена последних изменений изменений (откат изменений).

* git-merge(1) – слить (объединить) локальные ветви репозитория.

* git-rebase(1) – обновление локальной ветки до заданного репозитория и добавление необходимых коммитов.

* git-tag(1) – задать именованную метку для коммита (текущей точки).

Примеры

Используем тарбол, как отправную точку для нового репозитория.

$ tar zxf frotz.tar.gz

$ cd frotz

$ git-init

$ git add . ( ¹ )

$ git commit -m “import of frotz source tree.”

$ git tag v2.43 ( ² )

( ¹ ) Добавляем все измениия и файлы в текущем директории.

( ² ) Создаём легкий, неаннотированный тег

Создаём топик (имя) ветки и работаем с ней.

$ git checkout -b alsa-audio ( ¹ )

$ edit/compile/test

$ git checkout — curses/ux_audio_oss.c ( ² )

$ git add curses/ux_audio_alsa.c ( ³ )

$ edit/compile/test

$ git diff HEAD ( ⁴ )

$ git commit -a -s ( ⁵ )

$ edit/compile/test

$ git reset --soft HEAD^ ( ⁶ )

$ edit/compile/test

$ git diff ORIG_HEAD ( ⁷ )

$ git commit -a -c ORIG_HEAD ( ⁸ )

$ git checkout master ( ⁹ )

$ git merge alsa-audio ( ¹⁰ )

$ git log --since='3 days ago' ( ¹¹ )

$ git log v2.43.. curses/ ( ¹² )

¹. создаем новую ветку с именем (топиком) alsa-audio.

². отменяем ваши неудачные изменения в curses/ux_audio_oss.c

³. вам нужно указать git, что вы добавили новый файл; другие удаление и изменения будет не замечены, если сделать git commit.

⁴. смотрим, какие изменения Вы будете фиксировать при выполнении git-commit.

⁵. фиксируем всё так-вы проверили, подписывая коммит.

⁶. отменяем последний коммит, сохраняя его в рабочем дереве.

⁷. смотрим на изменения сделанные в отменённом нами коммите.

⁸. возвращаем предыдущий коммит используя при записи сообщение оригинала.

⁹. переключиться на ветвь master.

¹⁰. объединяем ветку топика alsa-audio с веткой master.

¹¹. смотрим логи коммита; другие формы могут ограничивать вывод и комбинироваться и включать

--max-count=10 (показать не больше 10 коммитов),

--until=2005–12–10 (до 10 декабря 2005г) и т.д.

¹². смотрим изменения, находящиеся в директории curses/ в коммите v2.43

Индивидуальная разработка (Совместный режим)

Разработчик участвуя в совместном проекте группы должен уметь общаться с другими участниками и использовать команды, помимо тех, что нужны в Автономной работе :

* git-clone(1) – создать точную копию основного репозитория разработки в своём локальном хранилище.

* git-pull(1) и git-fetch(1) – получает из “origin” основного репозитория и сохраняет изменения в звашем репозитории.

* git-push(1) помещает в общее хранилище, если у вашего общего Git репозитория принят стиль CVS.

* git-format-patch(1) готовит патч в представлении e-mail, если у вашего общего репозитория принят стиль «ядра Linux».

Примеры

Клонируем основной репозиторий и работаем с ним. Передаём изменения в основной репозиторий.

$ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6

$ cd my2.6

$ edit/compile/test; git commit -a -s ( ¹ )

$ git format-patch origin ( ² )

$ git pull ( ³ )

$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 ( ⁴ )

$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL ( ⁵ )

$ git reset --hard ORIG_HEAD ( ⁶ )

$ git gc ( ⁷ )

$ git fetch --tags ( ⁸ )

¹. повторяем по мере необходимости.

². извлекаем патчи из вашей ветки в e-mail виде.

³. git pull извлекает из origin (по-умолчанию) и объединяет с текущей веткой.

⁴. сразу после git pull, смотрим сделанные «апстримом» в последнее время изменения в области кода, которая нас интересует.

⁵. извлекаем изменения из конкретной ветки конкретного репозитория и объединяем их.

⁶. возвращаемся через git pull .

⁷. убираем мусор от оставшихся объектов после git-pull.

⁸. Время от времени, получать официальные метки из origin и сохраняем их в соответствии в .git/refs/tags/.

Передача в другой репоззиторий

satellite$ git clone mothership:frotz frotz ( ¹ )

satellite$ cd frotz

satellite$ git config --get-regexp '^(remote|branch)\.' ( ² )

remote.origin.url mothership:frotz

remote.origin.fetch refs/heads/*:refs/remotes/origin/*

branch.master.remote origin

branch.master.merge refs/heads/master

satellite$ git config remote.origin.push \

master:refs/remotes/satellite/master ( ³ )

satellite$ edit/compile/test/commit

satellite$ git push origin ( ⁴ )

mothership$ cd frotz

mothership$ git checkout master

mothership$ git merge satellite/master ( ⁵ )

¹. машина mothership имеет репозиторий frotz в домашний каталоге; клонируем его в репозиторий на машине satellite.

². клонируем установки конфигурации переменных по умолчанию. Готовим git pull для извлечения и сохранения ветвей с машины mothership в локальные отслеживаемые ветви remotes/origin/* .

³. готовим git push для отдачи с локальной ветки master в ветку remotes/satellite/master машины mothership.

⁴. отсылаем результаты нашей работы в remotes/satellite/master отслеживаемую ветку на машине mothership. Вы можете использовать её в качестве запасного хранилища кода.

⁵. на машине mothership, объединяем наработки с машины satellite в ветку master.

Ветка вне без специфичного тега.

$ git checkout -b private2.6.14 v2.6.14 ( ¹ )

$ edit/compile/test; git commit -a

$ git checkout master

$ git format-patch -k -m --stdout v2.6.14..private2.6.14 |

git am -3 -k ( ² )

¹. создаём приватную ветку на основе на известной (но несколько сзади) метки.

². портируем вперед все изменения в ветке private2.6.14 в ветку мастер без формального «слияние».

Интегратор

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

* git-am(1) применить патчи в e-mail виде от другого участника.

* git-pull(1) объединить ветки доверенных лиц.

* git-format-patch(1) подготовить и направить альтернативные предложения участнику.

* git-revert(1) отменить неудачные коммиты.

* git-push(1) опубликовать текущие изменения.

Примеры

Мой типичный день с Git.

$ git status ( ¹ )

$ git show-branch ( ² )

$ mailx ( ³ )

& s 2 3 4 5 ./+to-apply

& s 7 8 ./+hold-linus

& q

$ git checkout -b topic/one master

$ git am -3 -i -s -u ./+to-apply ( ⁴)

$ compile/test

$ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus ( ⁵)

$ git checkout topic/one && git rebase master ( ⁶ )

$ git checkout pu && git reset --hard next ( ⁷)

$ git merge topic/one topic/two && git merge hold/linus ( ⁸ )

$ git checkout maint

$ git cherry-pick master4 ( ⁹ )

$ compile/test

$ git tag -s -m “GIT 0.99.9x” v0.99.9x ( ¹⁰ )

$ git fetch ko && git show-branch master maint 'tags/ko-*' ( ¹¹ )

$ git push ko ( ¹² )

$ git push ko v0.99.9x ( ¹³)

¹. смотрю, состояние дел 

². смотрю названия веток, и думаю о том, как из них уже готовы.

³. читаю почту, сохраняю то, что уже применимо, и что не совсем готовы.

⁴. применяю их, интерактивно, с моей подписью.

⁵. создаваю топики веток по мере необходимости и применяю, с моей подписью.

⁶. делаю git rebase для внутренней именованной ветки, которая не была объединена с мастером, и не выставлена как часть стабильной ветви.

⁷. сброс ветки pu каждый раз, из следующей.

⁸. и объединяем ветки при их готовности.

⁹. «бакпортирую» критические исправления.

¹⁰. создаю подписанный тег.

¹¹. убеждаюсь, что я случайно не откачу master назад после git push. Где ko – это сокращенная запись точек, в которое я имею на kernel.org, и выглядит подобно этому :

$ cat .git/remotes/ko

URL: kernel.org:/pub/scm/git/git.git

Pull: master:refs/tags/ko-master

Pull: next:refs/tags/ko-next

Pull: maint:refs/tags/ko-maint

Push: master

Push: next

Push: +pu

Push: maint

¹². В выводе git show-branch, master должно быть все что имеется в ko-master, и next должен всегда иметь ko-next.

¹³. публикуем изменения ка публичном сервере

¹⁴. публикуем также тег.

Администрирование репозитория

Администратор репозитория использует следующие инструменты для создания и поддержки доступа разработчиков к репозиторию.

* git-daemon(1) разрешает анонимную загрузку из репозитория.

* git-shell(1) может использоваться в качестве ограниченного логин шелла в общем центральном репозитории пользователей.

hook howto имеет хорошии примеры совместной управления центрального репозитория.

Примеры

Мы исходим из следующего содержимого /etc/services

$ grep 9418 /etc/services

git 9418/tcp # Git Version Control System

Запуск ГИТ-демона как сервиса /pub/scm из inetd.

$ grep git /etc/inetd.conf

git stream tcp nowait nobody \

/usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm

Актуальная конфигурационная строка должна помещаться в одну строку.

Запуск git-демона как сервиса /pub/scm из xinetd.

$ cat /etc/xinetd.d/git-daemon

# default: off

# description: The git server offers access to git repositories

service git

{

disable = no

type = UNLISTED

port = 9418

socket_type = stream

wait = no

user = nobody

server = /usr/bin/git-daemon

server_args = --inetd --export-all --base-path=/pub/scm

log_on_failure += USERID

}

Проверьте вашу документацию по настройкам xinetd (8), вышеописанные строки соответсуют Fedora.

В других дистрибутивах могут быть отличия. Дайте права доступа для push/pull только для разработчиков.

$ grep git /etc/passwd ( ¹ )

alice:x:1000:1000::/home/alice:/usr/bin/git-shell

bob:x:1001:1001::/home/bob:/usr/bin/git-shell

cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell

david:x:1003:1003::/home/david:/usr/bin/git-shell

$ grep git /etc/shells ( ² )

¹. Установите для входа пользователя в качестве shell /usr/bin/git-shell, который не позволяет ничего делать пользователю, кроме git push и git pull. Эти пользователи должны иметь ssh доступ к машине.

². Во многих дистрибутивах в /etc/shells нужно перечислять, какие пользователи используют при входе данный shell.

Стиль общего CVS-репозитория

$ grep git /etc/group ( ¹ )

git:x:9418:alice,bob,cindy,david

$ cd /home/devo.git

$ ls -l ( ² )

lrwxrwxrwx 1 david git 17 Dec 4 22:40 HEAD -» refs/heads/master

drwxrwsr-x 2 david git 4096 Dec 4 22:40 branches

• rw-rw-r-- 1 david git 84 Dec 4 22:40 config
• rw-rw-r-- 1 david git 58 Dec 4 22:40 description

drwxrwsr-x 2 david git 4096 Dec 4 22:40 hooks

• rw-rw-r-- 1 david git 37504 Dec 4 22:40 index

drwxrwsr-x 2 david git 4096 Dec 4 22:40 info

drwxrwsr-x 4 david git 4096 Dec 4 22:40 objects

drwxrwsr-x 4 david git 4096 Nov 7 14:58 refs

drwxrwsr-x 2 david git 4096 Dec 4 22:40 remotes

$ ls -l hooks/update (3)

• r-xr-xr-x 1 david git 3536 Dec 4 22:40 update

$ cat info/allowed-users (4)

refs/heads/master alice\|cindy

refs/heads/doc-update bob

refs/tags/v[0–9]* david

¹. разработчики должны входить в группу git.

². делаем общий репозиторий доступный для записиси членам группы.

³. используем update-hook, например, от Carl из Documentation/howto/ для ветки политики контроля.

⁴. Алиса и Синди могут делать git-push в master, однако Bob может делать push в doc-update. Давид – это релиз-менеджер и является единственным лицом, которые может создать и помещать теги в версии.

HTTP-сервер для поддержки протокола передачи.

dev$ git update-server-info ( ¹ )

dev$ ftp user@isp.example.com ( ² )

ftp» cp -r .git /home/user/myproject.git

¹. проверьте, что ваши info/refs objects/info/packsи актуальны.

². загрузите на репозиторий на публичный HTTP-сервер или сервер вашего провайдера.

Страницы, ссылающиеся на данную:

AltLinux/Sisyphus/devel/git

RuslanHihin/GitTutorial1