Как получить хеш для текущего коммита в Git?

Question

Как получить хеш для текущего коммита в Git?

1548

Я хотел бы сохранить (на данный момент) возможность связывать Git набор изменений с рабочими элементами, хранящимися в TFS.

Я уже написал инструмент (используя hook из Git), в котором я могу вставлять workitemidentifiers в сообщение набора изменений Git.

Однако я также хотел бы сохранить идентификатор фиксации Git (хеш) в пользовательском поле рабочего места TFS. Таким образом, я могу проверить работу в TFS и посмотреть, что Git changeets связаны с рабочим элементом.

Как я могу легко получить хэш из текущего фиксации из Git?

Sardaukar 04 июнь 2009, в 09:59

Источник

Теги:

git

tfs

tfs-workitem

changeset

19 ответов

340

Если вам нужен только сокращенный хеш:

git log --pretty=format:'%h' -n 1

Кроме того, использование% H - это еще один способ получить длинный хэш.

outofculture 01 окт. 2011, в 00:03

97

Или, кажется, добавление --short к команде rev-parse выше работает.
outofculture 30 сен. 2011, в 23:39
11

Я думаю, что git log это фарфор, а git rev-parse это сантехника.
Amedee Van Gasse 29 янв. 2016, в 10:40
0

Одним из преимуществ этого метода является то, что он возвращает короткую версию хэша с правильной длиной, скорректированной с учетом коллизий хеша, которые происходят для больших репо. По крайней мере, в последних версиях Git.
Ilia Sidorenko 22 дек. 2016, в 14:26
2

Это плохой / неправильный способ сделать это, потому что этот метод даст вам неправильный хеш, если у вас отсоединенная голова. Например, если текущий коммит 12ab34 ... а предыдущий коммит был 33aa44 ... тогда, если я сделаю 'git checkout 33aa44' и затем введу вашу команду, я все равно вернусь обратно 12ab34 ... несмотря на то, что моя голова фактически указывает до 33aa44 ...
theQuestionMan 17 июль 2017, в 00:03
1

@ theQuestionMan Я не испытываю поведение, которое вы описываете; git checkout 33aa44; git log -n 1 дает мне 33aa44 . Какую версию Git вы используете?
outofculture 19 июль 2017, в 17:32

Показать ещё 3 комментария

124

Другой, используя git log:

git log -1 --format="%H"

Он очень похож на @outofculture, хотя немного короче.

Paul Pladijs 21 нояб. 2011, в 20:23

0

И результат не в кавычках.
crokusek 28 фев. 2017, в 23:11
0

Это правильный ответ, так как он работает, даже если вы извлекаете конкретный коммит вместо HEAD .
Parsa 22 фев. 2019, в 19:16

72

Чтобы получить полный SHA:

$ git rev-parse HEAD
cbf1b9a1be984a9f61b79a05f23b19f66d533537

Чтобы получить сокращенную версию:

$ git rev-parse --short HEAD
cbf1b9a

Alexander 29 июль 2016, в 21:01

0

Если вам нужны два git commit , например один из branch вы сейчас работаете, и master branch , вы также можете использовать git rev-parse FETCH_HEAD если вам нужен хеш для master commit который вы merge d в текущую branch , Например, если у вас есть branch es master и feature/new-feature для данного репо, в то время как в feature/new-feature вы можете использовать git fetch origin master && git merge FETCH_HEAD а затем git rev-parse --short FETCH_HEAD если вам нужно хеш commit от master вы просто merge d для любых скриптов, которые вы можете иметь.
EVAL 03 сен. 2018, в 21:43

68

Для полноты, поскольку никто еще не предложил ее. .git/refs/heads/master - это файл, содержащий только одну строку: хэш последней фиксации на master. Поэтому вы можете просто прочитать его оттуда.

Или, как команда:

cat .git/refs/heads/master

Update:

