I have been making these short (1 to 5-minute) videos covering a specific topic that I use daily or frequently. I have been posting them to my YouTube channel but they have not gained much traction over there so, I thought I would share them here along with an extended transcript.
If you like this one and want to see more, please let me know in the comments. If there is something specific you would like me to cover, same deal. 😉 👍
Let's say you opened a pull request and then reviewed your code and realized there's something that you forgot or want to change. You could make the change, add a new commit, and push to your code hosting service of choice, but now you have two commits.
While using multiple commits can be incredibly useful, I like to start my initial pull (merge) request with a single commit. This is a general practice I picked up while working at Mozilla and it has served me well.
Ok, good to know, but what do you do when you inevitably run into this scenario? In these instances, git rebase
is your friend.
After you have added your new commit, type the following in your terminal:
git rebase -i main
The -i
above will put you into interactive mode and main
is the branch against which you want to rebase. When you press enter, you will see something similar to the following:
pick 4ad8867 page: identity federation product page
pick d57c578 small prose change
# Rebase 2004347..396a1b6 onto 2004347 (2 commands)
The above will be followed with a lot of documentation concerning the command and the various options you have.
Note: Addressing all of those is not in the scope of this post, but if you would like me to cover this in more detail, let me know.
For this use case, I almost always use fixup
over the other options. The reason I use fixup
over squash
is that I only want to keep the commit message from the initial commit. That then is also the primary difference between these two options. Let's fixup
our commit history:
pick 4ad8867 page: identity federation product page
f d57c578 small prose change
# Rebase 2004347..396a1b6 onto 2004347 (2 commands)
Once you have done the above, you will be left with a single commit and only the initial commit message. Great! All that is left to do is push this to the remote repository.
If you try to do this using git push origin branch-name
, you will encounter an error message and Git will not allow you to push to the remote. This is because the above action changed the history (as mentioned above) and Git generally does not want to encourage this.
However, we are okay with having changed the history so we can use the -f
(force) flag to tell Git that we know what we are doing and to allow our push to overwrite what exists on the remote branch.
git push -f origin branch-name
With that, we now have our most recent changes on the remote branch, but still only have a single commit using our initial commit message.
I hope that you found this helpful. As mentioned earlier, if you would like more of these, have specific topics you would like me to cover, or have any other feedback, please let me know in the comments.
Top comments (16)
Thanks for the article! I am a fan of
git rebase
(I used it twice already today!) and it's good to see more people talking about it. People can be apprehensive about these git operations, but they are very powerful.I especially appreciate the insight of
fixup
vssquash
!In a case like the one you described, I often go with
git commit --amend
for these small edits, but I can definitely see the benefit to making the individual commits and having the option to make changes afterwards.Nice! Yes, I use
--amend
as well every now and again. There is a lot more to Git that I do not yet know, so I will most likely be making more of these as I learn new and practical uses of the many commands.In general, I would also love to have a deeper understanding of how Git works.
I'm an advanced git users, I use git rebase interactive daily when not hourly 😅
I appreciate you made a post about it. So people will get familiar with its usage.
Reading your post inspired me in writing an article I wanted to write for ages. So thank you.
Here it is
Amazing git additional tool to install: git-interactive rebase-tool
Christophe Colombier ・ Apr 24
Amazing! That makes my day. I am glad I could inspire you to write the above. Thanks for sharing!
Always useful, thanks for the tips !
You are very welcome! Would you be keen to see more of these? Anything specific you would like me to cover?
Yes sure, even after 15 years of development git commands still seems odd to me. I was wondering about modifying history in remote repository while using git reset, in a "security" point of view.
From your article, it seems to imply that while using git rebase, it will change the remote history as well, as you need to force it.
Let's say -a good friend- accidently committed an ENV key and pushed a commit, is there a way to reorganize history to completely remove it from .git history or could it be recover by digging or recovering traces ?
That is a good question. My knee-jerk reaction would be, if you changed history this way and force-pushed, that history is lost, but... I am also thinking mainly the commit history, not the underlying changes so there might very well still be a way to drudge that up. This is why it is important to use things like GitHub's push protection. github.blog/2023-05-09-push-protec...
I will do some digging, as "a friend" has also done this before. We had to rotate the keys so, that is why my general thinking is that that key and the related changes are still in history.
Haha, thanks for your reply ! We all got that one friend ^^
Yes, safe guards can be usefull, I'll add Github Push Protection, or well the Bitbucket equivalent, if it's available !
You do a great job including the Why you would do this along with the What you can do. Also why this might not be a good idea in some situations. Thanks for sharing your wisdom
Thank you for taking the time to write this thoughtful comment. I am glad you found value in this. 🙌 or old school o/\o
Nice tip✨✨! It will be very fan if we can have more tips about how to handle correctly git.
Thank you for your feedback. There is more coming!
It sounds like the general consensus is, "We want more of this!" 😃
Well, alrighty then ;p
Nice tip, learnt something new
That is great to hear!