руководство пользователя

Как получить репозиторий Git

При чтении этого руководства вам пригодится репозиторий Git для экспериментов.

Лучше всего получить его с помощью команды git-clone[1], загрузив копию существующего репозитория. Если вы ещё не выбрали проект, вот несколько интересных примеров:

        # Git itself (approx. 40MB download):
$ git clone git://git.kernel.org/pub/scm/git/git.git
        # the Linux kernel (approx. 640MB download):
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

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

Команда clone создаёт новый каталог с именем проекта (git или linux в приведённых выше примерах). Перейдя в этот каталог с помощью cd, вы увидите копию файлов проекта, называемую рабочим деревом, а также специальный каталог верхнего уровня с именем .git, в котором содержится вся информация об истории проекта.

Как переключиться на другую версию проекта

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

Эти снимки не обязательно выстроены в одну линию от самого старого к самому новому: разработка может одновременно идти по нескольким параллельным линиям, называемым ветками, которые могут сливаться и расходиться.

Один репозиторий Git может отслеживать разработку в нескольких ветках. Для этого он хранит список указателей HEAD, ссылающихся на последний коммит каждой ветки. Команда git-branch[1] показывает список указателей на вершины веток:

$ git branch
* master

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

В большинстве проектов также используются теги. Как и указатели HEAD, теги являются ссылками на историю проекта. Их список можно вывести командой git-tag[1]:

$ git tag -l
v2.6.11
v2.6.11-tree
v2.6.12
v2.6.12-rc2
v2.6.12-rc3
v2.6.12-rc4
v2.6.12-rc5
v2.6.12-rc6
v2.6.13
...

Предполагается, что теги всегда указывают на одну и ту же версию проекта, а указатели HEAD перемещаются вперёд по мере развития проекта.

Создайте новый указатель на вершину ветки, ссылающийся на одну из этих версий, и переключитесь на неё с помощью git-switch[1]:

$ git switch -c new v2.6.13

После этого рабочий каталог будет содержать файлы проекта в том состоянии, в котором они находились при создании тега v2.6.13. Команда git-branch[1] покажет две ветки; звёздочкой будет отмечена текущая ветка:

$ git branch
  master
* new

Если вы решите, что предпочли бы увидеть версию 2.6.17, можно переместить текущую ветку на v2.6.17 с помощью команды

$ git reset --hard v2.6.17

Обратите внимание: если указатель текущей ветки был единственной ссылкой на определённую точку истории, сброс ветки может лишить вас возможности найти историю, на которую она раньше указывала. Поэтому используйте эту команду осторожно.

Как понимать историю: коммиты

Каждое изменение в истории проекта представлено коммитом. Команда git-show[1] показывает последний коммит текущей ветки:

$ git show
commit 17cf781661e6d38f737f15f53ab552f1e95960d7
Author: Linus Torvalds <torvalds@ppc970.osdl.org.(none)>
Date:   Tue Apr 19 14:11:06 2005 -0700

    Remove duplicate getenv(DB_ENVIRONMENT) call

    Noted by Tony Luck.

