Spec-Zone.ru › Git

gitrevisions

Имя

gitrevisions - Указание ревизий и диапазонов для Git

Синтаксис

gitrevisions

Описание

Многие команды Git принимают параметры ревизий в качестве аргументов. В зависимости от команды, они обозначают конкретный коммит или, для команд, которые обходят график ревизий (таких как git-log[1]), все коммиты, достижимые из этого коммита. Для команд, которые обходят график ревизий, можно также явно указать диапазон ревизий.

Кроме того, некоторые команды Git (например, git-show[1] и git-push[1]) также могут принимать параметры ревизий, которые обозначают другие объекты, чем коммиты, например, объекты blobs ("файлы") или деревья ("каталоги файлов").

Указание ревизий

Параметр ревизии <rev> обычно, но не обязательно, называет объект коммита. Он использует так называемый синтаксис extended SHA-1. Вот различные способы записи имён объектов. Объекты деревьев и блобов, содержащихся в коммите, указаны в конце списка.

Примечание
Этот документ показывает "сырой" синтаксис, как его видит git. Оболочка и другие интерфейсы могут потребовать дополнительных кавычек для защиты специальных символов и предотвращения разделения слов.
<sha1>, e.g. dae86e1950b1277e545cee180551750029cfe735, dae86e

Полное имя объекта SHA-1 (40-символьная шестнадцатеричная строка) или его уникальная подстрока в репозитории. Например, dae86e1950b1277e545cee180551750029cfe735 и dae86e обозначают один и тот же объект коммита, если в репозитории нет другого объекта, имя которого начинается с dae86e.

<describeOutput>, e.g. v1.7.4.2-679-g3bee7fb

Вывод из git describe; т.е. ближайшая метка, необязательно с последующим тире и количеством коммитов, тире, g, и укороченным именем объекта.

<refname>, e.g. master, heads/master, refs/heads/master

Символическое имя ссылки. Например, master обычно означает объект коммита, на который ссылается refs/heads/master. Если у вас есть и heads/master, и tags/master, вы можете явно указать heads/master, чтобы Git понял, о каком из них идёт речь. В случае неоднозначности <refname> разрешается путём выбора первого соответствия в следующих правилах:

  1. Если $GIT_DIR/<refname> существует, это то, что вы имеете в виду (это обычно полезно только для HEAD, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD, REBASE_HEAD, REVERT_HEAD, CHERRY_PICK_HEAD, BISECT_HEAD и AUTO_MERGE);

  2. в противном случае, refs/<refname>, если оно существует;

  3. в противном случае, refs/tags/<refname>, если оно существует;

  4. в противном случае, refs/heads/<refname>, если оно существует;

  5. в противном случае, refs/remotes/<refname>, если оно существует;

  6. в противном случае, refs/remotes/<refname>/HEAD, если оно существует.

    HEAD

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

    FETCH_HEAD

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

    ORIG_HEAD

    создаётся командами, которые существенно перемещают вашу HEAD (git am, git merge, git rebase, git reset), чтобы записать позицию HEAD до их выполнения, позволяя легко вернуть вершину ветви в состояние до их запуска.

    MERGE_HEAD

    записывает коммит(ы), которые вы объединяете с вашей ветвью при запуске git merge.

    REBASE_HEAD

    во время слияния, записывает коммит, на котором операция в данный момент приостановлена, либо из-за конфликтов, либо из-за команды edit в интерактивном слиянии.

    REVERT_HEAD

    записывает коммит, который вы отменяете при запуске git revert.

    CHERRY_PICK_HEAD

    записывает коммит, который вы выбираете при запуске git cherry-pick.

    BISECT_HEAD

    записывает текущий коммит, который нужно проверить при запуске git bisect --no-checkout.

    AUTO_MERGE

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

