In general it is not great practice to rewrite history, the git log exists for a reason and rebasing in particular (which rewrites commits) might cause issues if other developers are relying on those commits. In this case you might want to also change the branch name, again if it makes sense. In my example my branch name didn't include a ticket number, sometimes they do. When done check your git log again and you should see updated commits with the correct messages, also referencing the original commit.Īssuming this branch is already in an upstream, which for me it was, you will need to force push over this branch to completely rewrite the history using git push -f.Ĭongratulations! You have now successfully updated all the commit messages on your feature branch. Save and close the file and repeat the process for every commit. Very similarly to our initial rebase file we can now edit the commit message here, replace the incorrect ticket number. ![]() The longer the branch the longer this will take, sorry. Once you close the initial rebase file you will be prompted with a new file for each commit on your branch. I am using nano so I can save and close the file. Depending on your text editor the process for this might be different. You can see that we have changed the word pick to reword for each commit as they all contain the wrong ticket number. You will not change the commit message here just the command, changing the message comes later. Below is what it looks like once we have changed this file. We still want to use this commit but we definitely want to change that commit message. You will notice that one of the options below is reword or r for short. We are now prompted with the history of the commits on our branch as well as some instructions on what we can do in interactive mode to change our previous commits. Now that we have our commit hash we can start an interactive rebase that not only replays our commits it lets us choose how we want to handle each commit. Much like a visual git tool git log can be a little cumbersome if your feature branch or parent branch are long, however the following command gives us a very similar analogue to our visual tool. Naturally the longer your branch the harder this might be. Using a visual git tool provides you with a good overview of how your branches look in relation to the rest of the repository and can be easily scanned to find the parent commit. In context of our example this is what it looks like. For a feature branching strategy where that should be one commit (and not some hypothetical commit based off a multi-branch merge) this yields the fastest results. The merge-base command attempts to find the base commit of the supplied branches. There are a few ways to do this and I will show them in my preferred order. ![]() We first want to find the parent commit for this branch, given we are attempting to do it in-place. So how can we rebase this branch in-place and also re-write all of our commit history? However there might be cases (other than pride) where doing an in-place rebase is useful. ![]() Normally I would suggest that best practice would be to just rebase the branch off your current parent as preserving the commit it branched from isn't super useful. To fix this particular mistake we are going to take advantage of the rebase command. Whoops! We were actually working on "Ticket Number 234", not only do I look silly but we might also break integrations with other work tracking tools, we might want to try and fix this ASAP. In this example we have "Ticket Number 123" appended to the start of the commits in the form. As a result we might be in a state similar to below. For brevity I've commited directly to the main branch but I suggest in real world scenarios you have branch policies that prevent this behaviour. We start working away while others continue to merge work into our trunk. Let's assume we have a repository that uses trunk based development and some sort of feature branching strategy. You try and fix your mistake of course! Learning is always fun and git is surprisingly hard to break so let's see how we can fix the problem. That's fine, but what happens if you are new at a company, taking on a little too much information at once, and typo one of your first ticket numbers, only to realise as you go to submit a Pull Request? For traceability of past work it is often common to use a ticket (or some other reference) number in commit messages. Some have strict adherence to commit message formats, while others are more lax. Many organisations approach their git commit standards differently. This post may (or may not) have been inspired by starting at a new job and not wanting my peers to know I completely misread one of my first programming tickets. It's not common but sometimes we have uses for rewriting our git history.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |