git rebase > git merge

I'm honestly tired of colleagues completely fucking up the git history along with creating conflicts for no reason at all.
How do you even manage to "recommit" changes when merging?

I can't even squash properly because there are 5 merge commits on the feature branch. Fuck off

I think squashing is better than rebasing if you're working on feature branches

Oh my bad he didn't "recommit" my changes he completely removed them when merging
Even though he was working on another component

Yeah cool that's fine I guess

@craig939393 well we always squash when merging a pull request, or rather our git service is configured to always do that

But one of my colleagues merges *on* the feature branches

I always rebase my feature branch whenever develop branch has major changes to it. And force push to sync it with remote if I have pushed it remote.

I try to teach my colleagues to always fetch remote *before* committing in the case someone has worked on the branch in the meantime.

One colleague created 3 feature branches, and merged develop into each one after a branch had been merged. When doing QA on the PR, it looked like that branch re-committed previous features.
I had to go in an “magically” clean up the branches, so they only contained the commits related to that feature.

I mostly blame it on bad GUI tools that hides too much of what’s going on behind the scenes. I like SublimeMerge since it basically shows you the cli commands it runs.

@ChainsawBaby yeah true, I try to use the command line most of the time

Also pull is set to ff-only, I don't know why you would want implicit merging that just sounds like a bad time

You know what's worse? when they merge but title the commit "rebase from develop" .. boils my blood, what does that even mean.

A solution for you: git push --force 😂

@Khani well I don't wanna erase the code from my colleague either

"Practice what you preach"