Обратите внимание, что любой из вышеперечисленных refs/* случаев может быть получен из директории $GIT_DIR/refs или из файла $GIT_DIR/packed-refs. Хотя кодировка имён ссылок не специфицирована, предпочтительно UTF-8, так как некоторые операции по обработке вывода предполагают использование UTF-8 для имён ссылок.

@

@ в одиночку является сокращением для HEAD.

[<refname>]@{<date>}, e.g. master@{yesterday}, HEAD@{5 minutes ago}

Ссылка, за которой следует постфикс @ со спецификацией даты в фигурных скобках (например, {yesterday}, {1 month 2 weeks 3 days 1 hour 1 second ago} или {1979-02-26 18:30:00}), указывает значение ссылки в предыдущий момент времени. Этот постфикс может использоваться только сразу после имени ссылки, и ссылка должна иметь существующий журнал ($GIT_DIR/logs/<ref>). Обратите внимание, что это ищет состояние вашей локальной ссылки в заданное время; например, какое было в вашей локальной ветви master на прошлой неделе. Если вам нужно просмотреть коммиты, созданные в определённые временные промежутки, см. --since и --until.

<refname>@{<n>}, e.g. master@{1}

Ссылка, за которой следует постфикс @ со спецификацией порядкового номера в фигурных скобках (например, {1}, {15}). Например, master@{1} — это предыдущее значение master, а master@{5} — пятое предыдущее значение master. Этот постфикс может использоваться только сразу после имени ссылки, и ссылка должна иметь существующий журнал ($GIT_DIR/logs/<refname>).

@{<n>}, e.g. @{1}

Конструкцию @ с пустой частью имени ссылки можно использовать для получения записи журнала текущей ветви. Например, если вы находитесь на ветви blabla, то @{1} означает то же самое, что и blabla@{1}.

@{-<n>}, e.g. @{-1}

Конструкция @{-<n>} означает <n>-ую ветвь/коммит, проверенную до текущей.

[<branchname>]@{upstream}, e.g. master@{upstream}, @{u}

Ветвь B может быть настроена для работы над ветвью X (настроенной с branch.<name>.merge в удалённом репозитории R (настроенной с branch.<name>.remote). B@{u} относится к удалённой ветви отслеживания для ветви X, взятой из удалённого репозитория R, обычно находящейся по адресу refs/remotes/R/X.

[<branchname>]@{push}, e.g. master@{push}, @{push}

Постфикс @{push} отображает ветвь "куда мы будем делать push", если git push был запущен, когда была выбрана ветвь branchname (или текущая HEAD , если имя ветви не указано). Как и в случае с @{upstream}, мы отображаем ветвь удалённого отслеживания, соответствующую этой ветви в удалённом репозитории.

Вот пример для большей ясности:

$ git config push.default current
$ git config remote.pushdefault myfork
$ git switch -c mybranch origin/master

$ git rev-parse --symbolic-full-name @{upstream}
refs/remotes/origin/master

$ git rev-parse --symbolic-full-name @{push}
refs/remotes/myfork/mybranch

Обратите внимание в примере, что мы создали треугольную схему работы, где получаем данные из одного места, а отправляем в другое. В нетреугольной схеме работы @{push} равно @{upstream}, и в ней нет необходимости.

Этот постфикс также принимается в верхнем регистре и означает то же самое независимо от регистра.

<rev>^[<n>], e.g. HEAD^, v1.5.1^0

Постфикс ^ к параметру пересмотра означает первого родителя объекта коммита. ^<n> означает <n>-го родителя (т.е. <rev>^ эквивалентно <rev>^1). Как особое правило, <rev>^0 означает сам коммит и используется, когда <rev> — имя объекта тега, который ссылается на объект коммита.

<rev>~[<n>], e.g. HEAD~, master~3

Постфикс ~ к параметру пересмотра означает первого родителя объекта коммита. Постфикс ~<n> к параметру пересмотра означает объект коммита, который является <n>-ым предком указанного объекта коммита, следуя только первым родителям. То есть <rev>~3 эквивалентно <rev>^^^, что эквивалентно <rev>^1^1^1. См. ниже пример использования этой формы.

<rev>^{<type>}, e.g. v0.99.8^{commit}

Постфикс ^ с именем типа объекта в фигурных скобках означает рекурсивное разыменование объекта в <rev> до тех пор, пока не будет найден объект типа <type> или объект больше не может быть разыменён (в этом случае, ошибка). Например, если <rev> — это объект коммита, <rev>^{commit} описывает соответствующий объект коммита. Аналогично, если <rev> — это объект дерева, <rev>^{tree} описывает соответствующий объект дерева. <rev>^0 — это сокращение для <rev>^{commit}.

<rev>^{object} можно использовать для проверки того, что <rev> называет существующий объект, без требования к <rev> быть тегом и без разыменования <rev>; так как тег уже является объектом, он не должен разыменовываться даже один раз, чтобы получить объект.

<rev>^{tag} можно использовать для проверки того, что <rev> идентифицирует существующий объект тега.

<rev>^{}, e.g. v0.99.8^{}

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

<rev>^{/<text>}, например, HEAD^{/fix nasty bug}

Суффикс ^ к параметру пересмотра, за которым следует пара фигурных скобок, содержащая текст, предваряемый косой чертой, эквивалентен синтаксису :/fix nasty bug ниже, за исключением того, что он возвращает самую последнюю соответствующую коммитацию, которая доступна от <rev> до ^.

:/<text>, например, :/fix nasty bug

Двоеточие, за которым следуют косые черты и текст, задаёт коммитацию, сообщение которой соответствует указанному регулярному выражению. Это имя возвращает самую последнюю соответствующую коммитацию, доступную от любого ref, включая HEAD. Регулярное выражение может соответствовать любой части сообщения о коммитации. Для соответствия сообщениям, начинающимся с строки, можно использовать, например, :/^foo. Специальная последовательность :/! зарезервирована для модификаторов того, что соответствует. :/!-foo выполняет отрицательное соответствие, а :/!!foo соответствует литеральному ! символу, за которым следует foo. Любая другая последовательность, начинающаяся с :/!, зарезервирована на данный момент. В зависимости от заданного текста, правила разделения слов оболочки могут потребовать дополнительной кавычки.

<rev>:<path>, например, HEAD:README, master:./README

Суффикс :, за которым следует путь, задаёт объект blob или tree по указанному пути в объекте tree-ish, названном частью перед двоеточием. Путь, начинающийся с ./ или ../ относительный к текущей рабочей директории. Указанный путь будет преобразован для относительности к корневой директории рабочей области. Это наиболее полезно для обращения к blob или tree из коммита или дерева, имеющего ту же структуру дерева, что и рабочая область.

:[<n>:]<path>, например, :0:README, :README

Двоеточие, необязательно за которым следует номер стадии (от 0 до 3) и двоеточие, за которыми следует путь, задаёт объект blob в индексе по указанному пути. Отсутствие номера стадии (и двоеточия, которое следует за ним) задаёт запись стадии 0. Во время слияния стадия 1 — это общий предок, стадия 2 — версия целевой ветви (обычно текущая ветвь), а стадия 3 — версия из ветви, которая сливается.

Вот иллюстрация, предоставленная Джоном Лоэлигером. Оба узла коммитов B и C являются родителями узла коммита A. Родительские коммиты упорядочены слева направо.

G   H   I   J
 \ /     \ /
  D   E   F
   \  |  / \
    \ | /   |
     \|/    |
      B     C
       \   /
        \ /
         A
A =      = A^0
B = A^   = A^1     = A~1
C =      = A^2
D = A^^  = A^1^1   = A~2
E = B^2  = A^^2
F = B^3  = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2  = B^^2    = A^^^2  = A~2^2
I = F^   = B^3^    = A^^3^
J = F^2  = B^3^2   = A^^3^2

Указание диапазонов

Команды перемещения по истории, такие как git log, работают с набором коммитов, а не только с одним коммитом.

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

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

Множество коммитов, доступных от коммита, включает сам коммит и коммиты в цепочке предков.

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

Исключения коммитов

Обозначение ^<rev> (восклицательный знак)

Для исключения коммитов, доступных от коммита, используется обозначение префикса ^. Например, ^r1 r2 означает коммиты, доступные от r2, но исключает те, которые доступны от r1 (т.е. r1 и его предков).

Точечные обозначения диапазона

Обозначение диапазона .. (двоеточие)

Операция набора ^r1 r2 встречается так часто, что для нее есть сокращение. Когда у вас есть два коммита r1 и r2 (названные в соответствии с синтаксисом, объясненным выше в разделе УКАЗАНИЕ ПЕРЕСМОТРОВ), вы можете запросить коммиты, доступные от r2, исключая те, что доступны от r1 по ^r1 r2, и это может быть записано как r1..r2.

Обозначение симметрической разности ... (три точки)

Аналогичное обозначение r1...r2 называется симметрической разностью r1 и r2 и определяется как r1 r2 --not $(git merge-base --all r1 r2). Это набор коммитов, доступных либо от одного из r1 (левое значение) или r2 (правое значение), но не от обоих.

В этих двух сокращенных обозначениях можно опустить один конец и сделать его по умолчанию равным HEAD. Например, origin.. является сокращением для origin..HEAD и спрашивает "Что я сделал с тех пор, как отделился от ветви происхождения?" Аналогично, ..origin является сокращением для HEAD..origin и спрашивает "Что сделала ветвь происхождения с тех пор, как я отделился от нее?" Обратите внимание, что .. означало бы HEAD..HEAD, что является пустым диапазоном, который является одновременно доступным и недоступным от HEAD.

Команды, которые специально разработаны для работы с двумя различными диапазонами (например, "git range-diff R1 R2" для сравнения двух диапазонов), существуют, но они являются исключениями. Если не указано иное, все команды "git", которые работают с набором коммитов, работают с одним диапазоном пересмотров. Другими словами, запись двух "обозначений диапазона с двумя точками" рядом, например:

$ git log A..B C..D

для большинства команд не задаёт два диапазона пересмотров. Вместо этого он назначает один связанный набор коммитов, т.е. те, которые доступны либо от B или D, но не доступны ни от A или C. В линейной истории, подобной этой:

---A---B---o---o---C---D

поскольку A и B доступны от C, диапазон пересмотров, заданный этими двумя диапазонами с точками, составляет один коммит D.

Другие сокращения для обозначений родительских пересмотров

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

Обозначение r1^@ означает всех родителей r1.

Обозначение r1^! включает коммит r1, но исключает всех его родителей. Само по себе это обозначение обозначает один коммит r1.

Обозначение <rev>^-[<n>] включает <rev>, но исключает <n>-ый родитель (т.е. сокращение для <rev>^<n>..<rev>), при <n> = 1, если не указано иначе. Это обычно полезно для коммитов слияния, когда вы можете просто передать <commit>^- чтобы получить все коммиты в ветви, которая была слита в коммит слияния <commit> (включая сам <commit>).

Хотя <rev>^<n> относилось к указанию единственного родительского коммита, эти три обозначения также учитывают его родителей. Например, вы можете сказать HEAD^2^@, но вы не можете сказать HEAD^@^2.

Резюме диапазона пересмотров

<rev>

Включить коммиты, доступные от <rev> (т.е. <rev> и его предки).

^<rev>

Исключить коммиты, доступные от <rev> (т.е. <rev> и его предки).

<rev1>..<rev2>

Включить коммиты, доступные от <rev2>, но исключить те, которые доступны от <rev1>. Если <rev1> или <rev2> опущены, по умолчанию они равны HEAD.

<rev1>...<rev2>

Включить коммиты, доступные либо от <rev1>, либо от <rev2>, но исключить те, которые доступны от обоих. Если <rev1> или <rev2> опущены, по умолчанию они равны HEAD.

<rev>^@, например, HEAD^@

Суффикс ^, за которым следует знак "@" — это то же самое, что и перечисление всех родителей <rev> (то есть, включать все, доступные от его родителей, но не сам коммит).

<rev>^!, например, HEAD^!

Суффикс ^, за которым следует восклицательный знак, эквивалентен заданию коммита <rev> и всех его родителей с префиксом ^ для их исключения (и их предков).

<rev>^-<n>, например, HEAD^-, HEAD^-2

Эквивалентно <rev>^<n>..<rev>, при <n> = 1, если не указано иное.

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

   Args   Expanded arguments    Selected commits
   D                            G H D
   D F                          G H I J D F
   ^G D                         H D
   ^D B                         E I J F B
   ^D B C                       E I J F B C
   C                            I J F C
   B..C   = ^B C                C
   B...C  = B ^F C              G H D E B C
   B^-    = B^..B
          = ^B^1 B              E I J F B
   C^@    = C^1
          = F                   I J F
   B^@    = B^1 B^2 B^3
          = D E F               D G H E F I J
   C^!    = C ^C^@
          = C ^C^1
          = C ^F                C
   B^!    = B ^B^@
          = B ^B^1 ^B^2 ^B^3
          = B ^D ^E ^F          B
   F^! D  = F ^I ^J D           G H D F

См. также

git-rev-parse[1]

gitrevisions

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

Spec-Zone.ru

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