diff --git a/init-db.c b/init-db.c
index 65898fa..b002dc6 100644
--- a/init-db.c
+++ b/init-db.c
@@ -7,7 +7,7 @@

 int main(int argc, char **argv)
 {
-        char *sha1_dir = getenv(DB_ENVIRONMENT), *path;
+        char *sha1_dir, *path;
         int len, i;

         if (mkdir(".git", 0755) < 0) {

Как видите, в коммите указано, кто внёс последнее изменение, что именно было сделано и почему.

У каждого коммита есть 40-значный шестнадцатеричный идентификатор, иногда называемый «именем объекта» или «идентификатором SHA-1». Он отображается в первой строке вывода git show. Обычно на коммит можно ссылаться по короткому имени, например по имени тега или ветки, но это длинное имя тоже может быть полезно. И главное: это глобально уникальное имя коммита. Поэтому, если вы сообщите кому-нибудь имя объекта (например, по электронной почте), можно быть уверенным, что в репозитории этого человека оно будет обозначать тот же коммит, что и в вашем (при условии, что этот коммит вообще есть в его репозитории). Поскольку имя объекта вычисляется как хеш содержимого коммита, коммит не может измениться, не изменив при этом своего имени.

В разделе Понятия Git мы увидим, что всё, хранящееся в истории Git, включая данные файлов и содержимое каталогов, сохраняется в объекте, имя которого является хешем его содержимого.

         o--o--o <-- Branch A
        /
 o--o--o <-- master
        \
         o--o--o <-- Branch B

Работа с ветками

Создавать, удалять и изменять ветки быстро и просто. Вот краткое описание команд:

Специальный символ "HEAD" всегда можно использовать для обозначения текущей ветки. Фактически Git запоминает текущую ветку в файле с именем HEAD в каталоге .git:

$ cat .git/HEAD
ref: refs/heads/master

Просмотр старой версии без создания новой ветки

Команда git switch обычно ожидает указатель на вершину ветки, но при вызове с параметром --detach принимает и произвольный коммит. Например, можно переключиться на коммит, на который ссылается тег:

$ git switch --detach v2.6.17
Note: checking out 'v2.6.17'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another switch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command again. Example:

  git switch -c new_branch_name

HEAD is now at 427abfa Linux v2.6.17

После этого HEAD будет указывать на SHA-1 коммита, а не на ветку, и команда git branch покажет, что вы больше не находитесь в ветке:

$ cat .git/HEAD
427abfa28afedffadfca9dd8b067eb6d36bac53f
$ git branch
* (detached from v2.6.17)
  master

В этом случае говорят, что HEAD «отсоединён».

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

Просмотр веток удалённого репозитория

Ветка "master", созданная во время клонирования, является копией HEAD репозитория, из которого вы клонировали проект. В этом репозитории могли быть и другие ветки, и локальный репозиторий хранит ветки, отслеживающие каждую из них. Они называются удалёнными отслеживаемыми ветками; их можно просмотреть с помощью параметра -r команды git-branch[1]:

$ git branch -r
  origin/HEAD
  origin/html
  origin/maint
  origin/man
  origin/master
  origin/next
  origin/seen
  origin/todo

В этом примере "origin" называется удалённым репозиторием или, сокращённо, «удалённым репозиторием». С нашей точки зрения, ветки этого репозитория называются «удалёнными ветками». Перечисленные выше удалённые отслеживаемые ветки были созданы на основе удалённых веток во время клонирования и будут обновляться командами git fetch (отсюда git pull) и git push. Подробнее см. в разделе Обновление репозитория с помощью git fetch.

Можно начать разработку на основе одной из этих удалённых отслеживаемых веток, создав собственную ветку, как и в случае с тегом:

$ git switch -c my-todo-copy origin/todo

Можно также переключиться непосредственно на origin/todo, чтобы изучить её или создать разовое исправление. См. раздел Отсоединённый HEAD.

Обратите внимание: имя "origin" — это просто имя, которое Git по умолчанию использует для ссылки на репозиторий, из которого вы клонировали проект.

Имена веток, тегов и других ссылок

Ветки, удалённые отслеживаемые ветки и теги — всё это ссылки на коммиты. Всем ссылкам присваиваются имена в виде путей, разделённых косыми чертами и начинающихся с refs. Имена, которые мы использовали до сих пор, являются сокращёнными вариантами:

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

(Новые ссылки фактически хранятся в каталоге .git/refs по пути, соответствующему их имени. Однако для повышения эффективности они могут быть упакованы в один файл; см. git-pack-refs[1].)

Ещё одно удобное сокращение: на HEAD репозитория можно ссылаться, просто используя имя этого репозитория. Так, например, "origin" обычно является сокращённым обозначением ветки HEAD в репозитории "origin".

Полный список путей, по которым Git ищет ссылки, и порядок выбора при наличии нескольких ссылок с одинаковым сокращённым именем приведены в разделе "SPECIFYING REVISIONS" документации gitrevisions[7].

Обновление репозитория с помощью git fetch

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

Команда git-fetch без аргументов обновит все удалённые отслеживаемые ветки до последних версий, найденных в исходном репозитории. Она не затронет ваши собственные ветки — даже ветку "master", созданную при клонировании.

Получение веток из других репозиториев

С помощью git-remote[1] можно отслеживать ветки и из других репозиториев, а не только из того, откуда вы клонировали проект:

$ git remote add staging git://git.kernel.org/.../gregkh/staging.git
$ git fetch staging
...
From git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
 * [new branch]      master     -> staging/master
 * [new branch]      staging-linus -> staging/staging-linus
 * [new branch]      staging-next -> staging/staging-next

Новые удалённые отслеживаемые ветки будут сохранены под сокращённым именем, заданным в команде git remote add. В данном случае это staging:

$ git branch -r
  origin/HEAD -> origin/master
  origin/master
  staging/master
  staging/staging-linus
  staging/staging-next

При последующем запуске команды git fetch <remote> будут обновлены удалённые отслеживаемые ветки указанного <remote>.

Если просмотреть файл .git/config, вы увидите, что Git добавил новый раздел:

$ cat .git/config
...
[remote "staging"]
        url = git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
        fetch = +refs/heads/*:refs/remotes/staging/*
...

Именно это позволяет Git отслеживать ветки удалённого репозитория. Эти параметры конфигурации можно изменить или удалить, отредактировав файл .git/config в текстовом редакторе. (Подробности см. в разделе "CONFIGURATION FILE" документации git-config[1].)

Как использовать bisect для поиска регрессии

Предположим, что версия 2.6.18 вашего проекта работала, а версия из ветки «master» аварийно завершается. Иногда лучший способ найти причину такой регрессии — методом полного перебора просмотреть историю проекта и найти конкретный коммит, вызвавший проблему. Команда git-bisect[1] поможет это сделать:

$ git bisect start
$ git bisect good v2.6.18
$ git bisect bad master
Bisecting: 3537 revisions left to test after this
[65934a9a028b88e83e2b0f8b36618fe503349f8e] BLOCK: Make USB storage depend on SCSI rather than selecting it [try #6]

Если на этом этапе выполнить git branch, вы увидите, что Git временно переключил вас в состояние «(no branch)». HEAD теперь не привязан ни к одной ветке и указывает непосредственно на коммит (с идентификатором 65934), который доступен из «master», но не из v2.6.18. Соберите и протестируйте его и проверьте, происходит ли аварийное завершение. Предположим, что происходит. Тогда выполните:

$ git bisect bad
Bisecting: 1769 revisions left to test after this
[7eff82c8b1511017ae605f0c99ac275a7e21b867] i2c-core: Drop useless bitmaskings

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

Примерно после 13 проверок (в данном случае) будет выведен идентификатор коммита, вызвавшего проблему. Затем вы можете изучить коммит с помощью git-show[1], выяснить, кто его написал, и отправить этому человеку сообщение об ошибке с идентификатором коммита. Наконец, выполните

$ git bisect reset

чтобы вернуться в ветку, в которой вы находились ранее.

Обратите внимание, что версия, на которую git bisect переключает вас на каждом этапе, — это лишь рекомендация, и вы можете попробовать другую версию, если считаете это целесообразным. Например, иногда можно попасть на коммит, который нарушил что-то не связанное с проблемой; выполните

$ git bisect visualize

Эта команда запустит gitk и пометит выбранный коммит маркером «bisect». Выберите поблизости коммит, который кажется безопасным, запишите его идентификатор и переключитесь на него с помощью:

$ git reset --hard fb47ddb2db

Затем выполните проверку, запустите bisect good или bisect bad, в зависимости от ситуации, и продолжайте.

Вместо того чтобы выполнять git bisect visualize, а затем git reset --hard fb47ddb2db, можно просто сообщить Git, что текущий коммит нужно пропустить:

$ git bisect skip

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

Если у вас есть тестовый скрипт, который может определить, является ли коммит хорошим или плохим, процесс bisect также можно автоматизировать. Дополнительные сведения об этом и других возможностях git bisect см. в git-bisect[1].

Именование коммитов

Мы уже рассмотрели несколько способов именования коммитов:

Существуют и другие способы; полный список способов именования ревизий см. в разделе «SPECIFYING REVISIONS» справочной страницы gitrevisions[7]. Вот несколько примеров:

$ git show fb47ddb2 # the first few characters of the object name
                    # are usually enough to specify it uniquely
$ git show HEAD^    # the parent of the HEAD commit
$ git show HEAD^^   # the grandparent
$ git show HEAD~4   # the great-great-grandparent

Помните, что у коммитов слияния может быть несколько родителей; по умолчанию ^ и ~ следуют за первым указанным в коммите родителем, но можно выбрать и другого:

$ git show HEAD^1   # show the first parent of HEAD
$ git show HEAD^2   # show the second parent of HEAD

Помимо HEAD, существуют и другие специальные имена коммитов:

Слияния (о них мы поговорим позже), а также такие операции, как git reset, которые меняют текущий выбранный коммит, обычно устанавливают ORIG_HEAD в значение HEAD до выполнения текущей операции.

Операция git fetch всегда сохраняет вершину последней полученной ветки в FETCH_HEAD. Например, если выполнить git fetch, не указав локальную ветку в качестве цели операции,

$ git fetch git://example.com/proj.git theirbranch

полученные коммиты всё равно будут доступны через FETCH_HEAD.

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

Команда git-rev-parse[1] — низкоуровневая команда, которая иногда бывает полезна для преобразования имени коммита в имя объекта этого коммита:

$ git rev-parse origin
e05db0fd4f31dde7005f075a84f96b360d05984b

Создание тегов

Можно также создать тег, ссылающийся на конкретный коммит; после выполнения

$ git tag stable-1 1b2e1d63ff

можно использовать stable-1, чтобы сослаться на коммит 1b2e1d63ff.

Так создаётся «лёгкий» тег. Если вы хотите добавить к тегу комментарий и, возможно, подписать его криптографической подписью, создайте вместо этого объект тега; подробности см. на справочной странице git-tag[1].

Просмотр ревизий

Команда git-log[1] может выводить списки коммитов. Без дополнительных аргументов она показывает все коммиты, доступные из родительского коммита; однако можно задавать и более конкретные запросы:

$ git log v2.5..        # commits since (not reachable from) v2.5
$ git log test..master        # commits reachable from master but not test
$ git log master..test        # ...reachable from test but not master
$ git log master...test        # ...reachable from either test or master,
                        #    but not both
$ git log --since="2 weeks ago" # commits from the last 2 weeks
$ git log Makefile      # commits which modify Makefile
$ git log fs/                # ... which modify any file under fs/
$ git log -S'foo()'        # commits which add or remove any file data
                        # matching the string 'foo()'

Разумеется, все эти параметры можно комбинировать; следующая команда находит коммиты после v2.5, затрагивающие Makefile или любой файл в fs:

$ git log v2.5.. Makefile fs/

Можно также попросить git log показывать исправления:

$ git log -p

Дополнительные параметры отображения см. в описании параметра --pretty на справочной странице git-log[1].

Обратите внимание, что git log начинает с самого последнего коммита и движется назад по родителям; однако, поскольку история Git может содержать несколько независимых линий разработки, конкретный порядок вывода коммитов может быть в некоторой степени произвольным.

Создание различий

С помощью git-diff[1] можно создать различия между любыми двумя версиями:

$ git diff master..test

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

$ git diff master...test

Иногда вместо этого требуется набор исправлений; для этого можно использовать git-format-patch[1]:

$ git format-patch master..test

Команда создаст файл исправления для каждого коммита, доступного из test, но не из master.

Просмотр старых версий файлов

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

$ git show v2.5:fs/locks.c

Перед двоеточием может быть любое имя коммита, а после него — любой путь к файлу, отслеживаемому Git.

Примеры

$ git log --pretty=oneline origin..mybranch | wc -l

$ git rev-list origin..mybranch | wc -l

$ git diff origin..master

$ git rev-list origin
e05db0fd4f31dde7005f075a84f96b360d05984b
$ git rev-list master
e05db0fd4f31dde7005f075a84f96b360d05984b

$ git log origin...master

$ gitk e05db0fd..

$ git name-rev --tags e05db0fd
e05db0fd tags/v1.5.0-rc1^0~23

$ git describe e05db0fd
v1.5.0-rc0-260-ge05db0f

$ git merge-base e05db0fd v1.5.0-rc1
e05db0fd4f31dde7005f075a84f96b360d05984b

$ git log v1.5.0-rc1..e05db0fd

$ git show-branch e05db0fd v1.5.0-rc0 v1.5.0-rc1 v1.5.0-rc2
! [e05db0fd] Fix warnings in sha1_file.c - use C99 printf format if
available
 ! [v1.5.0-rc0] GIT v1.5.0 preview
  ! [v1.5.0-rc1] GIT v1.5.0-rc1
   ! [v1.5.0-rc2] GIT v1.5.0-rc2
...

+ ++ [e05db0fd] Fix warnings in sha1_file.c - use C99 printf format if
available

$ git show-ref --heads
bf62196b5e363d73353a9dcf094c59595f3153b7 refs/heads/core-tutorial
db768d5504c1bb46f63ee9d6e1772bd047e05bf9 refs/heads/maint
a07157ac624b2524a059a3414e99f6f44bebc1e7 refs/heads/master
24dbc180ea14dc1aebe09f14c8ecf32010690627 refs/heads/tutorial-2
1e87486ae06626c2f31eaa63d26fc0fd646c8af2 refs/heads/tutorial-fixes

$ git show-ref --heads | cut -d' ' -f2 | grep -v '^refs/heads/master'
refs/heads/core-tutorial
refs/heads/maint
refs/heads/tutorial-2
refs/heads/tutorial-fixes

$ gitk master --not $( git show-ref --heads | cut -d' ' -f2 |
                                grep -v '^refs/heads/master' )

$ gitk $( git show-ref --heads ) --not  $( git show-ref --tags )

$ git archive -o latest.tar.gz --prefix=project/ HEAD

$ git archive --format=tar --prefix=project/ HEAD | gzip >latest.tar.gz

$ release-script 2.6.12 2.6.13-rc6 2.6.13-rc7

#!/bin/sh
stable="$1"
last="$2"
new="$3"
echo "# git tag v$new"
echo "git archive --prefix=linux-$new/ v$new | gzip -9 > ../linux-$new.tar.gz"
echo "git diff v$stable v$new | gzip -9 > ../patch-$new.gz"
echo "git log --no-merges v$new ^v$last > ../ChangeLog-$new"
echo "git shortlog --no-merges v$new ^v$last > ../ShortLog"
echo "git diff --stat --summary -M v$last v$new > ../diffstat-$new"

$  git log --raw --abbrev=40 --pretty=oneline |
        grep -B 1 `git hash-object filename`

Как сообщить Git ваше имя

Прежде чем создавать коммиты, представьтесь Git. Проще всего сделать это с помощью git-config[1]:

$ git config --global user.name 'Your Name Comes Here'
$ git config --global user.email 'you@yourdomain.example.com'

Эта команда добавит в файл с именем .gitconfig в вашем домашнем каталоге следующее:

[user]
        name = Your Name Comes Here
        email = you@yourdomain.example.com

Подробные сведения о файле конфигурации см. в разделе «ФАЙЛ КОНФИГУРАЦИИ» справки git-config[1]. Это обычный текстовый файл, поэтому его также можно редактировать в любом удобном вам редакторе.

Создание нового репозитория

Создать новый репозиторий с нуля очень просто:

$ mkdir project
$ cd project
$ git init

Если у вас уже есть исходное содержимое (например, tar-архив):

$ tar xzvf project.tar.gz
$ cd project
$ git init
$ git add . # include everything below ./ in the first commit:
$ git commit

Как создать коммит

Создание нового коммита состоит из трёх шагов:

На практике шаги 1 и 2 можно чередовать и повторять сколько угодно раз: чтобы отслеживать изменения, которые вы хотите включить в коммит на шаге 3, Git хранит снимок содержимого дерева в специальной области подготовки, называемой «индексом».

Изначально содержимое индекса совпадает с содержимым HEAD. Поэтому команда git diff --cached, показывающая разницу между HEAD и индексом, на этом этапе не должна ничего выводить.

Изменить индекс просто:

Чтобы обновить индекс содержимым нового или изменённого файла, используйте

$ git add path/to/file

Чтобы удалить файл из индекса и рабочего дерева, используйте

$ git rm path/to/file

После каждого шага можно убедиться, что

$ git diff --cached

всегда показывает разницу между HEAD и файлом индекса — именно эти изменения попадут в коммит, если создать его сейчас, — а

$ git diff

показывает разницу между рабочим деревом и файлом индекса.

Обратите внимание: git add добавляет в индекс только текущее содержимое файла; дальнейшие изменения того же файла будут проигнорированы, если снова не выполнить для него git add.

Когда будете готовы, просто выполните

$ git commit

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

$ git show

В качестве специального сокращённого варианта

$ git commit -a

обновит индекс всеми изменёнными или удалёнными файлами и создаст коммит — всё за один шаг.

Для отслеживания того, что вы собираетесь включить в коммит, полезны несколько команд:

$ git diff --cached # difference between HEAD and the index; what
                    # would be committed if you ran "commit" now.
$ git diff            # difference between the index file and your
                    # working directory; changes that would not
                    # be included if you ran "commit" now.
$ git diff HEAD            # difference between HEAD and working tree; what
                    # would be committed if you ran "commit -a" now.
$ git status            # a brief per-file summary of the above.

Для создания коммитов, просмотра изменений в индексе и файлах рабочего дерева, а также выбора отдельных блоков diff для включения в индекс можно воспользоваться и git-gui[1] (щелкните правой кнопкой мыши по блоку diff и выберите «Добавить блок в индекс для коммита»).

Как составлять хорошие сообщения коммитов

Хотя это и не обязательно, рекомендуется начинать сообщение коммита с одной короткой строки (не более 50 символов), в которой кратко описываются изменения, затем оставлять пустую строку и приводить более подробное описание. Текст до первой пустой строки в сообщении коммита считается его заголовком, и этот заголовок используется во всём Git. Например, git-format-patch[1] преобразует коммит в электронное письмо: заголовок используется в строке темы, а остальная часть коммита — в теле письма.

Игнорирование файлов

В проекте часто создаются файлы, которые вы not хотите отслеживать с помощью Git. Обычно это файлы, созданные в процессе сборки, или временные резервные копии, создаваемые редактором. Разумеется, not отслеживать файлы с помощью Git — всего лишь вопрос not вызова для них команды git add. Но вскоре начинает раздражать присутствие этих неотслеживаемых файлов: например, они делают git add . практически бесполезной, а также постоянно появляются в выводе git status.

Можно указать Git игнорировать определённые файлы, создав в корневом каталоге рабочего дерева файл с именем .gitignore и добавив в него, например, следующее:

# Lines starting with '#' are considered comments.
# Ignore any file named foo.txt.
foo.txt
# Ignore (generated) html files,
*.html
# except foo.html which is maintained by hand.
!foo.html
# Ignore objects and archives.
*.[oa]

Подробное описание синтаксиса см. в gitignore[5]. Файлы .gitignore можно также размещать в других каталогах рабочего дерева; в этом случае они будут применяться к этим каталогам и их подкаталогам. Файлы .gitignore можно добавлять в репозиторий, как и любые другие файлы (как обычно, достаточно выполнить git add .gitignore и git commit). Это удобно, если шаблоны исключения (например, шаблоны для файлов, создаваемых при сборке) пригодятся и другим пользователям, клонирующим ваш репозиторий.

Если вы хотите, чтобы шаблоны исключения применялись только к определённым репозиториям (а не ко всем репозиториям данного проекта), можно поместить их в файл с именем .git/info/exclude в репозитории или в любой файл, указанный переменной конфигурации core.excludesFile. Некоторые команды Git также принимают шаблоны исключения непосредственно в командной строке. Подробности см. в gitignore[5].

Как выполнить слияние

С помощью git-merge[1] можно объединить две разошедшиеся ветки разработки:

$ git merge branchname

объединяет изменения из ветки branchname с текущей веткой.

При слиянии объединяются изменения, внесённые в branchname, и изменения, внесённые в текущую ветку после расхождения историй, вплоть до последнего коммита. Если объединение проходит без конфликтов, рабочее дерево перезаписывается результатом слияния; если возникают конфликты — промежуточным результатом слияния. Поэтому Git откажется продолжать, если у вас есть незакоммиченные изменения в тех же файлах, которых касается слияние. Как правило, перед слиянием нужно закоммитить свои изменения. Если этого не сделать, git-stash[1] поможет временно убрать их на время слияния и восстановить после него.

Если изменения достаточно независимы, Git автоматически завершит слияние и создаст коммит с результатом (или повторно использует существующий коммит в случае перемотки вперёд; см. ниже). Если же возникнут конфликты — например, если один и тот же файл по-разному изменён в удалённой и локальной ветках, — Git предупредит вас; вывод может выглядеть примерно так:

$ git merge next
 100% (4/4) done
Auto-merged file.txt
CONFLICT (content): Merge conflict in file.txt
Automatic merge failed; fix conflicts and then commit the result.

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

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

Разрешение конфликтов слияния

Если Git не удаётся выполнить слияние автоматически, он оставляет индекс и рабочее дерево в особом состоянии, предоставляя всю необходимую информацию для разрешения конфликта.

Файлы с конфликтами помечаются в индексе особым образом, поэтому, пока вы не разрешите конфликт и не обновите индекс, git-commit[1] завершится ошибкой:

$ git commit
file.txt: needs merge

Кроме того, git-status[1] укажет эти файлы как «необъединённые», а в файлах с конфликтами будут добавлены маркеры конфликта, например:

<<<<<<< HEAD:file.txt
Hello world
=======
Goodbye
>>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt

Вам нужно лишь отредактировать файлы, чтобы разрешить конфликты, а затем выполнить

$ git add file.txt
$ git commit

Обратите внимание, что сообщение коммита уже будет заполнено некоторой информацией о слиянии. Обычно можно оставить это сообщение без изменений, но при желании добавить собственные пояснения.

Этого достаточно, чтобы разрешить простой конфликт слияния. Но Git также предоставляет дополнительную информацию, которая поможет разрешить конфликты:

$ git diff
diff --cc file.txt
index 802992c,2b60207..0000000
--- a/file.txt
+++ b/file.txt
@@@ -1,1 -1,1 +1,5 @@@
++<<<<<<< HEAD:file.txt
 +Hello world
++=======
+ Goodbye
++>>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt

$ git show :1:file.txt        # the file in a common ancestor of both branches
$ git show :2:file.txt        # the version from HEAD.
$ git show :3:file.txt        # the version from MERGE_HEAD.

$ git diff
diff --cc file.txt
index 802992c,2b60207..0000000
--- a/file.txt
+++ b/file.txt
@@@ -1,1 -1,1 +1,1 @@@
- Hello world
 -Goodbye
++Goodbye world

$ git diff -1 file.txt                # diff against stage 1
$ git diff --base file.txt        # same as the above
$ git diff -2 file.txt                # diff against stage 2
$ git diff --ours file.txt        # same as the above
$ git diff -3 file.txt                # diff against stage 3
$ git diff --theirs file.txt        # same as the above.

$ git diff AUTO_MERGE
diff --git a/file.txt b/file.txt
index cd10406..8bf5ae7 100644
--- a/file.txt
+++ b/file.txt
@@ -1,5 +1 @@
-<<<<<<< HEAD:file.txt
-Hello world
-=======
-Goodbye
->>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt
+Goodbye world

$ git log --merge
$ gitk --merge

$ git add file.txt

Отмена слияния

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

$ git merge --abort

Или, если вы уже создали коммит слияния, который хотите отменить, выполните

$ git reset --hard ORIG_HEAD

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

Слияния с перемоткой вперёд

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

Однако если текущая ветка является предком другой ветки — то есть все коммиты текущей ветки уже содержатся в другой ветке, — Git просто выполняет «перемотку вперёд»: вершина текущей ветки перемещается вперёд и начинает указывать на вершину объединяемой ветки, при этом новые коммиты не создаются.

Исправление ошибок

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

$ git restore --staged --worktree :/

Если вы создали коммит, о котором впоследствии пожалели, есть два принципиально разных способа исправить ситуацию:

$ git revert HEAD

$ git revert HEAD^

$ git commit --amend

$ git restore --source=HEAD^ path/to/file

$ git show HEAD^:path/to/file

$ git stash push -m "work in progress for foo feature"

... edit and test ...
$ git commit -a -m "blorpl: typofix"

$ git stash pop

Обеспечение высокой производительности

В больших репозиториях Git использует сжатие, чтобы история не занимала слишком много места на диске и в памяти. Некоторые команды Git могут автоматически запускать git-gc[1], поэтому вручную запускать её не обязательно. Однако сжатие большого репозитория может занять некоторое время, поэтому можно явно вызвать gc, чтобы автоматическое сжатие не запустилось в неподходящий момент.

Обеспечение надёжности

$ git fsck
dangling commit 7281251ddd2a61e38657c827739c57015671a6b3
dangling commit 2706a059f258c6b245f298dc4ff2ccd30ec21a63
dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5
dangling blob 218761f9d90712d37a9c5e36f406f92202db07eb
dangling commit bf093535a34a4d35731aa2bd90fe6b176302f14f
dangling commit 8e4bec7f2ddaa268bef999853c25755452100f8e
dangling tree d50bb86186bf27b681d25af89d3b5b68382e4085
dangling tree b24c2473f1fd3d91352a624795be026d64c8841f
...

$ git log master@{1}

$ git show master@{2}                # See where the branch pointed 2,
$ git show master@{3}                # 3, ... changes ago.
$ gitk master@{yesterday}        # See where it pointed yesterday,
$ gitk master@{"1 week ago"}        # ... or last week
$ git log --walk-reflogs master        # show reflog entries for master

$ git show HEAD@{"1 week ago"}

$ git fsck
dangling commit 7281251ddd2a61e38657c827739c57015671a6b3
dangling commit 2706a059f258c6b245f298dc4ff2ccd30ec21a63
dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5
...

$ gitk 7281251ddd --not --all

$ git branch recovered-branch 7281251ddd

Получение обновлений с помощью git pull

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

Мы уже видели, как поддерживать ветки отслеживания удалённых репозиториев в актуальном состоянии с помощью git-fetch[1], а также как объединить две ветки. Поэтому можно объединить изменения из главной ветки исходного репозитория с помощью команды:

$ git fetch
$ git merge origin/master

Однако команда git-pull[1] позволяет сделать это за один шаг:

$ git pull origin master

На самом деле, если у вас извлечена ветка master, то эта ветка настроена командой git clone на получение изменений из ветки HEAD репозитория origin. Поэтому часто всё описанное выше можно сделать простой командой

$ git pull

Эта команда получит изменения из удалённых веток в ваши ветки отслеживания удалённых репозиториев origin/* и объединит ветку по умолчанию с текущей веткой.

В более общем случае ветка, созданная из ветки отслеживания удалённого репозитория, по умолчанию будет получать изменения именно из этой ветки. Описание параметров branch.<name>.remote и branch.<name>.merge в git-config[1], а также обсуждение параметра --track в git-checkout[1] помогут узнать, как управлять этими настройками по умолчанию.

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

(Обратите внимание: если происходит перемотка вперёд, такой коммит не создаётся; вместо этого ваша ветка просто обновляется, чтобы указывать на последний коммит вышестоящей ветки.)

Команде git pull также можно передать . в качестве «удалённого» репозитория; в этом случае она просто объединит ветку из текущего репозитория. Поэтому команды

$ git pull . branch
$ git merge branch

примерно эквивалентны.

Отправка исправлений в проект

Если у вас всего несколько изменений, проще всего отправить их в виде исправлений по электронной почте:

Сначала воспользуйтесь git-format-patch[1], например:

$ git format-patch origin

эта команда создаст в текущем каталоге пронумерованную последовательность файлов — по одному для каждого исправления в текущей ветке, которого нет в origin/HEAD.

git format-patch может включать вступительное «сопроводительное письмо». Вы можете добавить комментарий к отдельным исправлениям после строки из трёх дефисов, которую format-patch помещает после сообщения коммита, но перед самим исправлением. Если для отслеживания материалов сопроводительного письма использовать git notes, команда git format-patch --notes аналогичным образом добавит заметки коммита.

Затем можно импортировать эти файлы в почтовый клиент и отправить их вручную. Однако, если нужно отправить сразу много писем, можно автоматизировать этот процесс с помощью скрипта git-send-email[1]. Сначала ознакомьтесь с требованиями к отправке исправлений, принятыми в списке рассылки вашего проекта.

Импорт исправлений в проект

В Git также есть инструмент git-am[1] (am означает «применить почтовый ящик»), предназначенный для импорта полученной по электронной почте последовательности исправлений. Просто сохраните все письма с исправлениями в правильном порядке в один файл почтового ящика, например patches.mbox, а затем выполните

$ git am -3 patches.mbox

Git применит каждое исправление по порядку; если возникнут конфликты, выполнение остановится, и вы сможете устранить их, как описано в разделе «Устранение конфликтов при слиянии». (Параметр -3 указывает Git выполнить слияние; если вы предпочитаете отменить операцию и оставить дерево и индекс без изменений, этот параметр можно опустить.)

После обновления индекса результатами разрешения конфликтов, вместо создания нового коммита просто выполните

$ git am --continue

Git создаст коммит и продолжит применять оставшиеся исправления из почтового ящика.

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

Публичные репозитории Git

Ещё один способ передать изменения в проект — попросить его сопровождающего получить изменения из вашего репозитория с помощью git-pull[1]. В разделе «Получение обновлений с помощью git pull» мы описали этот способ как вариант получения обновлений из «основного» репозитория, но он так же хорошо работает и в обратном направлении.

Если у вас и сопровождающего есть учётные записи на одном компьютере, вы можете напрямую получать изменения из репозиториев друг друга; команды, принимающие URL репозитория в качестве аргумента, также принимают имя локального каталога:

$ git clone /path/to/repository
$ git pull /path/to/other/repository

или URL SSH:

$ git clone ssh://yourhost/~you/repository

Для проектов с небольшим числом разработчиков или для синхронизации нескольких частных репозиториев этого может быть достаточно.

Однако чаще для этого поддерживают отдельный публичный репозиторий (обычно на другом сервере), из которого остальные могут получать изменения. Как правило, это удобнее и позволяет чётко отделить незавершённую частную работу от работы, доступной всем.

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

                      you push
your personal repo ------------------> your public repo
      ^                                     |
      |                                     |
      | you pull                            | they pull
      |                                     |
      |                                     |
      |               they push             V
their public repo <------------------- their repo

В следующих разделах объясняется, как это сделать.

$ git clone --bare ~/proj proj.git
$ touch proj.git/git-daemon-export-ok

$ mv proj.git /home/you/public_html/proj.git
$ cd proj.git
$ git --bare update-server-info
$ mv hooks/post-update.sample hooks/post-update

$ git clone http://yourserver.com/~you/proj.git

$ git push ssh://yourserver.com/~you/proj.git master:master

$ git push ssh://yourserver.com/~you/proj.git master

$ git remote add public-repo ssh://yourserver.com/~you/proj.git

[remote "public-repo"]
        url = yourserver.com:proj.git
        fetch = +refs/heads/*:refs/remotes/example/*

$ git push public-repo master

 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to '...'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

$ git push ssh://yourserver.com/~you/proj.git +master

$ git push -f ssh://yourserver.com/~you/proj.git master

Как получить репозиторий Git с минимальной историей

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

Поверхностный клон создаётся с помощью параметра --depth команды git-clone[1]. Позже глубину можно изменить с помощью параметра --depth команды git-fetch[1] или восстановить полную историю с помощью --unshallow.

Слияние в поверхностном клоне будет работать, пока база слияния находится в недавней истории. В противном случае оно будет похоже на слияние несвязанных историй и может привести к огромному числу конфликтов. Из-за этого ограничения такой репозиторий может не подойти для рабочих процессов, основанных на слиянии.

Примеры

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git work
$ cd work

$ git branch --track test origin/master
$ git branch --track release origin/master

$ git switch test && git pull
$ git switch release && git pull

$ cat >> .git/config <<EOF
[remote "mytree"]
        url =  master.kernel.org:/pub/scm/linux/kernel/git/aegl/linux.git
        push = release
        push = test
EOF

$ git push mytree

$ git push mytree test

$ git push mytree release

$ git switch -c speed-up-spinlocks v2.6.35

$ ... patch ... test  ... commit [ ... patch ... test ... commit ]*

$ git switch test && git merge speed-up-spinlocks

$ git switch release && git merge speed-up-spinlocks

$ git log linux..branchname | git shortlog

$ git log test..branchname

$ git log release..branchname

$ git log origin..branchname

$ git branch -d branchname

$ git push mytree
$ git request-pull origin mytree release

==== update script ====
# Update a branch in my Git tree.  If the branch to be updated
# is origin, then pull from kernel.org.  Otherwise merge
# origin/master branch into test|release branch

case "$1" in
test|release)
        git checkout $1 && git pull . origin
        ;;
origin)
        before=$(git rev-parse refs/remotes/origin/master)
        git fetch origin
        after=$(git rev-parse refs/remotes/origin/master)
        if [ $before != $after ]
        then
                git log $before..$after | git shortlog
        fi
        ;;
*)
        echo "usage: $0 origin|test|release" 1>&2
        exit 1
        ;;
esac

==== merge script ====
# Merge a branch into either the test or release branch

pname=$0

usage()
{
        echo "usage: $pname branch test|release" 1>&2
        exit 1
}

git show-ref -q --verify -- refs/heads/"$1" || {
        echo "Can't see branch <$1>" 1>&2
        usage
}

case "$2" in
test|release)
        if [ $(git log $2..$1 | wc -c) -eq 0 ]
        then
                echo $1 already merged into $2 1>&2
                exit 1
        fi
        git checkout $2 && git pull . $1
        ;;
*)
        usage
        ;;
esac

==== status script ====
# report on status of my ia64 Git tree

gb=$(tput setab 2)
rb=$(tput setab 1)
restore=$(tput setab 9)

if [ `git rev-list test..release | wc -c` -gt 0 ]
then
        echo $rb Warning: commits in release that are not in test $restore
        git log test..release
fi

for branch in `git show-ref --heads | sed 's|^.*/||'`
do
        if [ $branch = test -o $branch = release ]
        then
                continue
        fi

        echo -n $gb ======= $branch ====== $restore " "
        status=
        for ref in test release origin/master
        do
                if [ `git rev-list $ref..$branch | wc -c` -gt 0 ]
                then
                        status=$status${ref:0:1}
                fi
        done
        case $status in
        trl)
                echo $rb Need to pull into test $restore
                ;;
        rl)
                echo "In test"
                ;;
        l)
                echo "Waiting for linus"
                ;;
        "")
                echo $rb All done $restore
                ;;
        *)
                echo $rb "<$status>" $restore
                ;;
        esac
        git log origin/master..$branch | git shortlog