Обратите внимание, что git теперь поддерживает сохранение некоторых head ref в файле pack-ref вместо файла в папке /refs/heads/. https://www.kernel.org/pub/software/scm/git/docs/git-pack-refs.html

Deestan 16 окт. 2012, в 13:02

7

Это предполагает, что текущая ветвь является master , что не обязательно верно.
gavrie 23 окт. 2012, в 15:10
11

В самом деле. Вот почему я прямо сказал, что это для master .
Deestan 23 окт. 2012, в 15:22
1

Существует .git/HEAD который является файлом, который содержит 1 строку с SHA1 из HEAD. Я думаю, это то, что вы имели в виду.
kynan 06 нояб. 2012, в 20:39
18

.git/HEAD обычно указывает на ссылку, если у вас есть SHA1 там, вы находитесь в режиме отсоединенной головы.
eckes 09 апр. 2013, в 01:48
5

Это не очень надежно по сравнению с другими подходами, в частности, потому что предполагается, что существует подкаталог .git , что не всегда так. Смотрите --separate-git-dir на странице руководства git init .
jubobs 29 дек. 2014, в 17:44
14

Because1 потому что иногда вы не хотите, чтобы был установлен исполняемый файл git (например, в вашем Dockerfile)
wim 07 апр. 2015, в 02:59
3

Для нахождения SHA-хэша ветки .git/refs/heads/<branch-name>
pushya 07 апр. 2015, в 20:12
1

+1 и, если вы не хотите обязательно извлекать / перебазировать / объединять и просто хотите получить хеш после выборки cat .git/refs/remotes/origin/master
nhed 24 май 2016, в 03:02
0

cat .git / $ (cat .git / HEAD | awk '{print $ 2;}') должен работать тогда?
logicor 26 сен. 2017, в 22:45

Показать ещё 7 комментариев

38

Там всегда git describe а также. По умолчанию это дает вам -

john@eleanor:/dev/shm/mpd/ncmpc/pkg (master)$ git describe --always
release-0.19-11-g7a68a75

John Tyree 26 авг. 2011, в 10:58

13

Git description возвращает первый TAG, доступный из коммита. Как это поможет мне получить SHA?
Sardaukar 09 сен. 2011, в 13:45
35

Мне нравится git describe --long --dirty --abbrev=10 --tags это даст мне что-то вроде 7.2.0.Final-447-g65bf4ef2d4 что составляет 447 коммитов после тэга 7.2.0.Final и первых 10 дайджестов глобального SHA-1 в текущем заголовке "65bf4ef2d4". Это очень хорошо для версий строк. При использовании параметра --long всегда добавляются счетчик (-0-) и хэш, даже если тег точно совпадает.
eckes 09 апр. 2013, в 01:46
12

Если тегов не существует, git describe --always будет «показывать однозначно сокращенный объект коммита как запасной вариант»
Ronny Andersson 18 сен. 2014, в 16:57

Показать ещё 1 комментарий

31

Фиксировать хеш

git show -s --format=%H

Сокращенный хеш фиксации

git show -s --format=%H

Нажмите здесь для более git show примеров.

ecwpz91 27 март 2017, в 21:01

26

Используйте git rev-list --max-count=1 HEAD

Robert Munteanu 04 июнь 2009, в 09:14

3

git-rev-list предназначен для генерации списка объектов коммитов; это git-rev-parse для перевода имени объекта (например, HEAD) в SHA-1
Jakub Narębski 04 июнь 2009, в 14:13

19

Если вам нужно сохранить хэш в переменной во время script, вы можете использовать

last_commit=$(git rev-parse HEAD)

Или, если вам нужны только первые 10 символов (например, github.com)

last_commit=$(git rev-parse HEAD | cut -c1-10)

Henk 15 июль 2012, в 17:57

25

Есть также параметры --short или --short=number для git rev-parse ; Не нужно использовать трубу и cut .
Julian D. 13 сен. 2012, в 18:20

13

Самый сжатый способ, который я знаю:

git show --pretty=%h

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

--abbrev=n

Brian Peterson 07 фев. 2014, в 07:17

14

Хотя это технически работает, git show - это то, что известно как фарфоровая команда (то есть обращенная к пользователю), и поэтому его не следует использовать в сценариях, поскольку его выходные данные могут быть изменены. Ответ выше ( git rev-parse --short HEAD ) следует использовать вместо этого.
jm3 15 март 2014, в 23:45
4

@ jm3 это задом наперед. «Фарфоровые» команды имеют стабильные выходные данные, предназначенные для скриптов. Поиск git help show для porcelain .
John Tyree 06 июль 2015, в 21:32
0

@JohnTyree дох, ты прав, моя ошибка.
jm3 15 авг. 2015, в 21:51
1

@JohnTyree Это запутанная тема, но jm3 был прав: команды фарфора предназначены не для анализа, а для восприятия человеком. Если вам нужно использовать фарфоровую команду в сценарии и вы хотите иметь стабильный формат, иногда (например, с git status, push и blame) есть опция, которая делает именно это. К сожалению, эта опция называется --porcelain , поэтому это сбивает с толку. Вы можете найти подробности в этом великолепном ответе VonC
Fabio Turati 14 янв. 2019, в 17:20
0

дорогой бог, который решил назвать этот вариант - фарфор, я хочу их найти и ... о, подожди, мне нужно использовать git, чтобы найти их неважно
Britton Kerin 15 март 2019, в 06:12

Показать ещё 3 комментария

11

Если вам нужен супер-хакерский способ сделать это:

cat .git/`cat .git/HEAD | cut -d \  -f 2`

В основном, git хранит расположение HEAD в .git/HEAD в форме ref: {path from .git}. Эта команда считывает это, вырезает "ref:" и считывает любой файл, на который он указал.

Это, конечно, не удастся в режиме отсоединенной головы, поскольку HEAD не будет "ref:...", но сам хеш - но вы знаете, я не думаю, что вы ожидаете, что много умений в ваш bash однострочный. Если вы не думаете, что точки с запятой обманывают, хотя...

HASH="ref: HEAD"; while [[ $HASH == ref\:* ]]; do HASH="$(cat ".git/$(echo $HASH | cut -d \  -f 2)")"; done; echo $HASH

Fordi 14 окт. 2015, в 19:48

0

не нужно устанавливать git, мне это нравится. (у моего образа сборки докера нет git)
Helin Wang 15 фев. 2016, в 20:18
0

также полезно, потому что вы можете легко запустить это из-за пределов git репо
samaspin 22 июнь 2016, в 16:30
0

Я формализовал это для сценария для моей локальной машины. Затем я подумал: эй: реализованная мною реализация достаточно проста, чтобы проиллюстрировать, как решить несвязанную проблему (синтаксический анализ аргументов в необработанных сценариях оболочки POSIX без внешних программ), но достаточно сложна, чтобы обеспечить небольшие вариации и использовать большую часть особенности sh . Спустя полчаса комментариев к документации, и вот суть : gist.github.com/Fordi/29b8d6d1ef1662b306bfc2bd99151b07
Fordi 29 июнь 2016, в 14:41
0

Глядя на это, я сделал более обширную версию для обнаружения Git и SVN и получения ревизии git hash / svn. На этот раз не чистая строка, но легко анализируемая из командной строки и используемая как тег версии: gist.github.com/Fordi/8f1828efd820181f24302b292670b14e
Fordi 29 июнь 2016, в 15:21

Показать ещё 2 комментария

11

Возможно, вам нужен псевдоним, поэтому вам не нужно запоминать все детали. После выполнения одного из следующих шагов вы сможете просто ввести:

$ git lastcommit
49c03fc679ab11534e1b4b35687b1225c365c630

Следуя принятому ответу , вот два способа установить это:

