Let’s say that the third from last commit is the one we want to edit. We’ll need to know how many commits back we need to go (relative to the HEAD, or current commit). To edit our past commits we have to do an interactive rebase. The git rebase command has two modes: manual and interactive. It can make it simpler to locate and fix bugs too as it’s less likely you’ll need to wade through irrelevant commits. It can make it much quicker and easier to look back and see the chunks of work that was done on a project or feature, which is useful if you’re reviewing a team’s code contributions. But keeping a clean Git history has advantages. You might think it’s great to have a linear timeline where everything that has ever happened is recorded and set in stone. If you’ve watched the Netflix series Russian Doll, perhaps you can see how different timeline can operate in parallel! Let’s look at how this great and terrible superpower can be useful. Our past, present and future will be like that commit never existed at all. That is to say, we can go back, change (or remove) a commit and it’s like it never happened. Time is no longer linear – rebasing takes us into the world of the multiverse. Rebasing opens up some other dimensions for us. Merging an upstream master branch into your feature branch results in a large commit in the feature branch Rebasing moves the base of your feature branch along to include the new commits from the master branch With rebasing, we insert the extra commits from the master branch into our timeline, so it looks like they were there all along. You could use git pull or git merge, but this would result in a single (potentially very large) commit being tacked onto your branch’s history at the point you pull those changes. If you’ve based your current feature branch off of the master branch and the master branch has since moved on because of other contributions, then you can perform a rebase to ensure you have the latest changes from master on your current branch. ![]() Rebasing is the process of moving the base of your branch upstream. Pretty cool! A linear Git history Rebasing With every commit you’re adding some more steps to the timeline – so if something goes wrong, you haven’t lost all that great work you did. If you commit some bad code you can always go back in time to before it happened. If we’re working in a team we might have lots of people working on their own separate timelines ( Git branches), and sometimes their timelines might converge with our own ( merging), but time is basically linear. We can move backwards and forwards on our timeline by checking out different commits. Using Git is a bit like having access to our own time machine. We’ll need to use the rebase command – but first, let’s try to understand a little bit about it. You could also make changes to your last commit (such as adding or removing files) without changing the commit message: git add README.mdīut what if you’ve already pushed your commit, or even if it’s a few commits back? Happily, there’s a fairly straightforward way to edit your past commit messages – assuming you know which commit the one you want to edit is. Git commit -amend -m "Edited commit message" Here of code we’re adding the file README.md and removing the file wrong-file.md, then editing the commit message: git add README.md You can also add or remove files by making those changes before executing the amend command. Then edit your commit message, save the commit, and push your code to the repository. If you run this with the -m flag, you can edit your commit message in the terminal at the same time: git commit -amend -m "Edited commit message" If the commit you want to change is the very last one you made, and the commit hasn’t been pushed yet, then amending it is very simple. ![]() Let’s look at a few ways to do just that. ![]() ![]() We can change the commit message, or add or remove files if we need to. With Git, there are ways we can go back and edit our past commits. What if you need to do more than just edit a commit message? There are plenty of times I’ve accidentally included the wrong file in a commit, or else missed one change and had to push an extra commit to rectify it. Either way, bad commit messages are no good to anyone – you never know when you might need to check out a commit, and hunting through past commits for an elusive chunk of code can be a nightmare. Have you ever pushed some code with a bad commit message and wished you could go back in time and edit it? Perhaps you got two different commits mixed up, or maybe your commit message was insufficiently descriptive.
0 Comments
Leave a Reply. |