Предположим, у меня есть ветвь my-topic-branch, разветвленная от моей локальной ветки master, и эта ветвь master связана с удаленной веткой master.
Ветвь my-topic-branch была первоначально созданный из тега с именем tag1. tag1 - это тег, наложенный на удаленную главную ветвь, и я вижу этот тег как результат git fetch.
Некоторое время проходит, чтобы другие могли перенести свои изменения в эту удаленную главную ветвь. И еще позже новый tag2 устанавливается кем-то другим (см. Обновление 6 ниже по причинам для этого).
Затем я снова использую git fetch, чтобы убедиться, что У меня есть все эти удаленные теги в моем локальном репо для дальнейших операций.
Я перехожу на этот tag2, например:
$ git rebase tag2
First, rewinding head to replay your work on top of it...
Applying: CENSORED_LOG_MESSAGE1
Applying: CENSORED_LOG_MESSAGE2
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
Но затем я запускаю git status и вижу это :
$ git status
On branch my-topic-branch
Your branch is ahead of 'tag1' by 195 commits.
(use "git push" to publish your local commits)
Я ожидаю, что вышеупомянутое сообщение должно что-то сказать о tag2, и уж точно не о том, что я опередил старый тег на 195 коммитов.
Почему бы git status сообщить о коммите, с которого разветвился my-topic-branch, а не о новом коммите, на который я в основном недавно перебазировал?
Если это ожидаемое поведение, тогда хорошо, мне просто придется его игнорировать, но это Странно видеть, что я все еще отстаю master от 195 коммитов, когда это определенно не соответствует действительности (если git rebase действительно сделал то, что, как я думаю, должно).
Обновление 1
Я все еще могу найти базовую точку my-topic-branch, если HEAD все еще находится в этой ветви, через:
* 1 044 *
Но все же возникает вопрос о выводе git status.
Обновление 2:
Обновление в ответ на комментарий Pesho_T :
Я побежал git branch -vv и получил следующее. Это подвергается цензуре, но с добавлением чисел, таких как «2» и «4», чтобы отличать их от других, указанных выше:
$ git branch -vv | grep my-topic-branch
* my-topic-branch CENSORED_SHA1_TAG1 [tag1: ahead 195] MDFCOR-420 CENSORED_LOG_MESSAGE_TAG1
Обновление 3:
Воспроизведение некоторых команд в Ответ Торека , я вижу:
$ git rev-parse --abbrev-ref @{u}
tag1
$ git rev-parse --symbolic-full-name @{u}
refs/tags/tag1
В настоящее время, из очень хорошей рецензии Торека, я заключаю, что tag1 действительно является тегом, а не ветвью.
Обновление 4:
Я отредактировал предыдущие CENSORED_SHA1, чтобы они были согласованными:
- CENSORED_SHA1_TAG1 - это коммит SHA1, соответствующий тегу 1
- CENSORED_SHA1_TAG2, это коммит SHA1, соответствующий тегу 2
1077 * Обновление 5:
Еще одно обновление в ответ на ответ Торека :
The upstream of a branch is always another branch name or remote-tracking name, as tag names are forbidden
Я не уверен в этом из-за этого эксперимента:
$ git rev-list --count --left-right my-topic-branch...my-topic-branch@{upstream}
195 0
$ git show -s $(git rev-parse my-topic-branch@{u})
commit CENSORED_SHA1_TAG1 (tag: tag1)
Author: CENSORED_AUTHOR
Date: CENSORED_DATE
CENSORED_LOG_MESSAGE_TAG1
Выше показано, что восходящий поток указывает на тег.
Чтобы подтвердить, что оба эти тега tag1 и tag2 находятся в главной ветви, я сделал это, согласно подсказкам, найденным в ответ на Git: Как узнать, на какой ветке находится тег? : * 10 92 *
$ git branch -a --contains $(git rev-parse tag1^{commit}) | grep -E 'my-topic-branch|master'
* my-topic-branch
master
$
Обновление 6:
В мои планы не входит git push возврат к метке (tag2), по которой я запускал git rebase. Я использую этот тег только как точку на ветви master, чтобы перебазировать my-topic-branch в. tag2 - это известная точка в ветви master, на которой приложение должным образом строится (я не могу go более подробно рассказать об этом по конфиденциальным причинам). Я ожидаю продолжения git rebase для последующих тегов, tag3, tag4 и т. Д. До тех пор, пока my-topic-branch не будет готов к производству, после чего я объединю его с моей локальной веткой master и выполню git push оттуда.
Обновление 7
Я опубликовал ответ MCVE , чтобы показать, как изменяется восходящий поток, показанный git status, после того, как восходящий поток установлен на родительском ветвь ветки topi c, таким образом, поддерживая комментарии Торека, показанные в ней. Я все еще рассматриваю ответ Торека как ответ на этот вопрос, потому что без его участия я бы не понял его.