„Date” to trochę luźna koncepcja w gicie. Zatwierdzenie będzie miało datę autora, która może znajdować się w przeszłości, zanim ktoś faktycznie pobierze / zatwierdzi zatwierdzenie do swojego repozytorium, również zatwierdzenie może zostać zmienione i zaktualizowane, aby znajdowało się na szczycie pozornie nowszego zatwierdzenia.
Zatwierdzenie ma również datę zatwierdzenia, która jest aktualizowana, jeśli zatwierdzenie zostanie zmienione lub w jakikolwiek sposób zmienione. Te zatwierdzenia są bardziej prawdopodobne w jakiejś kolejności chronologicznej, ale nadal jesteś na łasce osoby zatwierdzającej, która ma właściwy czas ustawiony na swoim komputerze, a mimo to niezmodyfikowane zatwierdzenie może siedzieć w gałęzi funkcji w zdalnym repozytorium przez czas nieokreślony scalane z główną gałęzią centralnego repozytorium.
To, co jest prawdopodobnie najbardziej przydatne do twoich celów, to data reflogu w określonym repozytorium. Jeśli masz włączone reflogs dla poszczególnych gałęzi (zobacz git config core.logAllRefUpdates
), możesz użyć ref@{date}
składni, aby odnieść się do miejsca, w którym gałąź była w określonym czasie.
Na przykład
git log -p master@{2009-07-01}..master@{now}
Możesz także użyć „rozmytych” opisów, takich jak:
git log -p "master@{1 month ago}..master@{yesterday}"
Te polecenia pokażą wszystkie zatwierdzenia, które „pojawiły się” w danej gałęzi repozytorium, niezależnie od tego, jak są „stare” według ich autora i dat wprowadzenia.
Zwróć uwagę, że reflog dla poszczególnych gałęzi jest specyficzny dla repozytorium, więc jeśli uruchamiasz polecenie dziennika na klonie i nie ściągasz przez (powiedzmy) miesiąc, a następnie pobierz wszystkie zmiany z ostatniego miesiąca naraz wtedy wszystkie zmiany z ostatniego miesiąca pojawią się w @{1 hour ago}..@{now}
zakresie. Jeśli jesteś w stanie uruchomić polecenie log w „centralnym” repozytorium, do którego ludzie naciskają, może to zrobić, co chcesz.