1) Научите git явным образом, отредактировав глобальную конфигурацию (мой оригинальный ответ):

 # open the git config editor
 $ git config --global --edit
 # in the alias section, add
 ...
 [alias]
   lastcommit = rev-parse HEAD
 ...

2) Или, если вам нравится ярлык, чтобы научить git ярлыку, как недавно прокомментировал Адриен:

$ git config --global alias.lastcommit "rev-parse HEAD"

В этом случае используйте git lastcommit, чтобы показать последний хэш-код фиксации.

miraculixx 09 окт. 2015, в 13:38

3

Адриен де Сентенак отмечает, что вместо того, чтобы вручную редактировать файл конфигурации git, вы можете просто сделать: git config --global alias.lastcommit "rev-parse HEAD"
cgmb 17 нояб. 2015, в 18:35
0

@ Adrien спасибо, обновил соответственно.
miraculixx 17 нояб. 2015, в 21:02

6

Мне нужно было что-то немного другое: отобразите полный sha1 коммита, но добавьте звездочку в конец, если рабочий каталог не чист. Если я не хотел использовать несколько команд, ни один из вариантов предыдущих ответов не работает.

Вот один лайнер, который делает:
git describe --always --abbrev=0 --match "NOT A TAG" --dirty="*"
Результат: f5366ccb21588c0d7a5f7d9fa1d3f85e9f9d1ffe*

Объяснение: описывает (используя аннотированные теги) текущую фиксацию, но только с тегами, содержащими "NOT A TAG". Поскольку теги не могут иметь пробелы, это никогда не совпадает с тегом, и поскольку мы хотим показать результат --always, команда возвращается с отображением полного (--abbrev=0) sha1 коммита и добавляет звездочку, если рабочий каталог --dirty.

Если вы не хотите добавлять звездочку, это работает, как и все остальные команды в предыдущих ответах:
git describe --always --abbrev=0 --match "NOT A TAG"
Результат: f5366ccb21588c0d7a5f7d9fa1d3f85e9f9d1ffe

Rado 17 фев. 2018, в 20:33

0

Спасибо, просто спотыкаюсь об этом, и это избавляет меня от того или иного эха за это :)
hakre 23 фев. 2018, в 20:43
1

Это работает для меня без --match "NOT A TAG" . Протестировано в git 2.18.0 и 2.7.4. Есть ли ситуация, когда нужен этот аргумент?
Thomas 07 авг. 2018, в 07:24
0

@ Томас это не сработает, если у вас есть аннотированный тег где-либо в истории текущего коммита. Поддельный тег гарантирует, что команда description не использует тег для описания коммита,
Rado 08 авг. 2018, в 05:44

Показать ещё 1 комментарий

5

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

(head=($(<.git/HEAD)); cat .git/${head[1]})

^{Вам нужно выполнить команду выше в вашей корневой папке git.}

Этот метод может быть полезен, если у вас есть файлы репозитория, но команда git не установлена.

Если это не сработает, .git/refs/heads папку .git/refs/heads какие главы у вас есть.

kenorb 05 окт. 2017, в 22:59

5

git show-ref --head --hash head

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

cat .git/refs/heads/<branch-name>

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

Dennis 30 апр. 2015, в 08:53

0

show-ref мне кажется лучшим вариантом для сценариев, так как это сантехническая команда и, следовательно, гарантированная (или, по крайней мере, очень вероятная) стабильность в будущих выпусках: другие ответы используют rev-parse , show , describe или log , которые все команды фарфора. А в случаях, когда скорость не имеет значения, применяется примечание на странице руководства show-ref : «Использование этой утилиты рекомендуется для прямого доступа к файлам в каталоге .git».
Pont 08 окт. 2018, в 18:21

2

в файле home-dir в файле .gitconfig добавьте следующее

[alias]
sha = rev-parse HEAD

тогда вам будет легче запомнить:

$ git sha
59fbfdbadb43ad0b6154c982c997041e9e53b600

jo_ 18 фев. 2016, в 16:19

1

