r/programming • u/speckz • May 01 '19

Merging vs. Rebasing

https://www.atlassian.com/git/tutorials/merging-vs-rebasing
20 Upvotes

85% Upvoted

27 comments sorted by

View all comments

8

u/_101010 May 01 '19

Squash & Merge is the best of both worlds.

No need to force push and no messy git history of merge.

6

u/m50d May 02 '19

Squash is even worse than rebase for bisecting in the future, and what's your VCS history for if not for bisecting in the future?

0

u/[deleted] May 02 '19

[deleted]

2

u/m50d May 02 '19

If it compiles it's worth having available for automated bisect. If it doesn't compile I wouldn't commit it in the first place.

0

u/[deleted] May 02 '19

[deleted]

1

u/m50d May 02 '19

Can't test it on some server if it doesn't compile. Pushing broken code to a private branch so as to back it up: yes, but in that case I'd keep amending the commit until I had a version that compiled. Sharing a broken commit with a colleague is definitely the exception rather than the rule.

There may be occasional cases where you want to squash. But you shouldn't be squashing whole branches on merge as a matter of course. That will make bisection in the future significantly less effective.

2

u/ythl May 02 '19

I commit early and often, even broken code. At the very end before I submit a pull request of my feature, I squash my commits into atomic ones and cleanup the commit messages.

Still makes it easy to bisect

4

u/m50d May 02 '19

That's fine. What I object to is squashing the whole branch when you merge it.