Spec-Zone.ru › Git

giteveryday

Имя

giteveryday — полезный минимальный набор команд для повседневной работы с Git

Синопсис

Повседневная работа с Git с 20-ю и более командами

Описание

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

  • Команды для индивидуального разработчика (Standalone) являются необходимыми для любого, кто делает коммит, даже для человека, работающего в одиночку.

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

  • Люди, выполняющие роль Интегратора, должны изучить ещё несколько команд в дополнение к вышеперечисленным.

  • Команды Администрирования репозитория предназначены для системных администраторов, ответственных за обслуживание репозиториев Git.

Индивидуальный разработчик (standalone)

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

  • git-init[1] для создания нового репозитория.

  • git-log[1] для просмотра истории.

  • git-switch[1] и git-branch[1] для переключения между ветками.

  • git-add[1] для управления индексным файлом.

  • git-diff[1] и git-status[1] для просмотра текущих изменений.

  • git-commit[1] для продвижения текущей ветки.

  • git-restore[1] для отмены изменений.

  • git-merge[1] для слияния между локальными ветками.

  • git-rebase[1] для поддержки тематических веток.

  • git-tag[1] для маркировки известных точек.

Примеры

Использовать архив tar как стартовую точку для нового репозитория. 
$ tar zxf frotz.tar.gz
$ cd frotz
$ git init
$ git add . (1)
$ git commit -m "import of frotz source tree."
$ git tag v2.43 (2)

  1. Добавить все содержимое текущей директории.

  2. Создать легкую, необъявленную метку.

Создать тематическую ветку и работать над ней. 
$ git switch -c alsa-audio (1)
$ edit/compile/test
$ git restore curses/ux_audio_oss.c (2)
$ git add curses/ux_audio_alsa.c (3)
$ edit/compile/test
$ git diff HEAD (4)
$ git commit -a -s (5)
$ edit/compile/test
$ git diff HEAD^ (6)
$ git commit -a --amend (7)
$ git switch master (8)
$ git merge alsa-audio (9)
$ git log --since='3 days ago' (10)
$ git log v2.43.. curses/ (11)

  1. Создать новую тематическую ветку.

  2. Отменить неверные изменения в curses/ux_audio_oss.c.

  3. Вы должны сообщить Git, что вы добавили новый файл; удаление и изменения будут учтены, если вы сделаете git commit -a позже.

  4. Посмотреть изменения, которые вы собираетесь зафиксировать.

  5. Зафиксировать все изменения, как вы протестировали, со своим подписанием.

  6. Посмотреть все изменения, включая предыдущий коммит.

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

  8. Переключиться на ветку master.

  9. Слить тематическую ветку в вашу ветку master.

  10. Просмотреть журнал коммитов; другие способы ограничения вывода могут быть объединены и включают -10 (для отображения до 10 коммитов), --until=2005-12-10, и т. д.

  11. Просмотреть только изменения, которые затрагивают содержимое каталога curses/, начиная с метки v2.43.

Индивидуальный разработчик (participant)

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

  • git-clone[1] из upstream для инициализации вашего локального репозитория.

  • git-pull[1] и git-fetch[1] из "origin" для синхронизации с upstream.

  • git-push[1] в общий репозиторий, если вы используете рабочую схему совместного репозитория в стиле CVS.

  • git-format-patch[1] для подготовки отправки по электронной почте, если вы используете рабочую схему публичного форума в стиле ядра Linux.

  • git-send-email[1] для отправки вашей электронной почты без искажений вашей программой чтения почты.

  • git-request-pull[1] для создания сводки изменений для вашего upstream для pull.

Примеры