Вот шаги, которые помогли мне, используя хэш коммита:

Войдите в свою ссылку на GIT HUB, например: https://github.<xyz.abc>.com
После входа в систему в текстовом поле "Искать или перейти к..." введите как:
```
hash:<GIT COMMIT HASH>
```
Выберите между "Все GitHub Enterprise" или "В этой организации" в зависимости от ваших потребностей
Нажмите Enter.

ASethi 31 янв. 2019, в 10:46

0

Кажется, что это отвечает на совершенно другой вопрос.
Edward Thomson 31 янв. 2019, в 09:50

1

Вот еще один способ сделать это с помощью:)

git log | grep -o '\w\{8,\}' | head -n 1

Marcelo Lazaroni 10 фев. 2017, в 15:14

0

Вот еще одна реализация прямого доступа:

head="$(cat ".git/HEAD")"
while [ "$head" != "${head#ref: }" ]; do
  head="$(cat ".git/${head#ref: }")"
done

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

head="$(curl -s "$baseurl/.git/HEAD")"
while [ "$head" != "${head#ref: }" ]; do
  head="$(curl -s "$baseurl/.git/${head#ref: }")"
done

Daniel Alder 04 нояб. 2016, в 14:46

Ещё вопросы

Или, кажется, добавление --short к команде rev-parse выше работает.
Я думаю, что git log это фарфор, а git rev-parse это сантехника.
Одним из преимуществ этого метода является то, что он возвращает короткую версию хэша с правильной длиной, скорректированной с учетом коллизий хеша, которые происходят для больших репо. По крайней мере, в последних версиях Git.
Это плохой / неправильный способ сделать это, потому что этот метод даст вам неправильный хеш, если у вас отсоединенная голова. Например, если текущий коммит 12ab34 ... а предыдущий коммит был 33aa44 ... тогда, если я сделаю 'git checkout 33aa44' и затем введу вашу команду, я все равно вернусь обратно 12ab34 ... несмотря на то, что моя голова фактически указывает до 33aa44 ...
@ theQuestionMan Я не испытываю поведение, которое вы описываете; git checkout 33aa44; git log -n 1 дает мне 33aa44 . Какую версию Git вы используете?
Это правильный ответ, так как он работает, даже если вы извлекаете конкретный коммит вместо HEAD .
Если вам нужны два git commit , например один из branch вы сейчас работаете, и master branch , вы также можете использовать git rev-parse FETCH_HEAD если вам нужен хеш для master commit который вы merge d в текущую branch , Например, если у вас есть branch es master и feature/new-feature для данного репо, в то время как в feature/new-feature вы можете использовать git fetch origin master && git merge FETCH_HEAD а затем git rev-parse --short FETCH_HEAD если вам нужно хеш commit от master вы просто merge d для любых скриптов, которые вы можете иметь.
Это предполагает, что текущая ветвь является master , что не обязательно верно.
В самом деле. Вот почему я прямо сказал, что это для master .
Существует .git/HEAD который является файлом, который содержит 1 строку с SHA1 из HEAD. Я думаю, это то, что вы имели в виду.
.git/HEAD обычно указывает на ссылку, если у вас есть SHA1 там, вы находитесь в режиме отсоединенной головы.
Это не очень надежно по сравнению с другими подходами, в частности, потому что предполагается, что существует подкаталог .git , что не всегда так. Смотрите --separate-git-dir на странице руководства git init .
Because1 потому что иногда вы не хотите, чтобы был установлен исполняемый файл git (например, в вашем Dockerfile)
Для нахождения SHA-хэша ветки .git/refs/heads/<branch-name>
+1 и, если вы не хотите обязательно извлекать / перебазировать / объединять и просто хотите получить хеш после выборки cat .git/refs/remotes/origin/master
cat .git / $ (cat .git / HEAD | awk '{print $ 2;}') должен работать тогда?
Git description возвращает первый TAG, доступный из коммита. Как это поможет мне получить SHA?
Мне нравится git describe --long --dirty --abbrev=10 --tags это даст мне что-то вроде 7.2.0.Final-447-g65bf4ef2d4 что составляет 447 коммитов после тэга 7.2.0.Final и первых 10 дайджестов глобального SHA-1 в текущем заголовке "65bf4ef2d4". Это очень хорошо для версий строк. При использовании параметра --long всегда добавляются счетчик (-0-) и хэш, даже если тег точно совпадает.
Если тегов не существует, git describe --always будет «показывать однозначно сокращенный объект коммита как запасной вариант»
git-rev-list предназначен для генерации списка объектов коммитов; это git-rev-parse для перевода имени объекта (например, HEAD) в SHA-1
Есть также параметры --short или --short=number для git rev-parse ; Не нужно использовать трубу и cut .
Хотя это технически работает, git show - это то, что известно как фарфоровая команда (то есть обращенная к пользователю), и поэтому его не следует использовать в сценариях, поскольку его выходные данные могут быть изменены. Ответ выше ( git rev-parse --short HEAD ) следует использовать вместо этого.
@ jm3 это задом наперед. «Фарфоровые» команды имеют стабильные выходные данные, предназначенные для скриптов. Поиск git help show для porcelain .
@JohnTyree Это запутанная тема, но jm3 был прав: команды фарфора предназначены не для анализа, а для восприятия человеком. Если вам нужно использовать фарфоровую команду в сценарии и вы хотите иметь стабильный формат, иногда (например, с git status, push и blame) есть опция, которая делает именно это. К сожалению, эта опция называется --porcelain , поэтому это сбивает с толку. Вы можете найти подробности в этом великолепном ответе VonC
дорогой бог, который решил назвать этот вариант - фарфор, я хочу их найти и ... о, подожди, мне нужно использовать git, чтобы найти их неважно
не нужно устанавливать git, мне это нравится. (у моего образа сборки докера нет git)
также полезно, потому что вы можете легко запустить это из-за пределов git репо
Я формализовал это для сценария для моей локальной машины. Затем я подумал: эй: реализованная мною реализация достаточно проста, чтобы проиллюстрировать, как решить несвязанную проблему (синтаксический анализ аргументов в необработанных сценариях оболочки POSIX без внешних программ), но достаточно сложна, чтобы обеспечить небольшие вариации и использовать большую часть особенности sh . Спустя полчаса комментариев к документации, и вот суть : gist.github.com/Fordi/29b8d6d1ef1662b306bfc2bd99151b07
Глядя на это, я сделал более обширную версию для обнаружения Git и SVN и получения ревизии git hash / svn. На этот раз не чистая строка, но легко анализируемая из командной строки и используемая как тег версии: gist.github.com/Fordi/8f1828efd820181f24302b292670b14e
Адриен де Сентенак отмечает, что вместо того, чтобы вручную редактировать файл конфигурации git, вы можете просто сделать: git config --global alias.lastcommit "rev-parse HEAD"
@ Adrien спасибо, обновил соответственно.
Спасибо, просто спотыкаюсь об этом, и это избавляет меня от того или иного эха за это :)
Это работает для меня без --match "NOT A TAG" . Протестировано в git 2.18.0 и 2.7.4. Есть ли ситуация, когда нужен этот аргумент?
@ Томас это не сработает, если у вас есть аннотированный тег где-либо в истории текущего коммита. Поддельный тег гарантирует, что команда description не использует тег для описания коммита,
show-ref мне кажется лучшим вариантом для сценариев, так как это сантехническая команда и, следовательно, гарантированная (или, по крайней мере, очень вероятная) стабильность в будущих выпусках: другие ответы используют rev-parse , show , describe или log , которые все команды фарфора. А в случаях, когда скорость не имеет значения, применяется примечание на странице руководства show-ref : «Использование этой утилиты рекомендуется для прямого доступа к файлам в каталоге .git».
Кажется, что это отвечает на совершенно другой вопрос.

Jakub Narębski · Accepted Answer · 2009-06-04T09-10-00.000Z

2156

Лучший ответ

Чтобы превратить произвольную ссылку на расширенный объект в SHA-1, используйте просто git-rev-parse, например

git rev-parse HEAD

или

git rev-parse --verify HEAD

Sidenote: Если вы хотите повернуть ссылки (ветки и теги) в SHA-1, есть git show-ref и git for-each-ref.

Jakub Narębski 04 июнь 2009, в 09:10

67

--verify подразумевает, что: The parameter given must be usable as a single, valid object name. Otherwise barf and abort.
Linus Unnebäck 24 июль 2011, в 17:50
564

git rev-parse --short HEAD возвращает короткую версию хэша, на случай, если кому-то интересно.
Thane Brimhall 25 окт. 2012, в 21:28
47

--short , вы также можете добавить определенную длину в --short , например --short=12 , чтобы получить определенное количество цифр из хеша.
Tyson Phalp 21 фев. 2014, в 17:18
26

@TysonPhalp: --short=N - это минимальное количество цифр; git использует большее количество цифр, если укороченная будет неотличима от другой укороченной фиксации. Попробуйте, например, git rev-parse --short=2 HEAD или git log --oneline --abbrev=2 .
Jakub Narębski 21 фев. 2014, в 18:08
31

В дополнение к тому, что сказали Тэйн, Тайсон и Якуб, вы можете напечатать полный хеш, но выделите гекситы, необходимые для идентификации синего коммита, с помощью git rev-parse HEAD | GREP_COLORS='ms=34;1' grep $(git rev-parse --short=0 HEAD)
Zaz 05 авг. 2014, в 16:44
0

Аккуратный трюк Zaz. Кажется, он не работает с grep на моем Mac, но я заменил ack на аналогичный эффект!
XP84 24 июль 2015, в 15:14
7

@Zaz Это тоже не сработало для меня, но просто git rev-parse HEAD | grep --color $(git rev-parse --short=0 HEAD) делает.
Theodore Murdock 31 дек. 2015, в 01:47
0

Есть ли способ сделать это, но для каждого каталога? Например, допустим, я хочу последний хеш определенного каталога. Нужно ли делать git log <directory> и анализировать его, чтобы получить хеш?
Aaron 10 май 2016, в 18:23
0

@ Аарон: грубо говоря, да, вам нужно запустить git log <options> -- <directory> ; но вы можете настроить git-log, чтобы он возвращал только хэш.
Jakub Narębski 10 май 2016, в 23:53
4

В дополнение к сказанному @ThaneBrimhall, вы можете получить полную ссылку на SHA-1 из короткой версии хэша, используя git rev-parse ca003ae .
Halil 24 май 2016, в 13:14
0

Работает ли этот способ, если у вас есть тег с именем "HEAD"? > :)
Sap 03 авг. 2016, в 06:49
0

@EdRandall: главная цель git rev-parse - проанализировать параметры и вернуть ревизии, поэтому --short означает сокращенный SHA-1 ревизии. git log возвращает дополнительную информацию, в том числе SHA-1 ревизий, которая может быть сокращена до --abbrev или --abbrev-commit .
Jakub Narębski 07 сен. 2016, в 14:23
0

git rev-parse HEAD | pbcopy подходит для быстрого буфера обмена на Mac
Kirk Strobeck 07 сен. 2017, в 00:17
0

Здорово! Я даже добавил его к псевдониму: git config --global alias.sha 'rev-parse HEAD' . Теперь я могу просто использовать git sha .
milkovsky 11 янв. 2018, в 15:50
0

Это ответ не всегда правильный! Если ГОЛОВА не находится на вашем коммите проверки (отдельная голова), то что вы получите обратно неверно. Только git status даст вам правильный хеш коммита.
sschueller 05 июнь 2018, в 14:28

Показать ещё 13 комментариев