done

Создание идеальной серии патчей

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

Если представить все изменения в виде одного патча (или коммита), их может оказаться слишком много, чтобы изучить всё сразу.

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

Поэтому обычно идеальный вариант — подготовить серию патчей, в которой:

Мы рассмотрим инструменты, которые помогут вам это сделать, объясним, как ими пользоваться, а затем расскажем о некоторых проблемах, которые могут возникнуть из-за переписывания истории.

Поддержание актуальности серии патчей с помощью git rebase

Предположим, вы создаёте ветку mywork на основе удалённой отслеживаемой ветки origin и создаёте несколько коммитов поверх неё:

$ git switch -c mywork origin
$ vi file.txt
$ git commit
$ vi otherfile.txt
$ git commit
...

Вы не выполняли слияний в mywork, поэтому это просто линейная последовательность патчей поверх origin:

 o--o--O <-- origin
        \
         a--b--c <-- mywork

В исходном проекте проделали более интересную работу, и origin продвинулась вперёд:

 o--o--O--o--o--o <-- origin
        \
         a--b--c <-- mywork

На этом этапе можно использовать pull, чтобы влить изменения обратно; в результате будет создан новый коммит слияния, например:

 o--o--O--o--o--o <-- origin
        \        \
         a--b--c--m <-- mywork

