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>разрешается путём выбора первого соответствия в следующих правилах:-
Если
$GIT_DIR/<refname>существует, это то, что вы имеете в виду (это обычно полезно только дляHEAD,FETCH_HEAD,ORIG_HEAD,MERGE_HEAD,REBASE_HEAD,REVERT_HEAD,CHERRY_PICK_HEAD,BISECT_HEADиAUTO_MERGE); -
в противном случае,
refs/<refname>, если оно существует; -
в противном случае,
refs/tags/<refname>, если оно существует; -
в противном случае,
refs/heads/<refname>, если оно существует; -
в противном случае,
refs/remotes/<refname>, если оно существует; -
в противном случае,
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 См. также
gitrevisions
© 2005–2026 Linus Torvalds and others
Licensed under the GNU General Public License version 2.
https://git-scm.com/docs/gitrevisions