«дата» - это немного странная концепция в git. У коммита будет дата автора, которая может пройти довольно давно, прежде чем кто-то на самом деле извлечет / зафиксирует коммит в своем репозитории, также коммит может быть перебазирован и обновлен, чтобы быть поверх явно нового коммита.
У коммита также есть дата коммита, которая обновляется, если коммит перебазирован или изменен каким-либо образом. Скорее всего, эти коммиты будут в каком-то хронологическом порядке, но вы все еще находитесь во власти коммиттера, у которого на компьютере установлено правильное время, и даже в этом случае неизмененный коммит может находиться в ветви функций в удаленном репозитории бесконечно долго объединяется с основной ветвью центрального хранилища.
Что, вероятно, наиболее полезно для ваших целей, это дата reflog для конкретного репозитория. Если у вас включены повторные журналы для каждой ветви (см. git config core.logAllRefUpdates
), то вы можете использовать синтаксис ref@{date}
, чтобы указать, где была ветвь в определенное время.
1009 * Е.Г. *
git log -p master@{2009-07-01}..master@{now}
Вы также можете использовать «нечеткие» описания, такие как:
git log -p "master@{1 month ago}..master@{yesterday}"
Эти команды покажут все коммиты, которые «появились» в данной ветке хранилища, независимо от того, насколько «старыми» они являются в соответствии с их автором и датами коммитов.
Обратите внимание, что reflog для каждой ветви специфичен для репозитория, поэтому, если вы запускаете команду log на клоне и не тянете (скажем) месяц, то извлекаете все изменения за последний месяц сразу все изменения за последний месяц появятся в диапазоне @{1 hour ago}..@{now}
. Если вы можете запустить команду log в «центральном» репозитории, куда люди отправляют файлы, тогда он может делать то, что вы хотите.