Что делает git ls-remote, так это вызывает другой Git - тот, который находится по URL, который вы видите выше, - и спрашивает его о его ссылках: HEAD, названиях ветвей, именах тегов и так далее. Но единственной информацией, которую он отправляет, являются эти имена и хэш-идентификаторы.
Как я отмечал в комментариях выше, каждый коммит - представлен хеш-идентификатором, который является своего рода истинным значением коммитаname - содержит две метки времени. 1 Чтобы получить одну или обе метки времени, вы должны иметь commit . Таким образом, это означает, что git ls-remote в общем случае недостаточно: у вас могут не быть коммитов, чьи хеш-идентификаторы вы получаете от другого Git.
Сначала вам нужно запустить git fetch, который начинается так же: он вызывает какой-то другой Git и получает от него список их ветвей, тегов и т. д., а также хэш-идентификаторы, которые представляют каждое из этих имен. Затем для их веток ваш Git создаст или обновит ваши имена для удаленного отслеживания: их master станет вашим origin/master, например. Их develop становится вашим origin/develop. Какие бы у них ни были имена - refs/heads/* - полная форма - ваш Git создает или обновляет ваше собственное соответствующее refs/remotes/origin/* имя. Но прежде чем ваш Git сможет это сделать, ваш Git должен также получить сами коммиты, поэтому для любых их коммитов, которых у вас нет, которые нужны вашему Git, ваш Git получает их.
Возможно, вы захотитедобавьте --prune (для краткости git fetch -p), чтобы ваш собственный Git удалил любое имя удаленного отслеживания, которое у вас есть, которое больше не соответствует ветви в их Git. Если вы этого не сделаете, вы будете сохранять устаревшие имена для удаленного отслеживания навсегда (или до тех пор, пока вы не удалите их явно). Это на самом деле не вредно столько, сколько беспорядок-у.
Теперь у вас есть все их коммиты, плюс ваши собственные коммиты, которые вы не отправили. У вас также есть все их имена , измененные на ваши имена для удаленного отслеживания.
Вы можете просматривать эти ветви с помощью git branch -r. Порядок сортировки по умолчанию для git branch - алфавитно-внутри-групповой. 2 Но вы можете указать параметр --sort=key: 3
git branch -r --sort=authordate
или:
git branch -r --sort=committerdate
, который будет сортировать на основе соответствующей метки времени, сохраненной в коммите, на который указывает каждое имя для удаленного отслеживания.
Следовательно:
git fetch -p
git branch -r --sort=committerdate
должно получитьВы, что вы хотите (если вы не хотите, чтобы дата автора; см. сноску 1).
(Кроме того: мне нравится настраивать fetch.prune до true в моей конфигурации для каждого пользователя, так что все выборки действуют как git fetch --prune всегда.)
1 Две временные метки: авторская метка времени и метка времени коммиттера . Во многих случаях оба имеют одинаковую дату и время в любом случае. Новый коммит в целом получает то же самое, и затем, если вы копируете коммит в новый и улучшенный, с помощью git commit --amend или git rebase или любым другим способом, который может это сделать, новый и улучшенный коммит имеетинформация об авторе старого коммита, а вы и сейчас как информация коммиттера.
2 Технически, это скорее ASCII-betic или UTF-8-betic, чем буквенный: цифраперед заглавными, а заглавные перед строчными.
3 Ваш git branch должен быть достаточно новым, чтобы иметь опцию --sort, которая была введена в git branch в Git 2.7,Если ваш Git старше, попробуйте использовать git for-each-ref.