Если вы имеете в виду, что хотите иметь возможность читать некоторые выходные данные, чтобы вы, как пользователь, знали, что будет делать git checkout -
, тогда вы можете сделать
git reflog
и он обычно скажет вам правильную вещь. Он покажет HEAD
reflog, с выводом вроде
c5d4ede HEAD@{0}: checkout: moving from master to branch
38c594f HEAD@{1}: checkout: moving from branch to master
c5d4ede HEAD@{2}: checkout: moving from
c5d4ede3ffa2633bd7b8b0f19a100832a3b3ac86 to branch
c5d4ede HEAD@{3}: checkout: moving from master to HEAD^
38c594f HEAD@{4}: commit: 2
c5d4ede HEAD@{5}: commit (initial): 1
Вы можете видеть, что HEAD@{1}
- это то, что было в последний раз извлечено, сокращенный хэш для фиксации - 38c594f
, и на основании описания должно быть, что master
был извлечен.
Однако есть одна маленькая проблема. В этом случае вывод не показывает, переместился ли master
с тех пор, как вы включили master
. Существует не так много способов, но если вам нужно быть уверенным, а рефлог HEAD
показывает, что ветка будет проверена, то вы должны выполнить
git reflog master
чтобы увидеть, где сейчас находится * 1022; потому что git checkout -
будет извлекать ветвь, а не конкретную фиксацию, в этой ситуации.
(В случае, если HEAD@{1}
показывает, что вы были в отключенном состоянии, вам не нужно беспокоиться о возможных перемещениях веток, и вы знали бы, что chekcout -
приведет вас к коммиту, указанному в журнале. )
Если вы хотите что-то для сценария, это более сложная проблема. Вы можете получить идентификатор коммита, с которым вы были
git rev-parse HEAD@{1}
Но знать, в какой ветке вы находитесь, не так просто (потому что коммит может иметь ноль, одну или несколько веток, указывающих на него), и не зная, в какой ветке вы были, вы не можете знать, могла ли ветвь переехали.
Кажется, что git
способен понять это при выполнении checkout
, но что касается "как", мы достигли грани моих знаний. Очевидный ответ - использовать reflog, но я не вижу ничего, что выглядит достаточно структурированным в файлах reflog, чтобы это было правильно.