"date" est un concept un peu vague dans git. Un commit aura une date d'auteur qui peut être bien dans le passé avant que quelqu'un ne tire / valide le commit dans son référentiel, aussi le commit peut être rebasé et mis à jour pour être au-dessus d'un commit apparemment plus récent.
Un commit a également une date de commit qui est mise à jour si un commit est rebasé ou modifié de quelque manière que ce soit. Ces commits sont plus susceptibles d'être dans une sorte d'ordre chronologique, mais vous êtes toujours à la merci du committer ayant l'heure correcte définie sur son ordinateur et même ainsi, un commit non modifié peut rester indéfiniment sur une branche de fonctionnalité d'un référentiel distant avant fusionné dans la branche maître d'un référentiel central.
Ce qui est probablement le plus utile à vos fins est la date de reflog sur le référentiel particulier en question. Si vous avez activé les reflogs par branche (voir git config core.logAllRefUpdates
), vous pouvez utiliser leref@{date}
syntaxe pour faire référence à l'emplacement d'une branche à un moment donné.
Par exemple
git log -p master@{2009-07-01}..master@{now}
Vous pouvez également utiliser des descriptions `` floues '' comme:
git log -p "master@{1 month ago}..master@{yesterday}"
Ces commandes afficheront tous les commits qui sont «apparus» dans la branche donnée du référentiel quel que soit leur «âge» en fonction de leur auteur et des dates de livraison.
Notez que le reflog par branche est spécifique à un référentiel, donc si vous exécutez la commande log sur un clone et que vous ne tirez pas pendant (disons) un mois, puis extrayez toutes les modifications du mois dernier en une seule fois, puis toutes les modifications du mois dernier apparaîtront dans une @{1 hour ago}..@{now}
plage. Si vous êtes en mesure d'exécuter la commande log sur le répertoire «central» vers lequel les gens poussent, alors il peut faire ce que vous voulez.