Однако, если вы предпочитаете сохранять в mywork простую последовательность коммитов без слияний, можно вместо этого воспользоваться git-rebase[1]:

$ git switch mywork
$ git rebase origin

Эта команда удалит каждый ваш коммит из mywork, временно сохранив их в виде патчей (в каталоге с именем .git/rebase-apply), обновит mywork до последней версии origin, а затем применит каждый из сохранённых патчей к новой версии mywork. Результат будет выглядеть так:

 o--o--O--o--o--o <-- origin
                 \
                  a'--b'--c' <-- mywork

В процессе могут обнаружиться конфликты. В этом случае выполнение остановится, чтобы вы могли их устранить; после устранения конфликтов используйте git add, чтобы обновить индекс с учётом этих изменений, а затем вместо запуска git commit просто выполните

$ git rebase --continue

и Git продолжит применять остальные патчи.

В любой момент можно воспользоваться параметром --abort, чтобы прервать этот процесс и вернуть mywork в состояние, в котором она находилась до начала перебазирования:

$ git rebase --abort

Если нужно переупорядочить или отредактировать несколько коммитов в ветке, может быть удобнее использовать git rebase -i: эта команда позволяет переупорядочить коммиты и объединить их, а также пометить отдельные коммиты для редактирования во время перебазирования. Подробнее см. в разделе Использование интерактивного перебазирования, а альтернативные варианты — в разделе Переупорядочивание серии патчей или выбор патчей из неё.