Клонировать upstream и работать над ним. Передавать изменения в upstream. 
$ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6
$ cd my2.6
$ git switch -c mine master (1)
$ edit/compile/test; git commit -a -s (2)
$ git format-patch master (3)
$ git send-email --to="person <email@example.com>" 00*.patch (4)
$ git switch master (5)
$ git pull (6)
$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 (7)
$ git ls-remote --heads http://git.kernel.org/.../jgarzik/libata-dev.git (8)
$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL (9)
$ git reset --hard ORIG_HEAD (10)
$ git gc (11)

  1. Переключиться на новую ветку mine из master.

  2. Повторять по необходимости.

  3. Извлечь исправления из вашей ветки, относительно master.

  4. Отправить их по электронной почте.

  5. Вернуться к master, готовым к обзору новых изменений

  6. git pull по умолчанию забирает данные из origin и сливает их в текущую ветку.

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

  8. Проверить имена веток в внешнем репозитории (если они неизвестны).

  9. Загрузить данные из определённой ветки ALL из определённого репозитория и слить их.

  10. Отменить загрузку.

  11. Очистить ненужные объекты, оставшиеся после отменённой загрузки.

Опубликовать в другой репозиторий. 
satellite$ git clone mothership:frotz frotz (1)
satellite$ cd frotz
satellite$ git config --get-regexp '^(remote|branch)\.' (2)
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 \
           +refs/heads/*:refs/remotes/satellite/* (3)
satellite$ edit/compile/test/commit
satellite$ git push origin (4)

mothership$ cd frotz
mothership$ git switch master
mothership$ git merge satellite/master (5)

  1. Машинный сервер имеет репозиторий frotz в вашей домашней директории; клонировать его, чтобы начать репозиторий на спутниковой машине.

  2. Клонирование по умолчанию устанавливает эти переменные конфигурации. Он организует git pull для загрузки и хранения веток машины-сервера в локальные remotes/origin/* удалённые ветки отслеживания.

  3. Организовать git push для публикации всех локальных веток в соответствующие ветки машины-сервера.

  4. Опубликование сохранит все наши изменения на remotes/satellite/* удалённых ветках отслеживания на машине-сервере. Вы можете использовать это как метод резервного копирования. Аналогично, вы можете предположить, что машина-сервер "загрузил" изменения от вас (полезно, когда доступ односторонний).

  5. На машине-сервере слить работу, проведённую на спутниковой машине, в ветку master.

Отделить ветку от определённой метки. 
$ git switch -c private2.6.14 v2.6.14 (1)
$ edit/compile/test; git commit -a
$ git checkout master
$ git cherry-pick v2.6.14..private2.6.14 (2)

  1. Создать частную ветку, основанную на известной (но несколько устаревшей) метке.

  2. Переместить все изменения в ветку private2.6.14 в ветку master без формального "слияния". Или вручную
    git format-patch -k -m --stdout v2.6.14..private2.6.14 | git am -3 -k

Альтернативный механизм отправки участника использует git request-pull или механизмы pull-запросов (например, используемые на GitHub (www.github.com)) для уведомления вашего upstream о вашем вкладе.

Интегратор

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

Этот раздел также может быть использован теми, кто отвечает на git request-pull или pull-запросы на GitHub (www.github.com) для интеграции работы других в свою историю. Заместитель по подзонам репозитория будет выполнять функции как участника, так и интегратора.

  • git-am[1] для применения исправляющих электронных писем от ваших соавторов.

  • git-pull[1] для слияния с ваших надёжных подчиненных.

  • git-format-patch[1] для подготовки и отправки предложенных альтернатив соавторам.

  • git-revert[1] для отмены испорченных коммитов.

  • git-push[1] для публикации актуальной версии.

Примеры

Типичный день интегратора с Git. 
$ git status (1)
$ git branch --no-merged master (2)
$ mailx (3)
& s 2 3 4 5 ./+to-apply
& s 7 8 ./+hold-linus
& q
$ git switch -c topic/one master
$ git am -3 -i -s ./+to-apply (4)
$ compile/test
$ git switch -c hold/linus && git am -3 -i -s ./+hold-linus (5)
$ git switch topic/one && git rebase master (6)
$ git switch -C seen next (7)
$ git merge topic/one topic/two && git merge hold/linus (8)
$ git switch maint
$ git cherry-pick master~4 (9)
$ compile/test
$ git tag -s -m "GIT 0.99.9x" v0.99.9x (10)
$ git fetch ko && for branch in master maint next seen (11)
    do
        git show-branch ko/$branch $branch (12)
    done
$ git push --follow-tags ko (13)

  1. Посмотреть, чем вы занимались, если что-то было.

  2. Посмотреть, какие ветки ещё не слиты в master. Аналогично для других ветвей интеграции, например, maint, next и seen.

  3. Прочитать письма, сохранить применимые и сохранить другие, которые пока не готовы (доступны другие программы чтения почты).

  4. Применить их интерактивно со своими подписями.

  5. Создать тематическую ветку по мере необходимости и применить, опять же со своими подписями.

  6. Перестроить внутреннюю тематическую ветку, которая не была слита с веткой master или представлена как часть стабильной ветки.

  7. Перезапустить seen каждый раз с последующего.

  8. И собрать тематические ветки, которые ещё готовятся.

  9. Перезагрузить критически важную исправление.

  10. Создать подписанную метку.

  11. Убедиться, что master не был случайно отменён за пределы уже опубликованного.

  12. В выводе от git show-branch, master должно содержать всё, что ko/master имеет, и next должно содержать всё, что ko/next имеет, и т.д.

  13. Опубликовать актуальную версию вместе с новыми метками, указывающими на опубликованную историю.

В этом примере, сокращение ko указывает на репозиторий основного разработчика Git на kernel.org и выглядит так:

(in .git/config)
[remote "ko"]
        url = kernel.org:/pub/scm/git/git.git
        fetch = refs/heads/*:refs/remotes/ko/*
        push = refs/heads/master
        push = refs/heads/next
        push = +refs/heads/seen
        push = refs/heads/maint

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

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

  • git-daemon[1] для разрешения анонимного скачивания из репозитория.

  • git-shell[1] может использоваться в качестве restricted login shell для пользователей общего центрального репозитория.

  • git-http-backend[1] предоставляет реализацию серверной части Git-over-HTTP ("Smart http"), позволяя предоставлять как службы fetch, так и службы push.

  • gitweb[1] предоставляет веб-фронтенд для Git-репозиториев, который может быть настроен с помощью скрипта git-instaweb[1].

пример управления хуком обновления содержит хороший пример управления общим центральным репозиторием.

Кроме того, существует ряд других широко используемых решений для хостинга, просмотра и рецензирования, таких как:

  • gitolite, gerrit для рецензирования кода, cgit и другие.

Примеры

Мы предполагаем следующее в /etc/services 
$ grep 9418 /etc/services
git                9418/tcp                # Git Version Control System
Запустить git-daemon для обслуживания /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-daemon для обслуживания /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 разработчикам, использующим git-over-ssh.

Например, тем, кто использует: $ git push/pull ssh://host.xz/pub/scm/project

$ grep git /etc/passwd (1)
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 (2)
/usr/bin/git-shell

  1. оболочка входа установлена на /usr/bin/git-shell, что не позволяет ничего, кроме git push и git pull. Пользователи требуют доступ по ssh к машине.

  2. во многих дистрибутивах /etc/shells необходимо перечислить используемые оболочки входа.

Репозиторий общего доступа в стиле CVS. 
$ grep git /etc/group (1)
git:x:9418:alice,bob,cindy,david
$ cd /home/devo.git
$ ls -l (2)
  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

  1. разместите разработчиков в одной группе git.

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

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

  4. alice и cindy могут отправлять в мастер, только bob может отправлять в doc-update. david - менеджер релизов и только он может создавать и отправлять теги версий.

giteveryday

© 2005–2026 Linus Torvalds and others
Licensed under the GNU General Public License version 2.
https://git-scm.com/docs/giteveryday

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API