Para modificar o conteudo do ultimo commit, adicionando novo conteudo, mas sem t · kht

Para modificar o conteudo do ultimo commit, adicionando novo conteudo, mas sem ter que criar um novo commit:
git commit --amend --no-edit

Só um detalhe importante: git commit --amend sempre cria um novo commit (ok, quase sempre, mais detalhes abaixo).

Inclusive, isso está descrito na documentação oficial:

--amend

Replace the tip of the current branch by creating a new commit.

Dá pra confirmar com um teste rápido. Suponha que meu commit mais recente é esse:

$ git log --format=fuller -1
commit cc5079bdfbefa1e465caaeeb3ea4cec79922afba (HEAD -> test)
Author:     Fulano <[email protected]>
AuthorDate: 2024-10-21 14:10:58
Commit:     Fulano <[email protected]>
CommitDate: 2024-10-21 14:10:58

    teste

^{Usei o formato fuller para que ele mostre o CommitDate, em breve entenderemos o motivo.}

Em seguida rodei git commit --amend --no-edit, e podemos ver que ele criou outro commit:

$ git log --format=fuller -1
commit 9f4cc75088848b36783b8affd7cb02324dc4d77d (HEAD -> test)
Author:     Fulano <[email protected]>
AuthorDate: 2024-10-21 14:10:58
Commit:     Fulano <[email protected]>
CommitDate: 2024-10-21 14:12:01

    teste

Repare que o hash mudou de cc5079bdfbefa1e465caaeeb3ea4cec79922afba para 9f4cc75088848b36783b8affd7cb02324dc4d77d, ou seja, é outro commit. Isso porque, se qualquer informação do commit mudar, então o hash também muda, e portanto é outro commit. E neste caso a informação que mudou é o CommitDate (embora o AuthorDate continue igual - entenda a diferença aqui).

Ou seja, embora tenha o mesmo comentário, mesmo autor, mesmo conteúdo, etc; como uma das informações mudou, então foi criado outro commit. Portanto fique atento caso vc vá fazer amend em um commit que já foi enviado para o repositório remoto (ou seja, ele já foi enviado em um git push). Isso é inclusive citado no livro oficial:

You need to be careful with this technique because amending changes the SHA-1 of the commit. It’s like a very small rebase — don’t amend your last commit if you’ve already pushed it.

Eu disse anteriormente que --amend quase sempre cria um novo commit. O único caso em que ele não criaria um novo commit é se todas as informações forem iguais.

E tecnicamente é possível fazer o amend usando as mesmas datas.

Por exemplo, se eu tiver este commit:

$ git log --format=fuller -1
commit 430b1d3a14b8b80aaeadabbd2e645c0699f38f71 (HEAD -> test)
Author:     Fulano <[email protected]>
AuthorDate: 2024-10-21 14:22:05
Commit:     Fulano <[email protected]>
CommitDate: 2024-10-21 14:22:05

    teste

E rodar o comando usando as mesmas datas (assumindo que não fiz nenhuma outra alteração):

GIT_COMMITTER_DATE="2024-10-21 14:22:05" git commit --amend --no-edit --date="2024-10-21 14:22:05"

No fim terei "o mesmo commit", ou seja, git log --format=fuller -1 mostrará exatamente o mesmo commit com as mesmas datas.

Lembrando que isso só valerá se eu não mudar nenhuma das outras informações (como a mensagem de commit, author, alterações feitas, etc). Mas como na prática é raro as pessoas se preocuparem em manter a mesma data (e o git log por padrão só mostra o AuthorDate, que não é alterado com o amend, ou seja, dará a impressão que "é o mesmo commit, já que tem a mesma data"), então faz sentido trabalhar com a premissa de que sempre será gerado um novo commit.

Mas se ele cria um novo commit, o que acontece com o anterior? Bem, ele fica "perdido" (o nome técnico é "dangling commit"). Mas vc não precisa se preocupar com ele, pois uma hora o Git irá limpá-lo automaticamente.