Переписывание одного коммита

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

$ git commit --amend

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

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

Переупорядочивание серии патчей или выбор патчей из неё

Иногда возникает необходимость отредактировать коммит, находящийся глубже в истории. Один из вариантов — использовать git format-patch, чтобы создать серию патчей, а затем вернуть состояние к моменту до применения этих патчей:

$ git format-patch origin
$ git reset --hard origin

Затем при необходимости измените, переупорядочьте или удалите патчи, прежде чем применить их снова с помощью git-am[1]:

$ git am *.patch

Использование интерактивного перебазирования

Также можно редактировать серию патчей с помощью интерактивного перебазирования. Оно позволяет переупорядочить серию патчей с помощью format-patch, поэтому используйте тот интерфейс, который вам больше нравится.

Перебазируйте текущий HEAD на последний коммит, который нужно оставить без изменений. Например, чтобы переупорядочить последние 5 коммитов, выполните:

$ git rebase -i HEAD~5

В редакторе откроется список шагов, которые будут выполнены при перебазировании.

pick deadbee The oneline of this commit
pick fa1afe1 The oneline of the next commit
...

# Rebase c0ffeee..deadbee onto c0ffeee
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

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

Перебазирование остановится там, где pick заменено на edit, или если на каком-либо шаге не удастся автоматически разрешить конфликты и потребуется ваша помощь. Закончив редактирование и/или разрешение конфликтов, можно продолжить с помощью команды git rebase --continue. Если процесс становится слишком сложным, его всегда можно прервать командой git rebase --abort. Даже после завершения перебазирования исходную ветку всё ещё можно восстановить с помощью журнала ссылок (reflog).

Более подробное описание этой процедуры и дополнительные советы см. в разделе «ИНТЕРАКТИВНЫЙ РЕЖИМ» справочной страницы git-rebase[1].

Другие инструменты

Существует множество других инструментов, например StGit, предназначенных для сопровождения серии патчей. Их рассмотрение выходит за рамки этого руководства.

Проблемы переписывания истории

Основная проблема переписывания истории ветки связана со слияниями. Предположим, кто-то получает вашу ветку и сливает её со своей веткой, в результате чего получается примерно следующее:

 o--o--O--o--o--o <-- origin
        \        \
         t--t--t--m <-- their branch:

Затем предположим, что вы изменяете последние три коммита:

         o--o--o <-- new head of origin
        /
 o--o--O--o--o--o <-- old head of origin

Если рассмотреть всю эту историю вместе в одном репозитории, она будет выглядеть так:

         o--o--o <-- new head of origin
        /
 o--o--O--o--o--o <-- old head of origin
        \        \
         t--t--t--m <-- their branch:

Git никак не может определить, что новая вершина ветки — это обновлённая версия старой; он рассматривает эту ситуацию так же, как если бы два разработчика независимо выполнили работу на старой и новой вершинах ветки параллельно. Если на этом этапе кто-то попытается влить новую вершину в свою ветку, Git попытается объединить две линии разработки (старую и новую), а не заменить старую новой. Результат, скорее всего, будет неожиданным.

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

Для полноценной распределённой разработки с корректной поддержкой слияний опубликованные ветки никогда не следует переписывать.

Почему поиск с помощью bisect по коммитам слияния может быть сложнее, чем по линейной истории

Команда git-bisect[1] корректно обрабатывает историю, содержащую коммиты слияния. Однако, если найденный ею коммит является коммитом слияния, пользователю может потребоваться приложить больше усилий, чем обычно, чтобы выяснить, почему именно этот коммит внёс проблему.

Представьте себе такую историю:

      ---Z---o---X---...---o---A---C---D
          \                       /
           o---o---Y---...---o---B

