"data" é um conceito um pouco solto no git. Um commit terá uma data de autor que pode ser algum tempo no passado antes de alguém realmente puxar / submeter o commit em seu repositório, também o commit pode ser rebaseado e atualizado para estar no topo de um commit aparentemente mais recente.
Um commit também tem uma data de commit que é atualizada se um commit for rebatizado ou alterado de alguma forma. É mais provável que esses commits estejam em algum tipo de ordem cronológica, mas você ainda está à mercê do committer com a hora correta definida em seu computador e, mesmo assim, um commit não modificado pode ficar em um branch de recurso em um repositório remoto indefinidamente antes sendo mesclado no branch master de um repositório central.
O que provavelmente é mais útil para seus propósitos é a data de reflog no repositório particular em questão. Se você tiver reflogs por branch habilitado (consulte Recursos git config core.logAllRefUpdates
), então você pode usar a ref@{date}
sintaxe para se referir a onde um branch estava em um determinado momento.
Por exemplo
git log -p master@{2009-07-01}..master@{now}
Você também pode usar descrições 'difusas' como:
git log -p "master@{1 month ago}..master@{yesterday}"
Esses comandos mostrarão todos os commits que 'apareceram' em um determinado ramo do repositório, independentemente de quão 'antigos' eles realmente são de acordo com seu autor e datas de commit.
Observe que o reflog por ramo é específico para um repositório, portanto, se você estiver executando o comando log em um clone e não puxar por (digamos) um mês, extraia todas as alterações do último mês de uma vez, então, todas as alterações do último mês aparecerão em um @{1 hour ago}..@{now}
intervalo. Se você for capaz de executar o comando log no repositório 'central' para o qual as pessoas enviam, então ele pode fazer o que você quiser.