DEV Community

Cover image for Git merge, git rebase, and crawling out of the git hole

Git merge, git rebase, and crawling out of the git hole

juliette_chevalier on January 28, 2020

To master git is like being a time wizard ✨. You can move across points in time, flying like a bird from one commit to the next, always having a st...
Collapse
 
aminnairi profile image
Amin

Hello Juliette, nice article. This is by far the best explanation about the differences between rebase and merge in git!

I found on GitHub that you can do a squash merge. I learned to love it because it can squash (as its name indicates) all commits into one. From there, I always write something like Fixed an issue where the cat wasn't cute enough (#152) in the squash commit message. This allows having as many commits in the base branch as there are pull requests, keeping the history count low on the base branch. And if I need more details (meaning more commits history for that particular feature), I can click on the #152 which refers to the pull request ID.

What do you think? Is it a good idea in your opinion?

Collapse
 
jorgepvenegas_4 profile image
Jorge Venegas

That photo at the beginning. Can't relate more.

Collapse
 
_juliettech profile image
juliette_chevalier

Hahah I saw that and had to include it in. Too good 😂

Collapse
 
dcanning profile image
David Canning

Good article, not sure I like the amend, think I prefer to squash just before rebasing back to master just so I can get to all my commits while working on feature branch.

Collapse
 
_juliettech profile image
juliette_chevalier

Yeah, I've used squash as well. I just feel like amending is easier and safer, especially if you're just starting to play with rebasing.

What would you say is the added benefit of squashing rather than amending?

Collapse
 
dcanning profile image
David Canning • Edited

I'd say the main benefit of doing squash is that you still have multiple commits in your history up until you do the squash, so if you screw something up you can still look back through your commits to either get back to before, or look at the changes to figure out what you did. With the amend, you're adding your new changes to the previous commit, so you've only got the one commit in your history the whole time, no way to look at previous commits, because there aren't any.

Thread Thread
 
ac000 profile image
Andrew Clayton

Often --amend is exactly what you want.

Maybe you need to re-word the commit message, add a Reviewed-by tag etc... or perhaps you just need to make a code change or you forgot to git add [-p] something...

I would say I use --amend a lot more often than squashing commits.

The right tool for the job and all that...

Collapse
 
emmabostian profile image
Emma Bostian ✨

This is awesome hahahhahah.

Collapse
 
_juliettech profile image
juliette_chevalier

Haha yay, thanks :) glad you liked it!

Collapse
 
ale_jacques profile image
Alexandre Jacques

Have to agree. By far the best explanation I've seen in a while. Great stuff!

Collapse
 
_juliettech profile image
juliette_chevalier

Thank you!! Glad I was able to help :)

Collapse
 
jmcp profile image
James McPherson

Really well written, thankyou.

Collapse
 
_juliettech profile image
juliette_chevalier

Thank you!! Appreciate it :)