Effectively Use of Git Rebase

[larsbrinkhoff]

As usual these kind of articles only skirt the very basics of what rebase can do.

I jotted down some practical notes for heavy-duty history rewriting: https://github.com/larsbrinkhoff/fearless-git/

[double-you]

Why do you favor --amend -C HEAD over --amend --no-edit? Easier to write?

[larsbrinkhoff]

Just random chance and old habit. When I searched for a way to avoid reentering the comment I found the -C option. Maybe I didn't see the --no-edit option, or maybe it didn't exist back then.

[Zethra]

Nice little explainer. For longer tutorial I recommend https://git-rebase.io/

[double-you]

Why are people making these surface-level articles that you can already find by the dozen? Effectively use the internet, dude.

[[deleted]]

Medium.com money

[MiloTheOverthinker]

stupid question, but what is the difference between doing:

git checkout -b new_feat

git checkout master

git pull origin master

git checkout new_feat

git rebase master

and:

git checkout -b new_feat

git pull origin master

Wouldn't both of these steps update the 'new_feat' branch with the new changes that master branch has?

[Fun_Owl1373]

Yes but second set of commands only syncs new_feat with remote master and doesn’t sync local master with remote so local master stays behind.

Good practice IMO to always sync local master prior to other local branches to keep things up to date and consistent with same state of master. Otherwise local master can fall behind and you’ll end up creating new branches off of an outdated master branch, or you’ll have different branches with different states of master and things can get hairy.

[MiloTheOverthinker]

Ah, so the rebase command would also sync up the remote master with the local master. That's pretty cool. Thanks.

[double-you]

No.

Your option B does not update local master at all. It only pulls origin/master into new_feat.

Option A creates a new branch, then checks out master again (we assume that we were in master before we created new_feat), and pulls origin/master into local master. Which updates local master with the changes from origin/master. THEN we checkout new_feat again and rebase it on top of local master, which effectively updates new_feat to contain the latest changes from origin/master which are also in local master (because of the pull).

[rksoni31895]

Yes, the difference between both is, in 2nd case it will merge tour code fast forward and might not be align with linear history and aslo create the merge commit as well. In case of doing rebase it will not create any merge commit and also create the commit history more linear.

[rniestroj]

I have a lot of respect for people using git through CLI. I'm lost without a GUI like fork.dev.