git должен иметь возможность идентифицировать коммит во время ряда общих операций
Существует несколько способов определить коммит. Вы можете использовать ветку, тэг, коммит sha1 или выражения. Например:
git log HEAD
HEAD в конечном итоге преобразуется в конкретный коммит, и вам будет выдан журнал для этого. Вы также можете сказать:
git log master
master - это ветвь, которая также преобразуется в конкретный коммит.
git log fd72e9c99312
Теперь это фактический коммит.
<ч />
Следующая документация - это то, что вы ищете. Взято из документации команды git-rev-parse в http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html.
уточняющие пересмотренные варианты
Параметр ревизии обычно, но не обязательно, именует объект фиксации. Они используют так называемый расширенный синтаксис SHA1. Вот различные способы написания имен объектов. Те, что перечислены в конце этого списка, должны давать имена деревьям и BLOB-объектам, содержащимся в коммите.
Полное имя объекта SHA1 (40-байтовая шестнадцатеричная строка) или его подстрока, которая является уникальной в хранилище. Например. dae86e1950b1277e545cee180551750029cfe735 и dae86e оба называют один и тот же объект фиксации, если в вашем хранилище нет другого объекта, имя которого начинается с dae86e.
Вывод из git-description; т. е. ближайший тег, за которым может следовать тире и количество коммитов, за которыми следуют тире, g и сокращенное имя объекта.
Символическое имя ссылки. Например. master обычно означает объект фиксации, на который ссылается $ GIT_DIR / refs /head / master. Если у вас есть и заголовки / мастер, и теги / мастер, вы можете явно сказать, главы / мастер, чтобы сказать git, какой из них вы имеете в виду. Когда неоднозначно, а устраняется неоднозначность, принимая первое совпадение в следующих правилах:
если существует $ GIT_DIR /, это то, что вы имеете в виду (обычно это полезно только для HEAD, FETCH_HEAD, ORIG_HEAD и MERGE_HEAD);
в противном случае, $ GIT_DIR / refs /, если существует;
в противном случае, $ GIT_DIR / refs / tags /, если существует;
в противном случае, $ GIT_DIR / refs /head /, если существует;
в противном случае, $ GIT_DIR / refs / remotes /, если существует;
в противном случае, $ GIT_DIR / refs / remotes // HEAD, если существует.
HEAD называет коммит, на котором основаны ваши изменения в рабочем дереве. FETCH_HEAD записывает ветку, которую вы извлекли из удаленного репозитория с вашим последним вызовом git-fetch. ORIG_HEAD создается командами, которые резко перемещают ваш HEAD, чтобы записать положение HEAD перед их работой, чтобы вы могли изменить кончик ветви обратно в состояние до того, как вы легко запустили их. MERGE_HEAD записывает коммиты, которые вы объединяете в ветке, когда запускаете git-merge.
Ссылка, за которой следует суффикс @ с указанием даты, заключенной в пару скобок (например, {вчера}, {1 месяц 2 недели 3 дня 1 час 1 секунда назад} или {1979-02-26 18:30:00) }) чтобы указать значение ссылки в предыдущий момент времени. Этот суффикс может использоваться только сразу после имени ссылки, и ссылка должна иметь существующий журнал ($ GIT_DIR / logs /). Обратите внимание, что это ищет состояние вашего местного реф в данный момент; например, что было в вашем местном главном филиале на прошлой неделе. Если вы хотите посмотреть коммиты, сделанные в определенные моменты времени, посмотрите --since и --until.
Ссылка, за которой следует суффикс @ с порядковым номером, заключенным в пару скобок (например, {1}, {15}), для указания n-го предшествующего значения этой ссылки. Например, master @ {1} является непосредственным предшествующим значением master, а master @ {5} является 5-м предшествующим значением master. Этот суффикс может использоваться только сразу после имени ссылки, и ссылка должна иметь существующий журнал ($ GIT_DIR / logs /).
Вы можете использовать конструкцию @ с пустой частью ref, чтобы получить reflog текущей ветви. Например, если вы находитесь на ветке blabla, то @ {1} означает то же самое, что и blabla@ndom1goti.
.
Специальная конструкция @ {-} означает, что ветвь th была проверена раньше текущей.
Суффикс ^ к параметру ревизии означает первого родителя этого объекта фиксации. ^ означает th-го родителя (т. е. rev ^ эквивалентен rev ^ 1). Как специальное правило, rev ^ 0 означает сам коммит и используется, когда rev является именем объекта тега, который ссылается на объект фиксации.
Суффикс ~ к параметру ревизии означает объект фиксации, который является прародителем поколения поименованного объекта фиксации, следуя только за первым родителем. То есть rev ~ 3 эквивалентен rev ^^^, что эквивалентно rev ^ 1 ^ 1 ^ 1. Ниже приведена иллюстрация использования этой формы.
Суффикс ^, за которым следует имя типа объекта, заключенное в пару фигурных скобок (например, v0.99.8 ^ {commit}), означает, что объект может быть тегом, и рекурсивно разыменовывает тег до тех пор, пока не будет найден объект этого типа или объект больше не может быть разыменовано (в этом случае, barf). rev ^ 0, представленный ранее, является сокращением для rev ^ {commit}.
Суффикс ^, за которым следует пустая пара скобок (например, v0.99.8 ^ {}), означает, что объект может быть тегом, и рекурсивно разыменовывает тег до тех пор, пока не будет найден объект без тега.
Двоеточие, за которым следует косая черта, за которым следует текст: это имя коммита, сообщение о коммите которого начинается с указанного текста. Это имя возвращает самый молодой соответствующий коммит, который доступен из любой ссылки. Если сообщение фиксации начинается с!, Вы должны повторить это; специальная последовательность: / !, за которой следует нечто иное, чем! сейчас зарезервировано.
Суффикс: следуют пути; это имя большого двоичного объекта или дерева по заданному пути в объекте tree-ish, названном частью перед двоеточием.
Двоеточие, за которым может следовать номер этапа (от 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 = 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