Команды работы с [Базисные команды репозитория] нужны всем, у кого есть репозиторий, т.е. любому, работающему с git хранилищем.
Кроме того, важное значение для всех, кто создаёт коммиты, даже если он работает один, важное значение имеют комады [Индивидуальная разработка (Автономный режим)] .
Если вы работаете совместно с другими людьми, вам потребуются команды, перечисленные в разделе [Индивидуальная разработка (Совместный режим)].
Людям, которые играют роль [Интегратора], необходимо знать помимо этого ещё несколько команд..
Команды [Администрирование репозитория] важны для системных администраторов которые несут ответственность за работоспособность git репозиториия.
Базисные команды репозитория
Эти команды повседневно используются при работе с 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 (1)
$ git count-objects (2)
$ git gc (3)
1. Даже запуская без --full, вы легко и надёжно проверяете «здоровье» репозитория.
2. Проверка, сколько объектов будет потеряно и объём освобождаемого места при перепаковке репозитория.
3. переупаковка локальных репозиториев и другие виды повседневныз задач.
Упаковка небольших проектов в один пакет.
$ git gc (1)
1. паковать все объекты доступные из «ссылок» в одну упаковку, затем удалить другие упаковки.
Индивидуальная разработка (Автономный режим)
Автономный индивидуальный разработчик не обменивается патчами с другими людьми, а работает только в одном репозитории, используя
следующие команды.
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. машина 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. forward port all changes in private2.6.14 branch to master branch without a formal “merging”.
3. портируем вперед все изменения в private2.6.14 ветке в ветку мастер без формального «слияние».
Интегратор
Довольно часто
центральное лицо, выступающая в качестве интегратора проекта группы,
получает изменения от других участников изучает их интегрирует их, а потом
публикует результаты для использования другими. Ему нужны команды, для организации совместной работы.
git-am(1) применить патчи в e-mail виде от другого участника.
git-pull(1) объединить ветки доверенных лиц.
git-format-patch(1) подготовить и направить альтернативные предложения участнику.
git-revert(1) отменить неудачные коммиты.
git-push(1) опубликовать текущие изменения.
Примеры
Мой типичный день с Git.
$ git status (1)
$ git show-branch (2)
$ mailx (3)
& 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 (4)
$ compile/test
$ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus (5)
$ git checkout topic/one && git rebase master (6)
$ git checkout pu && git reset --hard next (7)
$ git merge topic/one topic/two && git merge hold/linus (8)
$ git checkout maint
$ git cherry-pick master4 (9)
$ compile/test
$ git tag -s -m “GIT 0.99.9x” v0.99.9x (10)
$ git fetch ko && git show-branch master maint 'tags/ko-*' (11)
$ git push ko (12)
$ git push ko v0.99.9x (13)
смотрю, состояние дел
смотрю названия веток, и думаю о том, как из них уже готовы.
читаю почту, сохраняю то, что уже применимо, и что не совсем готовы.
применяю их, интерактивно, с моей подписью.
создаваю топики веток по мере необходимости и применяю, с моей подписью.
делаю git rebase для внутренней именованной ветки, которая не была объединена с мастером, и не выставлена как часть стабильной ветви.
сброс ветки pu каждый раз, из следующей.
и объединяем ветки при их готовности.
«бакпортирую» критические исправления.
создаю подписанный тег.
убеждаюсь, что я случайно не откачу master назад после git push. Где ko – это сокращенная запись точек, в которое я имею на kernel.org, и выглядит подобно этому :
В выводе git show-branch, master должно быть все что имеется в ko-master, и next должен всегда иметь ko-next.
публикуем изменения ка публичном сервере
публикуем также тег.
Администрирование репозитория
A repository administrator uses the following tools to set up and maintain access to the repository by developers.
Администратор репозитория использует следующие инструменты для создания и поддержки доступа разработчиков к репозиторию.
* git-daemon(1) разрешает анонимную загрузку из репозитория.
* git-shell(1) can be used as a restricted login shell for shared central repository users.
* git-shell(1) может использоваться в качестве ограниченного авторизированного sheel`а в общем центральном репозитории пользователей.
update 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
}
Check your xinetd(8) documentation and setup, this is from a Fedora system.
Проверьте вашу документацию по xinetd (8) настройки, вышеописанные строки соответсуют Fedora.
В других дистрибутивах могут быть отличия. Give push/pull only access to developers.
Дайте права доступа для push/pull только для разработчиков.
1. log-in shell is set to /usr/bin/git-shell, which does not allow anything but git push and git pull .
2. Установите для входа пользователя в качестве shell /usr/bin/git-shell, которывй не позволяет ничего делать пользователю, кроме git push и git pull. Эти пользователи должны иметь ssh доступ к машине.
3. in many distributions /etc/shells needs to list what is used as the login shell.
4. Во многих дистрибутивах в /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
разработчики должны входить в группу git.
делаем общий репозиторий доступный для записиси членам группы.
используем update-hook, например, от Carl из Documentation/howto/ для ветки политики контроля.
alice and cindy can push into master, only bob can push into doc-update. Алиса и Синди могут делать git-push в master, однако Bob может делать push в doc-update. Давид – это релиз-менеджер и является единственным лицом, которые может создать и помещать теги в версии.
HTTP-сервер для поддержки протокола передачи.
dev$ git update-server-info (1)
dev$ ftp user@isp.example.com (2)
ftp» cp -r .git /home/user/myproject.git
1. проверьте, что ваши info/refs objects/info/packsи актуальны.
2. upload to public HTTP server hosted by your ISP.
3. загрузите на публичный HTTP-сервер или сервер вашего провайдера.