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