"data" è un concetto un po 'sciolto in git. Un commit avrà una data dell'autore che potrebbe essere un bel po 'di tempo nel passato prima che qualcuno effettui il pull / commit del commit nel proprio repository, inoltre il commit potrebbe essere ribasato e aggiornato per essere in cima a un commit apparentemente più recente.
Un commit ha anche una data di commit che viene aggiornata se un commit viene ribasato o modificato in qualsiasi modo. È più probabile che questi commit siano in una sorta di ordine cronologico ma sei ancora in balia del committer che ha l'ora corretta impostata sul suo computer e anche così, un commit non modificato può sedersi su un ramo di funzionalità su un repository remoto indefinitamente prima essere fusa nel ramo principale di un repository centrale.
Ciò che è probabilmente più utile per i tuoi scopi è la data di reflog sul particolare repository in questione. Se hai i reflog per ramo abilitati (vedi git config core.logAllRefUpdates
), puoi usare la ref@{date}
sintassi per fare riferimento a dove si trovava un ramo in un determinato momento.
Per esempio
git log -p master@{2009-07-01}..master@{now}
Puoi anche utilizzare descrizioni "sfocate" come:
git log -p "master@{1 month ago}..master@{yesterday}"
Questi comandi mostreranno tutti i commit che sono "apparsi" nel ramo dato del repository indipendentemente da quanto siano "vecchi" in base all'autore e alle date di commit.
Nota che il reflog per ramo è specifico di un repository, quindi se stai eseguendo il comando log su un clone e non esegui il pull per (diciamo) un mese, esegui il pull di tutte le modifiche dell'ultimo mese contemporaneamente, quindi tutte le modifiche dell'ultimo mese verranno visualizzate in un @{1 hour ago}..@{now}
intervallo. Se sei in grado di eseguire il comando log sul ripostory 'centrale' a cui le persone spingono, allora potrebbe fare quello che vuoi.