Предположим, что в верхней линии разработки в коммите X меняется смысл одной из функций, существующих в Z. Коммиты от Z до A изменяют как реализацию функции, так и все места её вызова, существовавшие в Z, а также новые места вызова, добавленные этими коммитами, чтобы они соответствовали друг другу. В A ошибки нет.

Предположим, что тем временем в нижней линии разработки кто-то добавляет новое место вызова этой функции в коммите Y. Коммиты от Z до B исходят из старого поведения этой функции, а вызывающий и вызываемый код согласованы друг с другом. В B тоже нет ошибки.

Кроме того, предположим, что две линии разработки сливаются в C без конфликтов, поэтому разрешать конфликты не требуется.

Тем не менее код в C содержит ошибку, поскольку места вызова, добавленные в нижней линии разработки, не были адаптированы к новому поведению, введённому в верхней линии разработки. Если вам известно только, что D содержит ошибку, Z работает правильно, а git-bisect[1] указывает на C как на причину проблемы, как выяснить, что проблема вызвана изменением поведения функции?

Если результатом git bisect является коммит, не являющийся коммитом слияния, обычно достаточно изучить только этот коммит, чтобы обнаружить проблему. Разработчики могут упростить эту задачу, разбивая изменения на небольшие, самостоятельные коммиты. Однако в описанном выше случае это не поможет, поскольку проблема не очевидна при изучении какого-либо одного коммита; вместо этого требуется рассмотреть процесс разработки в целом. Что ещё хуже, изменение поведения проблемной функции может быть лишь небольшой частью изменений в верхней линии разработки.

С другой стороны, если бы вместо слияния в C вы перебазировали историю от Z до B поверх A, получилась бы такая линейная история:

    ---Z---o---X--...---o---A---o---o---Y*--...---o---B*--D*

При поиске между Z и D* был бы найден один коммит-причина — Y*, и понять, почему Y* содержит ошибку, вероятно, было бы проще.

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

Получение отдельных веток

Вместо использования git-remote[1] можно обновлять по одной ветке за раз и сохранять её локально под произвольным именем:

$ git fetch origin todo:my-todo-work

Первый аргумент, origin, просто указывает Git получить данные из репозитория, из которого вы изначально клонировали проект. Второй аргумент указывает Git получить из удалённого репозитория ветку с именем todo и сохранить её локально под именем refs/heads/my-todo-work.

Можно также получать ветки из других репозиториев. Например, команда

$ git fetch git://example.com/proj.git master:example-master

создаст новую ветку с именем example-master и сохранит в ней ветку с именем master из репозитория по указанному URL. Если ветка example-master уже существует, Git попытается выполнить для неё перемотку вперёд до коммита, на который указывает ветка master на example.com. Подробнее:

git fetch и перемотка вперёд

В предыдущем примере при обновлении существующей ветки команда git fetch проверяет, является ли последний коммит удалённой ветки потомком последнего коммита в вашей копии этой ветки, прежде чем обновить вашу копию и переместить её указатель на новый коммит. Git называет этот процесс перемоткой вперёд.

Перемотка вперёд выглядит примерно так:

 o--o--o--o <-- old head of the branch
           \
            o--o--o <-- new head of the branch

В некоторых случаях новая вершина ветки может не являться потомком старой вершины. Например, разработчик мог обнаружить серьёзную ошибку и решить вернуться к предыдущему состоянию. Тогда ситуация будет выглядеть примерно так:

 o--o--o--o--a--b <-- old head of the branch
           \
            o--o--o <-- new head of the branch

В этом случае команда git fetch завершится ошибкой и выведет предупреждение.

В такой ситуации всё ещё можно принудительно переместить указатель Git на новую вершину ветки, как описано в следующем разделе. Однако учтите, что в приведённом выше случае это может привести к потере коммитов с метками a и b, если вы заранее не создали собственную ссылку, указывающую на них.

Принудительное выполнение git fetch без перемотки вперёд

Если выполнение git fetch завершается ошибкой, потому что новая вершина ветки не является потомком старой, обновление можно выполнить принудительно:

$ git fetch git://example.com/proj.git +master:refs/remotes/example/master

Обратите внимание на знак +. В качестве альтернативы можно использовать флаг -f, чтобы принудительно обновить все полученные ветки, например:

$ git fetch -f origin

Помните, что коммиты, на которые указывала старая версия example/master, могут быть потеряны, как описано в предыдущем разделе.

Настройка удалённых отслеживаемых веток

Выше мы увидели, что origin — это просто сокращённое обозначение репозитория, из которого вы изначально клонировали проект. Эта информация хранится в переменных конфигурации Git, которые можно просмотреть с помощью git-config[1]:

$ git config list
core.repositoryformatversion=0
core.filemode=true
core.logallrefupdates=true
remote.origin.url=git://git.kernel.org/pub/scm/git/git.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master

Если вы часто используете и другие репозитории, можно создать аналогичные параметры конфигурации, чтобы не вводить команды целиком. Например, команда

$ git remote add example git://example.com/proj.git

добавит в .git/config следующие строки:

