git init, git branch mybranch, git checkout mybranch, git add, git commit, git push, git pull, git merge⦠These are the commands I use the most and I honestly thought they would be enough (at least while working for the first time in a collaboration project) But all of a sudden reality hit me (in a good sense) and I had to face it: I couldn't run away from git rebase.
Although it might sound scary because it was an unknown commit for me and I didn't really understand the difference between merge and rebase, practice made me finally learn and understand why it is worth using it.
Git rebase integrates changes from one branch onto another. It is basically like cutting your branch and moving it to the very last commit in main/master. It is an alternative to git merge because it offers a cleaner repo history.
Let's have a look at the following case scenario:
I have a new repository that only contains a README file so far. I want to start working on it so I create a branch: git checkout -b mybranch
I have switched from main to mybranch and want to start creating files but suddenly another colleague pushes some changes into main (an index.html file) If I pull changes from mybranch, Git will inform me that mybranch is βalready up to dateβ:
But of course, if I switch to main and pull the changes, I will see the html file there:
What is happening here? I don't have the latest changes from main because mybranch is behind main. How can I fix this? The scary command is everything I need. I only need to type git rebase main and I will automatically move mybranch on top of main getting the latest updates and voilΓ‘: I can see now the index.html file on mybranch.
One lesson learnt, one less problem. What about you? Do you dare putting git rebase into practise?
Top comments (6)
Funny coincidence how one of my colleagues at work was scared of using rebase and I am seeing this post. He is senior to me and instead of learning and risking a rebase, he wanted to create a new branch from the main dev branch we cut from and copy-paste his changes (from the feature branch) into that, lol. Although our lead suggested rebasing but since the guy was so hesitant and creating a new branch and then manually copy-pasting the changes was so inefficient, he suggested cherry picking. Much better and a good middle-ground but still inefficient to rebasing. I was in the background thinking to myself, why not take this opportunity and learn rebasing. Not doing something that has to be done just because it hasn't been done till now is kinda slacky considering the favorable situation, there was no major time bound, there was hardly any criticality in it. I have seen people react this way to a rebase before.
Simple and crisp article Cristina. Adding a little section contrasting it with how a merge is different would be great. I think people often incorrectly understand a merge and the merge commit.
I totally agree. I was reluctant myself in the beginning but when I understood how it works, I tried it and I would do it again. You are not learning if you are not challenged :)
Counterpoint: IMHO it's a major design error from the git authors to have promoted so much the often futile and inherently dangerous act of rewriting the history. Contrast to others VCS who keep it for exceptional cases like you have committed a secret or copy pasted something you weren't allowed to do.
There is a reason why "you are rewriting history" is understood as a severe critic outside of programming. History is best kept immutable. That requires the courage to accept that history is messy, and show how things happened instead of how your ego wished they would have happened.
The very fact that every week there is a new article on how to stop screwing up things with git rebase is a huge red flag from a usability perspective
It's a terrible idea to change the history of a branch that others have synced against. However, rebase is awesome for cleaning and organizing local/dev branches. Some open source projects demand that you rebase your branch after incorporating review suggestions to avoid having a bunch of noise in the commit history.
It's also probably less of an ego thing and more of an insecure/embarrassed thing.
"for cleaning and organizing local/dev branches" by this do you mean rebasing our feature branch onto main and then creating a PR?
No. I mean after you have opened a PR and applied changes based on reviews. Some repo owners don't want commits like βapplied review suggestionsβ around so you rebase your branch to squash these into more reasonable/logical commits.