safetylobi.blogg.se - Edit git commit message

#Edit git commit message code

Now, let's see what happens if we fix the typo using -amend.

Here's a history containing three commits, two of which are already published remotely ( C0 + C1) and one ( C2) yet to be published notice the spelling mistake in the message of the unpublished commit. I'll be addressing amending a commit from its most general use case, that is making changes to the last commit just created (even though it's technically possible to amend any commit in your history). Let's answer the question by looking at two examples. The question was: If I amend a commit by changing its commit message only (and nothing else), does that make it immutable? To put it in more general terms: Does amending a commit change its hash? Even if it's only the commit message that changes.

#Edit git commit message code

4 min read Photo by Markus Spiske / Unsplashįollowing my previous post describing how every commit in Git is an immutable snapshot of your entire code base – which cannot be altered or tampered with – I got an interesting question from a friend of mine (who also happens to be a developer).

You might want to look at whether a different solution - like notes or annotated tags - would meet your needs instead. So, if this somehow still sounds worth the trouble, the correct procedure isġ) Coordinate a cut-over with all other users of the repoĢ) Follow a procedure similar to Edmundo's, but probably with the modifications I've suggested above force push because it clears the error, just like you did - then the history will once again have the original A with the original commit message you wanted to do away with. the way that causes them the last headache - i.e. If you haven't carefully coordinated with your coworkers, they'll find out about needing to rebase their work through a somewhat cryptic error message, and if they react to that the "wrong" way - i.e.

As soon as you do that, any work anyone else has added after D or F (either on the respective branch, or on a new branch) will have to be rebased onto your work as well. To fix that, you'll have to force-push both master and branch1. Of course re-parenting is still history rewriting, so now what you get is x - x - A - B - C - D <-(origin/master) Now if you really want to do this, cherry-picking is actually the hard way you'd be better off at this point re-parenting B from A to A' using filter-branch. Notice that your branches still "see" the original commit (with the original message) in their histories, which is why Edmundo says you'll then be doing some cherry-picking. You check out A and run the commit -amend, and now you have x - x - A - B - C - D <-(master) So you follow Edmundo's advice (which is, after all, closer to correct than anyone else's). For example, if you have x - x - A - B - C - D <-(master)Īnd you want to rewrite the commit message for A.

And every ref that points at any one of them will have to be rewritten. This doesn't mean you can never do it it means that you should have the agreement of everyone who uses the branch in question before you do it.Īnd in the case you specify - where not only the commit to be modified but also some subsequent commits have been pushed - those commits are going to need to be replaced as well. (See "recovering from upstream rebase" in the git rebase documentation.) You can replace a commit with a new commit that is identical except for having a new message, but if in doing so you remove a commit that has been pushed, every other user of the repo will have to recover because you have just performed an effective upstream rebase. There is no mechanism for editing the message of a commit. (If you have the use the -f or -force options, then git is trying to warn you of something.) That is why, in Edmundo's procedure, you end up having to do a bunch of nonsense cherry-picking and forced operations. The commit message is a fundamental part of the commit identity. But nobody seems to want to tell you the real score. And you have a couple answers giving you procedures that you'll think worked great, until your coworkers start complaining. So you have one answer that tells you how you would do it if the commit weren't pushed (ignoring that you specifically said it has been pushed).