Git is probably the most universal tool for software developers these days and understanding its nuances is key to a developing career.
You can get by with a limited grasp, but you are going to want to improve over time. git rebase is one of those commands that causes a lot of ongoing confusion, it's an evergreen topic to say the least.
I'm not the one to properly explain it to you but I wanted to share some of the awesome dev.to resources that have come to create quite the nice learning library.
The content on this subject goes pretty deep and there is much more than just these posts, but they are a great source. Jason chatted a bit about git rebase in his AMA last year. That post was a treasure trove of git knowledge overall.
The reason people shy away from rebase is because it rewrites history - meaning it changes the commit SHAs. So if you're sharing your work with others, that can be a problem.
It's likely this consultant was the victim of a force push and made a sweeping statement to never use rebase again. We've all been there. It's frustrating.
Being mindful of which commands, like rebase, can rewrite history resolves this issue. Then you can use it appropriately. For example, I use rebase often. But I do so at the end - right before merging - so I limit the chance for it to affect other developers.
Top comments (6)
P.S. I've learned that the community finds these kinds of dev.to roundups super helpful and they are really quick to put together.
The syntax for these rich content embeds is like this:
{% link https://dev.to/gonedark/a-closer-look-at-git-rebase %}{% devcomment n5g %}linkonly works on internal DEV posts anddevcommenttakes the "id" from a comment url. Eventually we'll have better guides for all this. ✌️I just figured out that this is on the "Help" page when creating new posts. Love it.
For the rest there's git.io/git-tips ;)
Nice grimoire!
When I need to explain what
git rebaseis and why it's extremely useful, it usually goes something like thisSimplest way that I see to describe rebase: if you have differences that aren't on the origin branch, briefly put those aside, pull in the origin branch into your local branch, and then apply those changes that weren't on the origin branch. What this does is always apply your own changes on top of the (structure of) the origin branch, while leaving that stucture wholly intact.