Il y a des façons de changer le message engage plus tard:Modifier la validation racine dans Git?
git commit --amend # for the most recent commit
git rebase --interactive master~2 # but requires *parent*
Comment pouvez-vous changer le message de validation de la première commit (qui n'a pas de parent)?
En supposant que vous avez un arbre de travail propre, vous pouvez faire ce qui suit.
# checkout the root commit
git checkout <sha1-of-root>
# amend the commit
git commit --amend
# rebase all the other commits in master onto the amended root
git rebase --onto HEAD HEAD master
Je crois que cela devrait être 'git rebase - head
@Andrew: Dans cet exemple 'HEAD' _is_ le commit racine modifié. –
À droite, mais vous voulez que la racine _original_ s'engage pour le
Vous pouvez utiliser git filter-branch:
cd test
git init
touch initial
git add -A
git commit -m "Initial commit"
touch a
git add -A
git commit -m "a"
touch b
git add -A
git commit -m "b"
git log
-->
8e6b49e... b
945e92a... a
72fc158... Initial commit
git filter-branch --msg-filter \
"sed \"s|^Initial commit|New initial commit|g\"" -- --all
git log
-->
c5988ea... b
e0331fd... a
51995f1... New initial commit
J'utilise filter-branch change l'auteur/committer, et l'option '- --all' est en effet la clé dans ce cas pour pouvoir aussi gérer le commit racine . – sschuberth
de la version Git 1.7.12, vous pouvez maintenant utiliser
git rebase -i --root
Pour développer ecdpalma's answer, vous pouvez maintenant utiliser l'option --root pour dire rebase que vous voulez réécrire la racine/premier commit:
git rebase --interactive --root
Ensuite commit racine apparaîtra dans la liste TODO rebase, et vous pouvez choisir de modifier ou reformuler:
reword <root commit sha> <original message>
pick <other commit sha> <message>
...
Voici l'explication de --root de the Git rebase docs (Souligné par):
Rebase tout engage accessible à partir
<branch>, au lieu de les limiter à un<upstream>. Ceci vous permet de rebaser la (les) validation (s) racine (s) sur une branche.
Une autre façon d'éviter ce problème si vous savez que vous serez rebasage au-dessus du commit « première » à l'avenir, est de faire un vide commettras au début:
git commit --allow-empty -m "Initial commit"
et seulement alors commencer à faire de "réels" commits, alors vous pouvez facilement rebaser en plus de ce commit la manière standard en utilisant sth comme git rebase -i HEAD^
Cela ne signifie-t-il pas que, pour que cela fonctionne, vous devez avoir la prévoyance (ou être psychique) de faire un commit vide * dès le début de votre projet *? Cela semble être *** extrêmement situationnel ***, pour moi, et *** généralement pas pratique ***. Qu'est-ce que tu penses? Que se passe-t-il si j'ai déjà effectué 100 validations et que j'ai soudainement besoin de modifier la validation racine? Cela fonctionnera-t-il toujours, dans ce cas, si je n'ai pas fait ce commit vide au début? –
Modifier le message de la racine n'est probablement pas quelque chose que vous feriez après en avoir 100. Il m'arrive parfois de vouloir juste faire un dépôt de git, de faire des commissaires trash, sachant qu'une fois que j'aurai atteint un état utilisable, je les écraserais par exemple, et reformulerais le message. De toute façon, maintenant j'ai changé d'avis et je pense que la chose la plus utile pour le premier commit serait de mettre le fichier '.gitattributes' au lieu de faire un commit vide. –
Voir aussi http://stackoverflow.com/questions/11987914/how-do-i-reword -le-premier-premier-git-commit-message – fork0
En particulier: l'utilisation de la variable d'environnement GIT_COMMIT dans le script de 'g filter-branch --msg-filter' – fork0