Rebase might be the most misunderstood git command.
Nearly every junior developer I pair with is terrified of git rebase.
Ironically, rebase is o...
For further actions, you may consider blocking this person and/or reporting abuse
I still feel a nervous tension whenever I rebase. It seems to depend on the context. Sometimes rebase feels like the obvious thing to do, other times I just know rebase is going to break everything ... until it doesn't. Basically, git can sometimes be scary.
Loving the series, Jacob. Thanks!
Git is terrifying. That's a big part of the reason I chose to write about it.
These tools don't have to be scary, and hopefully writing about them in simple terms helps to dispel some of the mystery about them.
Yup! But I couldn't work without it.
For me, you're doing exactly that. Keep up the good work.
Great article. Can u confirm that u would typically pull the master branch (to ensure u have the latest master) before doing a 'git rebase master' as mentioned in article to rebase 'master onto a branch'. Thanks for your time.
Yeah, generally that would be my workflow. 👍
Good stuff, this is an easy to understand explanation. For me, git rebase was an imposter-inducing concept because a lot of the information out there is so nonchalant ("just rebase") or so technical (a complex web with arrows everywhere) that it was hard to establish when to use it and how in a practical example, so thank you for that.
Cool, I'm glad it was easy to understand; that was my primary goal.
Which is why the example is so simple (but a common problem nonetheless).
I'll probably do a follow up going over the
-iflag and some more creative things you can do with rebase to make your life easier.Finally a simple and easy to understand article about git rebase.
At first I was terrified doing rebase but now its my daily habit on maintaining feature branch.
I was terrified of rebase too for a long time
I think it's a failure in git's communication strategy 😂
I agree, it has a bit of a public perception problem. 😬🙃
Great post. Explained simply indeed. I can't recall how many times I googled what rebase 'really' does and not just trusting stack overflow. Btw I love your podcast. Keep it up.
You talked me into it:
Glad to hear it. Hopefully I get some new episodes up soon.
To be honest I'm still confused. What is the need for rebase, if you can merge master into the working branch?
For one thing, merging creates a merge commit which can clutter the git history. I don't feel as strongly about that as a lot of people do, but it's the most common argument for rebasing over merging.
Personally, I prefer rebasing because of the
-iflag which allows you to re-order commits, reword their messages, squash, and manipulate commits in a bunch of cool ways!Great article. Would u typically do a 'git pull master' to ensure master is up to date before git rebase master? Thanks for your time.
Ok, just so I’m clear:
From branch, checkout master.
Pull from origin to get master changes.
Go back to branch.
Run: Git Rebase Master
Like that?
Thanks for sharing :)
I will definitely try to work with this, it makes a lot of sense.
And then I should really get a guy course soon !
this was my third or fourth attempt on trying to understand rebase and the first successful one. thank you!
how can something so simple be so hard to explain?
I'm so glad to hear that you were able to understand the article!
When i rebase, it's always because your base is belong to me.
git push -f origin master
alias git-yeet='rm -rf * && git commit -am "yeet" && git push -f origin master'Love the clear explanation, was the start for me to start experimenting with git rebase.
Sometimes, an article can be the push needed to start - thanks!
What happened to commit 'df796f7e Cache data on /mod (#5315) [deploy]' in the working branch (before rebase)? 🤔
Haha, I just removed it. That was an accident. I was using the dev.to's git repository for the examples and I removed some commits to make them shorter/less tedious to read and I guess I just removed that one everywhere else!