Thursday, March 28, 2024
HomeCSSAmending Your Previous Commits with Git

Amending Your Previous Commits with Git


Have you ever ever pushed some code with a foul commit message and wished you could possibly return in time and edit it? Maybe you bought two totally different commits combined up, or perhaps your commit message was insufficiently descriptive. Both manner, unhealthy commit messages aren’t any good to anybody – you by no means know whenever you may want to take a look at a commit, and searching by previous commits for an elusive chunk of code is usually a nightmare. Your future self received’t thanks for it!

What if that you must do extra than simply edit a commit message? There are many instances I’ve by chance included the fallacious file in a commit, or else missed one change and needed to push an additional decide to rectify it.

With Git, there are methods we will return and edit our previous commits. We are able to change the commit message, or add or take away recordsdata if we have to. Let’s have a look at just a few methods to just do that.

Amending your final commit

If the commit you need to change is the final one you made, and the commit hasn’t been pushed but, then amending it is vitally easy. Simply sort:

git commit --amend

For those who run this with the -m flag, you’ll be able to edit your commit message within the terminal on the identical time:

git commit --amend -m "Edited commit message"

Then edit your commit message, save the commit, and push your code to the repository. You can even add or take away recordsdata by making these adjustments earlier than executing the amend command. Right here of code we’re including the file README.md and eradicating the file wrong-file.md, then enhancing the commit message:

git add README.md
git rm wrong-file.md
git commit --amend -m "Edited commit message"

You could possibly additionally make adjustments to your final commit (corresponding to including or eradicating recordsdata) with out altering the commit message:

git add README.md
git rm bad-file.md
git commit --amend --no-edit

Amending older commits

However what if you happen to’ve already pushed your commit, or even when it’s just a few commits again? Fortunately, there’s a reasonably easy technique to edit your previous commit messages – assuming you realize which commit the one you need to edit is. We’ll want to make use of the rebase command – however first, let’s attempt to perceive a little bit bit about it.

Travelling by time

Utilizing Git is a bit like gaining access to our personal time machine. We are able to transfer backwards and forwards on our timeline by testing totally different commits. If we’re working in a staff we’d have plenty of individuals engaged on their very own separate timelines (Git branches), and generally their timelines may converge with our personal (merging), however time is principally linear. For those who commit some unhealthy code you’ll be able to at all times return in time to earlier than it occurred. With each commit you’re including some extra steps to the timeline – so if one thing goes fallacious, you haven’t misplaced all that nice work you probably did. Fairly cool!

Illustration showing a git master branch in the centre with two other branches merging in a linear fashion
A linear Git historical past

Rebasing

Rebasing is the method of shifting the bottom of your department upstream. For those who’ve primarily based your present function department off of the grasp department and the grasp department has since moved on due to different contributions, then you’ll be able to carry out a rebase to make sure you have the most recent adjustments from grasp in your present department. You might use git pull or git merge, however this may lead to a single (doubtlessly very giant) commit being tacked onto your department’s historical past on the level you pull these adjustments. With rebasing, we insert the additional commits from the grasp department into our timeline, so it seems to be like they had been there all alongside.

Illustration showing the master branch being merged into the feature branch
Merging an upstream grasp department into your function department ends in a big commit within the function department
Illustration showing the feature branch being rebased from master
Rebasing strikes the bottom of your function department alongside to incorporate the brand new commits from the grasp department

Rebasing opens up another dimensions for us. Time is not linear – rebasing takes us into the world of the multiverse. We are able to truly change historical past. That’s to say, we will return, change (or take away) a commit and it’s prefer it by no means occurred. Our previous, current and future shall be like that commit by no means existed in any respect. For those who’ve watched the Netflix sequence Russian Doll, maybe you’ll be able to see how totally different timeline can function in parallel! Let’s have a look at how this nice and horrible superpower could be helpful.

Conserving a clear historical past

You may assume it’s nice to have a linear timeline the place all the things that has ever occurred is recorded and set in stone. However conserving a clear Git historical past has benefits. It could make it a lot faster and simpler to look again and see the chunks of labor that was achieved on a mission or function, which is beneficial if you happen to’re reviewing a staff’s code contributions. It could make it less complicated to find and repair bugs too because it’s much less seemingly you’ll have to wade by irrelevant commits.

Enhancing the timeline

The git rebase command has two modes: handbook and interactive. To edit our previous commits now we have to do an interactive rebase. We’ll have to know what number of commits again we have to go (relative to the HEAD, or present commit). Let’s say that the third from final commit is the one we need to edit. Sort the next into your terminal:

git rebase -i HEAD~3

This can deliver up a listing of the final three commits. For instance:

decide cd16d77 Including .gitignore
decide 67c91dc Including README.md
decide 1ba6af9 Eradicating unneccessary imports

Alternatively, if you realize the commit ID, you could possibly goal that as a substitute:

git rebase -i cd16d77

You’ll discover every commit has the phrase decide subsequent to it. We have to change this to reword. Use the i key as a shortcut for insert mode, which can enable us to edit the textual content. Then you’ll be able to change the precise textual content of the commit message alongside it.

If you wish to change not solely the commit message, however the content material of the commit itself, you should use edit as a substitute of reword. You’ll discover there are another choices too, together with drop to take away a commit completely. (These even have their quick instructions: d for drop, r for reword, and many others.)

One you’re completely satisfied together with your commit, hit escape to exit insert mode, then sort :wq to exit the Git editor.

For those who haven’t but pushed your unhealthy commit, then we don’t have to do something additional. In any other case, we’ll have to drive push. If, like me, you’re a bit petrified of Git, then force-pushing is simply in regards to the scariest factor you are able to do. You’re re-writing Git historical past. However lets face our fears collectively!

First, a caveat: force-pushing is barely one thing you need to do by yourself department. For those who drive push to a shared department then you definitely’re rewriting the historical past for different individuals too, and so they should resolve this regionally, doubtlessly inflicting huge complications. (For this reason it’s a extremely good thought to work on separate branches!). For those who’re completely satisfied that no-one else goes to be affected then you’ll be able to go forward and run:

git push --force

When rebasing the HEAD will robotically be reset to the most recent commit, so we’re achieved – we’ll have already got essentially the most up-to-date model of our mission to proceed engaged on.

So there you go, we’ve rewritten historical past and the world didn’t finish! For those who’re fascinated by studying extra, Atlassian has some nice tutorials, together with this one about rebasing and rewriting historical past.

I’m attempting to be taught extra about Git and would love to listen to your suggestions! In case you have one thing to share, please let me know on Twitter @CSSInRealLife.

I made a small repository that I’m utilizing to mess around with Git whereas I’m studying, that additionally features a handful of instructions and explanations, which I’m including to over time. Be at liberty to fork it and use it to your personal Git practise (e.g. by including recordsdata to the playground listing), or create a pull request you probably have some helpful issues so as to add!



RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Most Popular

Recent Comments