DEV Community

Cover image for How do you use git rebase? Let's go through one use case
Schalk Neethling
Schalk Neethling

Posted on

How do you use git rebase? Let's go through one use case

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
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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 (14)

Collapse
 
oculus42 profile image
Samuel Rouse

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 vs squash!

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.

Collapse
 
schalkneethling profile image
Schalk Neethling

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.

Collapse
 
ccoveille profile image
Christophe Colombier • Edited

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

Collapse
 
schalkneethling profile image
Schalk Neethling

Amazing! That makes my day. I am glad I could inspire you to write the above. Thanks for sharing!

Collapse
 
fabrikapp profile image
Fabrikapp

Always useful, thanks for the tips !

Collapse
 
schalkneethling profile image
Schalk Neethling

You are very welcome! Would you be keen to see more of these? Anything specific you would like me to cover?

Collapse
 
fabrikapp profile image
Fabrikapp

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.

  • Would the old history still be visible somewhere ? Or is it safe to conclude that old history will not be visible ?

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 ?

Thread Thread
 
schalkneethling profile image
Schalk Neethling

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.

Thread Thread
 
fabrikapp profile image
Fabrikapp

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 !

Collapse
 
mikec711g profile image
Michael Casile

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

Collapse
 
schalkneethling profile image
Schalk Neethling

Thank you for taking the time to write this thoughtful comment. I am glad you found value in this. ๐Ÿ™Œ or old school o/\o

Collapse
 
schalkneethling profile image
Schalk Neethling

It sounds like the general consensus is, "We want more of this!" ๐Ÿ˜ƒ

Well, alrighty then ;p

Collapse
 
osonwa profile image
Osonwa

Nice tip, learnt something new

Collapse
 
schalkneethling profile image
Schalk Neethling

That is great to hear!