[remote "example"]
        url = git://example.com/proj.git
        fetch = +refs/heads/*:refs/remotes/example/*

Обратите также внимание, что приведённую выше конфигурацию можно задать, отредактировав файл .git/config напрямую, а не используя git-remote[1].

После настройки удалённого репозитория следующие три команды выполняют одно и то же:

$ git fetch git://example.com/proj.git +refs/heads/*:refs/remotes/example/*
$ git fetch example +refs/heads/*:refs/remotes/example/*
$ git fetch example

Подробнее о перечисленных выше параметрах конфигурации см. в git-config[1], а о синтаксисе refspec — в git-fetch[1].

База объектов

В разделе Понимание истории: коммиты мы уже видели, что все коммиты хранятся под 40-значным «именем объекта». На самом деле вся информация, необходимая для представления истории проекта, хранится в объектах с такими именами. В каждом случае имя вычисляется как хеш SHA-1 содержимого объекта. Хеш SHA-1 — это криптографическая хеш-функция. Для нас это означает, что невозможно найти два разных объекта с одинаковым именем. У этого есть ряд преимуществ, в частности:

(Подробности о формате объектов и вычислении SHA-1 см. в разделе Формат хранения объектов.)

Существует четыре разных типа объектов: «blob», «tree», «commit» и «tag».

Подробнее о типах объектов:

$ git show -s --pretty=raw 2be7fcb476
commit 2be7fcb4764f2dbcee52635b91fedb1b3dcf7ab4
tree fb3a8bdd0ceddd019615af4d57a53f43d8cee2bf
parent 257a84d9d02e90447b149af58b271c19405edb6a
author Dave Watson <dwatson@mimvista.com> 1187576872 -0400
committer Junio C Hamano <gitster@pobox.com> 1187591163 -0700

    Fix misspelling of 'suppress' in docs

    Signed-off-by: Junio C Hamano <gitster@pobox.com>

$ git ls-tree fb3a8bdd0ce
100644 blob 63c918c667fa005ff12ad89437f2fdc80926e21c    .gitignore
100644 blob 5529b198e8d14decbe4ad99db3f7fb632de0439d    .mailmap
100644 blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3    COPYING
040000 tree 2fb783e477100ce076f6bf57e4a6f026013dc745    Documentation
100755 blob 3c0032cec592a765692234f1cba47dfdcc3a9200    GIT-VERSION-GEN
100644 blob 289b046a443c0647624607d471289b2c7dcd470b    INSTALL
100644 blob 4eb463797adc693dc168b926b6932ff53f17d0b1    Makefile
100644 blob 548142c327a6790ff8821d67c2ee1eff7a656b52    README
...

$ git show 6ff87c4664

 Note that the only valid version of the GPL as far as this project
 is concerned is _this_ particular version of the license (ie v2, not
 v2.2 or v3.x or whatever), unless explicitly otherwise stated.
...

$ git cat-file tag v1.5.0
object 437b1b20df4b356c9342dac8d38849f24ef44f27
type commit
tag v1.5.0
tagger Junio C Hamano <junkio@cox.net> 1171411200 +0000

GIT 1.5.0
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBF0lGqwMbZpPMRm5oRAuRiAJ9ohBLd7s2kqjkKlq1qqC57SbnmzQCdG4ui
nLE/L9aUXdWeTFPron96DLA=
=2E+0
-----END PGP SIGNATURE-----

$ git count-objects
6930 objects, 47620 kilobytes

$ git repack
Counting objects: 6020, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6020/6020), done.
Writing objects: 100% (6020/6020), done.
Total 6020 (delta 4070), reused 0 (delta 0)

$ git prune

$ git count-objects
0 objects, 0 kilobytes

$ gitk <dangling-commit-sha-goes-here> --not --all

$ git branch recovered-branch <dangling-commit-sha-goes-here>

$ git show <dangling-blob/tree-sha-goes-here>

$ git prune

$ git fsck --full --no-dangling
broken link from    tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
              to    blob 4b9458b3786228369c63936db65827de3cc06200
missing blob 4b9458b3786228369c63936db65827de3cc06200

$ git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
100644 blob 8d14531846b95bfa3564b58ccfb7913a034323b8        .gitignore
100644 blob ebf9bf84da0aab5ed944264a5db2a65fe3a3e883        .mailmap
100644 blob ca442d313d86dc67e0a2e5d584b465bd382cbf5c        COPYING
...
100644 blob 4b9458b3786228369c63936db65827de3cc06200        myfile
...

$ git hash-object -w somedirectory/myfile

$ git log --raw --all --full-history -- somedirectory/myfile

commit abc
Author:
Date:
...
:100644 100644 4b9458b newsha M somedirectory/myfile


commit xyz
Author:
Date:

...
:100644 100644 oldsha 4b9458b M somedirectory/myfile

$ git hash-object -w <recreated-file>

$ git log --raw --all

Индекс

Индекс — это двоичный файл (обычно хранящийся в .git/index), содержащий отсортированный список путей, каждый из которых сопровождается правами доступа и SHA-1 blob-объекта. Содержимое индекса можно посмотреть с помощью git-ls-files[1]:

$ git ls-files --stage
100644 63c918c667fa005ff12ad89437f2fdc80926e21c 0        .gitignore
100644 5529b198e8d14decbe4ad99db3f7fb632de0439d 0        .mailmap
100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3 0        COPYING
100644 a37b2152bd26be2c2289e1f57a292534a51a93c7 0        Documentation/.gitignore
100644 fbefe9a45b00a54b58d94d06eca48b03d40a50e0 0        Documentation/Makefile
...
100644 2511aef8d89ab52be5ec6a5e46236b4b6bcd07ea 0        xdiff/xtypes.h
100644 2ade97b2574a9f77e7ae4002a4e07a6a38e46d07 0        xdiff/xutils.c
100644 d5de8292e05e7c36c4b68857c1cf9855e3d2f70a 0        xdiff/xutils.h

Обратите внимание: в старой документации индекс может называться «кэшем текущего каталога» или просто «кэшем». У него есть три важных свойства:

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

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

Подводные камни при работе с подмодулями

Всегда публикуйте изменение подмодуля до публикации изменения суперпроекта, который на него ссылается. Если забыть опубликовать изменение подмодуля, другие не смогут клонировать репозиторий:

$ cd ~/git/super/a
$ echo i added another line to this file >> a.txt
$ git commit -a -m "doing it wrong this time"
$ cd ..
$ git add a
$ git commit -m "Updated submodule a again."
$ git push
$ cd ~/git/cloned
$ git pull
$ git submodule update
error: pathspec '261dfac35cb99d380eb966e102c1197139f7fa24' did not match any file(s) known to git.
Did you forget to 'git add'?
Unable to checkout '261dfac35cb99d380eb966e102c1197139f7fa24' in submodule path 'a'

В старых версиях Git легко было забыть закоммитить новые или изменённые файлы в подмодуле, что незаметно приводило к проблемам, аналогичным тем, которые возникают, если не отправить изменения подмодуля. Начиная с Git 1.7.0 команды git status и git diff в суперпроекте показывают подмодули как изменённые, если они содержат новые или изменённые файлы, чтобы защитить от случайного коммита такого состояния. Команда git diff также добавит -dirty со стороны рабочего дерева при создании вывода исправления или при использовании параметра --submodule:

$ git diff
diff --git a/sub b/sub
--- a/sub
+++ b/sub
@@ -1 +1 @@
-Subproject commit 3f356705649b5d566d97ff843cf193359229a453
+Subproject commit 3f356705649b5d566d97ff843cf193359229a453-dirty
$ git diff --submodule
Submodule sub 3f35670..3f35670-dirty:

Не следует также откатывать ветки в подмодуле за пределы коммитов, которые когда-либо фиксировались в любом суперпроекте.

Небезопасно выполнять git submodule update, если вы внесли и закоммитили изменения в подмодуле, не переключившись предварительно на ветку. Эти изменения будут незаметно перезаписаны:

$ cat a.txt
module a
$ echo line added from private2 >> a.txt
$ git commit -a -m "line added inside private2"
$ cd ..
$ git submodule update
Submodule path 'a': checked out 'd266b9873ad50488163457f025db7cdd9683d88b'
$ cd a
$ cat a.txt
module a

Если в рабочем дереве подмодуля есть незакоммиченные изменения, команда git submodule update не перезапишет их. Вместо этого вы получите обычное предупреждение о том, что нельзя переключиться с изменённой ветки.

Формат хранения объектов

Тип каждого объекта определяется статически и указывает его формат (то есть то, как он используется и как может ссылаться на другие объекты). В настоящее время существует четыре типа объектов: «blob», «tree», «commit» и «tag».

Независимо от типа, у всех объектов есть следующие общие свойства: все они сжаты с помощью zlib и имеют заголовок, в котором указан не только их тип, но и размер содержащихся в объекте данных. Стоит отметить, что хеш SHA-1, используемый для имени объекта, вычисляется по исходным данным вместе с этим заголовком. Поэтому sha1sum file не совпадает с именем объекта для file (в самых ранних версиях Git хеширование выполнялось несколько иначе, но вывод остаётся тем же).

Ниже приведён краткий пример ручного вычисления таких хешей:

Предположим, у нас есть небольшой текстовый файл с простым содержимым:

$ echo "Hello world" >hello.txt

Теперь можно вручную вычислить хеш, который Git использовал бы для этого файла:

$ { printf "blob 12\0"; cat hello.txt; } | sha1sum
802992c4220de19a90767f3000a79a31b98d0df7  -

Этот вычисленный вручную хеш можно проверить с помощью git hash-object, которая, разумеется, скрывает добавление заголовка:

$ git hash-object hello.txt
802992c4220de19a90767f3000a79a31b98d0df7

Таким образом, общую целостность объекта всегда можно проверить независимо от его содержимого и типа: все объекты можно проверить, убедившись, что (a) их хеши соответствуют содержимому файла и (b) объект успешно распаковывается в поток байтов, образующий последовательность <ascii-type-without-space> + <space> + <ascii-decimal-size> + <byte\0> + <binary-object-data>.

Кроме того, можно проверить структуру структурированных объектов и их связи с другими объектами. Обычно это делается с помощью программы git fsck, которая строит полный граф зависимостей всех объектов и проверяет их внутреннюю целостность (помимо поверхностной проверки целостности с помощью хеша).

Краткий обзор исходного кода Git

Новым разработчикам не всегда легко разобраться в исходном коде Git. В этом разделе приведены небольшие подсказки, которые помогут понять, с чего начать.

Хорошее начало — изучить содержимое первоначального коммита:

$ git switch --detach e83c5163

В первоначальной версии заложена основа почти всего, что есть в Git сегодня (хотя в некоторых местах детали могут отличаться), но она достаточно мала, чтобы прочитать её за один присест.

Обратите внимание, что со времени этой версии терминология изменилась. Например, в README этой версии используется слово «changeset» для описания того, что теперь мы называем коммитом.

Также мы больше не называем это «кэшем», а говорим «индекс»; однако файл по-прежнему называется read-cache.h.

Если вы усвоили идеи, изложенные в первоначальном коммите, изучите более новую версию и бегло прочитайте read-cache-ll.h, object.h и commit.h.

В первые годы Git (в традициях UNIX) представлял собой набор предельно простых программ, которые использовались в скриптах: вывод одной программы передавался другой. Для начальной разработки это оказалось удобно, поскольку упрощало тестирование новых возможностей. Однако в последнее время многие из этих частей стали встроенными командами, а часть основного кода была «перенесена в библиотеку», то есть в libgit.a, ради повышения производительности и переносимости, а также во избежание дублирования кода.

К этому моменту вы уже знаете, что такое индекс (и найдёте соответствующие структуры данных в read-cache-ll.h), и что есть лишь несколько типов объектов (блобы, деревья, коммиты и теги), которые наследуют общую структуру от struct object — своего первого члена (поэтому, например, можно привести (struct object *)commit, чтобы получить same, как в &commit->object, то есть доступ к имени объекта и флагам).

Сейчас самое время сделать перерыв и обдумать эту информацию.

Следующий шаг — разобраться с именованием объектов. Прочитайте раздел Именование коммитов. Существует довольно много способов задать имя объекта (и не только ревизии!). Все они обрабатываются в sha1_name.c. Просто бегло просмотрите функцию get_sha1(). Значительная часть специальной обработки выполняется такими функциями, как get_sha1_basic(), и им подобными.

Это поможет вам подготовиться к изучению наиболее глубоко перенесённой в библиотеку части Git — обходчика ревизий.

Изначально git log был shell-скриптом:

$ git-rev-list --pretty $(git-rev-parse --default HEAD "$@") | \
        LESS=-S ${PAGER:-less}

Что это значит?

git rev-list — исходная версия обходчика ревизий, которая always выводила список ревизий в stdout. Она по-прежнему работает, и так и должно быть, поскольку большинство новых команд Git сначала создаются как скрипты, использующие git rev-list.

git rev-parse больше не так важна; она использовалась только для фильтрации параметров, относящихся к разным низкоуровневым командам, которые вызывались скриптом.

Большая часть работы, выполнявшейся git rev-list, теперь находится в revision.c и revision.h. Она оборачивает параметры в структуру с именем rev_info, которая определяет, как и какие ревизии обходить, а также другие параметры.

Исходную задачу git rev-parse теперь выполняет функция setup_revisions(), которая разбирает ревизии и общие параметры командной строки для обходчика ревизий. Эти сведения сохраняются в структуре rev_info для последующего использования. После вызова setup_revisions() можно самостоятельно разбирать параметры командной строки. Затем нужно вызвать prepare_revision_walk() для инициализации, после чего получать коммиты по одному с помощью функции get_revision().

Если вас интересуют подробности процесса обхода ревизий, изучите первую реализацию cmd_log(): вызовите git show v1.3.0~155^2~4 и прокрутите до этой функции (обратите внимание, что теперь больше не нужно вызывать setup_pager() напрямую).

В наши дни git log — встроенная команда, то есть она contained в команде git. Исходный код встроенной команды включает:

Иногда в одном исходном файле содержится несколько встроенных команд. Например, cmd_show() и cmd_log() находятся в builtin/log.c, поскольку используют значительную часть общего кода. В этом случае команды, которые not называются так же, как файл .c, в котором они находятся, должны быть перечислены в BUILT_INS в Makefile.

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

И здесь самое время сделать перерыв.

Третий урок: изучайте код. В самом деле, это лучший способ узнать об устройстве Git (после того как вы усвоите основные понятия).

Подумайте о том, что вам интересно, например: «как получить доступ к блобу, зная только его имя объекта?». Сначала найдите команду Git, с помощью которой это можно сделать. В данном примере это может быть git show или git cat-file.

Для ясности остановимся на git cat-file, поскольку она

Итак, откройте builtin/cat-file.c, найдите cmd_cat_file() и посмотрите, что она делает.

        repo_config(the_repository, git_default_config);
        if (argc != 3)
                usage("git cat-file [-t|-s|-e|-p|<type>] <sha1>");
        if (get_sha1(argv[2], sha1))
                die("Not a valid object name %s", argv[2]);

Пропустим очевидные детали; единственная по-настоящему интересная часть здесь — вызов get_sha1(). Функция пытается интерпретировать argv[2] как имя объекта и, если оно указывает на объект, присутствующий в текущем репозитории, записывает полученный SHA-1 в переменную sha1.

Здесь интересны два момента:

Вы встретите оба этих случая в коде.

А теперь — самое интересное:

        case 0:
                buf = odb_read_object_peeled(r->objects, sha1, argv[1], &size, NULL);

Так читается блоб (на самом деле не только блоб, но и объект любого типа). Чтобы узнать, как именно работает функция odb_read_object_peeled(), найдите её исходный код (например, выполнив в репозитории Git команду вроде git grep read_object_with | grep ":[a-z]") и прочитайте его.

Чтобы узнать, как использовать результат, продолжайте читать cmd_cat_file():

        write_or_die(1, buf, size);

Иногда вы не знаете, где искать нужную возможность. Во многих таких случаях помогает поиск в выводе команды git log, а затем git show соответствующего коммита.

Пример: вы знаете, что для git bundle был написан тестовый пример, но не помните, где он находился (да, можно could git grep bundle t/, но это не иллюстрирует суть!):

$ git log --no-merges t/

В программе просмотра (less) просто найдите слово «bundle», прокрутите на несколько строк вверх и увидите, что оно находится в коммите 18449ab0. Теперь скопируйте это имя объекта и вставьте его в командную строку:

$ git show 18449ab0

Вот и всё.

Ещё один пример: выясним, что нужно сделать, чтобы превратить скрипт во встроенную команду:

$ git log --no-merges --diff-filter=A builtin/*.c

Как видите, Git — лучший инструмент для изучения исходного кода самого Git!

Объяснение Git

Создание нового репозитория

Из tar-архива:

$ tar xzf project.tar.gz
$ cd project
$ git init
Initialized empty Git repository in .git/
$ git add .
$ git commit

Из удалённого репозитория:

$ git clone git://example.com/pub/project.git
$ cd project

Управление ветками

$ git branch                        # list all local branches in this repo
$ git switch test                # switch working directory to branch "test"
$ git branch new                # create branch "new" starting at current HEAD
$ git branch -d new                # delete branch "new"

Чтобы создать новую ветку не от текущего HEAD (что используется по умолчанию), выполните:

$ git branch new test    # branch named "test"
$ git branch new v2.6.15 # tag named v2.6.15
$ git branch new HEAD^   # commit before the most recent
$ git branch new HEAD^^  # commit before that
$ git branch new test~10 # ten commits before tip of branch "test"

Создать новую ветку и сразу переключиться на неё:

$ git switch -c new v2.6.15

Обновить и просмотреть ветки из репозитория, который вы клонировали:

$ git fetch                # update
$ git branch -r                # list
  origin/master
  origin/next
  ...
$ git switch -c masterwork origin/master

Получить ветку из другого репозитория и присвоить ей новое имя в своём репозитории:

$ git fetch git://example.com/project.git theirbranch:mybranch
$ git fetch git://example.com/project.git v2.6.15:mybranch

Сохранить список репозиториев, с которыми вы регулярно работаете:

$ git remote add example git://example.com/project.git
$ git remote                        # list remote repositories
example
origin
$ git remote show example        # get details
* remote example
  URL: git://example.com/project.git
  Tracked remote branches
    master
    next
    ...
$ git fetch example                # update branches from example
$ git branch -r                        # list all remote branches

Изучение истории

$ gitk                            # visualize and browse history
$ git log                    # list all commits
$ git log src/                    # ...modifying src/
$ git log v2.6.15..v2.6.16  # ...in v2.6.16, not in v2.6.15
$ git log master..test            # ...in branch test, not in branch master
$ git log test..master            # ...in branch master, but not in test
$ git log test...master            # ...in one branch, not in both
$ git log -S'foo()'            # ...where difference contain "foo()"
$ git log --since="2 weeks ago"
$ git log -p                    # show patches as well
$ git show                    # most recent commit
$ git diff v2.6.15..v2.6.16 # diff between two tagged versions
$ git diff v2.6.15..HEAD    # diff with current head
$ git grep "foo()"            # search working directory for "foo()"
$ git grep "foo()" v2.6.15  # search old tree for "foo()"
$ git show v2.6.15:a.txt    # look at old version of a.txt

Поиск регрессий:

$ git bisect start
$ git bisect bad                # current version is bad
$ git bisect good v2.6.13-rc2        # last known good revision
Bisecting: 675 revisions left to test after this
                                # test here, then:
$ git bisect good                # if this revision is good, or
$ git bisect bad                # if this revision is bad.
                                # repeat until done.

Внесение изменений

Убедитесь, что Git знает, кого винить:

$ cat >>~/.gitconfig <<\EOF
[user]
        name = Your Name Comes Here
        email = you@yourdomain.example.com
EOF

Выберите содержимое файлов, которое нужно включить в следующий коммит, а затем создайте коммит:

$ git add a.txt    # updated file
$ git add b.txt    # new file
$ git rm c.txt     # old file
$ git commit

Или подготовьте изменения и создайте коммит за один шаг:

$ git commit d.txt # use latest content only of d.txt
$ git commit -a           # use latest content of all tracked files

Слияние

$ git merge test   # merge branch "test" into the current branch
$ git pull git://example.com/project.git master
                   # fetch and merge in remote branch
$ git pull . test  # equivalent to git merge test

Обмен изменениями

Импорт и экспорт исправлений:

$ git format-patch origin..HEAD # format a patch for each commit
                                # in HEAD but not in origin
$ git am mbox # import patches from the mailbox "mbox"

Получить ветку из другого репозитория Git, а затем объединить её с текущей веткой:

$ git pull git://example.com/project.git theirbranch

Перед слиянием с текущей веткой сохранить полученную ветку в локальной ветке:

$ git pull git://example.com/project.git theirbranch:mybranch

После создания коммитов в локальной ветке обновить удалённую ветку, добавив в неё свои коммиты:

$ git push ssh://example.com/project.git mybranch:theirbranch

Если удалённая и локальная ветки называются «test»:

$ git push ssh://example.com/project.git test

Краткая команда для часто используемого удалённого репозитория:

$ git remote add example ssh://example.com/project.git
$ git push example test

Обслуживание репозитория

Проверить наличие повреждений:

$ git fsck

Повторно сжать данные и удалить неиспользуемые остатки:

$ git gc

Список задач

Работа над руководством продолжается.

Основные требования:

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

Просмотреть Documentation/ и найти другие упущенные темы, в частности:

Просмотреть архивы электронной почты и найти другие упущенные темы.

Просмотреть справочные страницы и проверить, не предполагает ли какая-либо из них наличие знаний, которые не представлены в этом руководстве.

Добавить больше хороших примеров. Возможно, полезно создать целые разделы с примерами из практики; может быть, стоит сделать раздел «Дополнительные примеры» стандартным заключительным разделом каждой главы?

Добавить перекрёстные ссылки на глоссарий там, где это уместно.

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

Написать главу об использовании низкоуровневых команд и создании скриптов.

Альтернативные базы данных объектов, clone --reference и т. д.

Добавить сведения о восстановлении после повреждения репозитория. См.: https://lore.kernel.org/git/Pine.LNX.4.64.0702272039540.12485@woody.linux-foundation.org/ https://lore.kernel.org/git/Pine.LNX.4.64.0702141033400.3604@woody.linux-foundation.org/