Команды работы с [Базисные команды репозитория] нужны всем, у кого есть репозиторий, т.е. любому, работающему с 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) решает общие задачи сохранения репозитория, такие как переупаковки и «убирание мусора».
Примеры
Проверка «здоровья» репозитория и удаление из него мусора.
( 1 ) Даже запуская без --full, вы легко и надёжно проверяете «здоровье» репозитория.
( 2 ) Проверка, сколько объектов будет потеряно и объём освобождаемого места при перепаковке репозитория.
( 3 ) переупаковка локальных репозиториев и другие виды повседневныз задач.
( 1 ) . паковать все объекты доступные из «ссылок» (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 . ( 1 )
$ git commit -m “import of frotz source tree.”
$ git tag v2.43 ( 2 )
( 1 ) Добавляем все измениия и файлы в текущем директории.
( 2 ) Создаём легкий, неаннотированный тег
1. создаем новую ветку с именем (топиком) alsa-audio. 2. отменяем ваши неудачные изменения в curses/ux_audio_oss.c 3. вам нужно указать git, что вы добавили новый файл; другие удаление и изменения будет не замечены, если сделать git commit. 4. смотрим, какие изменения Вы будете фиксировать при выполнении git-commit. 5. фиксируем всё так-вы проверили, подписывая коммит. 6. отменяем последний коммит, сохраняя его в рабочем дереве. 7. смотрим на изменения сделанные в отменённом нами коммите. 8. возвращаем предыдущий коммит используя при записи сообщение оригинала. 9. переключиться на ветвь master. 10. объединяем ветку топика alsa-audio с веткой master. 11. смотрим логи коммита; другие формы могут ограничивать вывод и комбинироваться и включать
--max-count=10 (показать не больше 10 коммитов),
--until=2005–12–10 (до 10 декабря 2005г) и т.д. 12. смотрим изменения, находящиеся в директории 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».
Примеры
Клонируем основной репозиторий и работаем с ним. Передаём изменения в основной репозиторий.
1. повторяем по мере необходимости. 2. извлекаем патчи из вашей ветки в e-mail виде. 3. git pull извлекает из origin (по-умолчанию) и объединяет с текущей веткой. 4. сразу после git pull, смотрим сделанные «апстримом» в последнее время изменения в области кода, которая нас интересует. 5. извлекаем изменения из конкретной ветки конкретного репозитория и объединяем их. 6. возвращаемся через git pull . 7. убираем мусор от оставшихся объектов после git-pull. 8. Время от времени, получать официальные метки из origin и сохраняем их в соответствии в .git/refs/tags/.
1. машина mothership имеет репозиторий frotz в домашний каталоге; клонируем его в репозиторий на машине satellite. 2. клонируем установки конфигурации переменных по умолчанию. Готовим git pull для извлечения и сохранения ветвей с машины mothership в локальные отслеживаемые ветви remotes/origin/* . 3. готовим git push для отдачи с локальной ветки master в ветку remotes/satellite/master машины mothership. 4. отсылаем результаты нашей работы в remotes/satellite/master отслеживаемую ветку на машине mothership. Вы можете использовать её в качестве запасного хранилища кода. 5. на машине mothership, объединяем наработки с машины satellite в ветку master.
1. создаём приватную ветку на основе на известной (но несколько сзади) метки. 2. портируем вперед все изменения в ветке private2.6.14 в ветку мастер без формального «слияние».
Интегратор
Довольно часто центральное лицо, выступающая в качестве интегратора проекта группы, получает изменения от других участников изучает их интегрирует их, а потом публикует результаты для использования другими. Ему нужны команды, для организации совместной работы.
* git-am(1) применить патчи в e-mail виде от другого участника.
* git-pull(1) объединить ветки доверенных лиц.
* git-format-patch(1) подготовить и направить альтернативные предложения участнику.
* git-revert(1) отменить неудачные коммиты.
* git-push(1) опубликовать текущие изменения.
1. смотрю, состояние дел 2. смотрю названия веток, и думаю о том, как из них уже готовы. 3. читаю почту, сохраняю то, что уже применимо, и что не совсем готовы. 4. применяю их, интерактивно, с моей подписью. 5. создаваю топики веток по мере необходимости и применяю, с моей подписью. 6. делаю git rebase для внутренней именованной ветки, которая не была объединена с мастером, и не выставлена как часть стабильной ветви. 7. сброс ветки pu каждый раз, из следующей. 8. и объединяем ветки при их готовности. 9. «бакпортирую» критические исправления. 10. создаю подписанный тег. 11. убеждаюсь, что я случайно не откачу master назад после git push. Где ko – это сокращенная запись точек, в которое я имею на kernel.org, и выглядит подобно этому :
12. В выводе git show-branch, master должно быть все что имеется в ko-master, и next должен всегда иметь ko-next. 13. публикуем изменения ка публичном сервере 14. публикуем также тег.
Администрирование репозитория
Администратор репозитория использует следующие инструменты для создания и поддержки доступа разработчиков к репозиторию.
* git-daemon(1) разрешает анонимную загрузку из репозитория.
* git-shell(1) может использоваться в качестве ограниченного логин шелла в общем центральном репозитории пользователей.
hook howto имеет хорошии примеры совместной управления центрального репозитория.
Примеры
Мы исходим из следующего содержимого /etc/services
$ grep 9418 /etc/services
git 9418/tcp # Git Version Control System
Актуальная конфигурационная строка должна помещаться в одну строку.
Запуск 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 только для разработчиков.
1. Установите для входа пользователя в качестве shell /usr/bin/git-shell, который не позволяет ничего делать пользователю, кроме git push и git pull. Эти пользователи должны иметь ssh доступ к машине. 2. Во многих дистрибутивах в /etc/shells нужно перечислять, какие пользователи используют при входе данный shell.
Стиль общего 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, например, от Carl из Documentation/howto/ для ветки политики контроля. 4. Алиса и Синди могут делать git-push в master, однако Bob может делать push в doc-update. Давид – это релиз-менеджер и является единственным лицом, которые может создать и помещать теги в версии.