5 ms·

"No broken commits" is one, "nobody cares how often you merged master into your feature branch" is another. Most of the real reasons revolve around making a bis

• kerblang 6y ago
  If it helps any, I usually squash-merge my final output into sparkling, concise commits with nice messages (my original branch usually has "x" for every commit message). And yes I have a dedicated script for squash-merging too...
• patrickthebold 6y ago
  My preference is to disallow/disable fast-forward (and squash) merges to master, and then use --first-parent when you want the clean non-broken easily bisectable history, which is most of the time, but the full messy history is still there. I actually don't care so much about seeing the messy history, but its annoying when everyone on a team is always rebasing there branches and force pushing them. I've definitely been at places where one team member is waiting on another to merge their code to master so they can start working. Of course, rebase all you want locally before you push.
  • Buttons840 6y ago
    Try not pulling other team members branches. What I mean by that is instead of having your own branch HEAD/tag (whatever the term?) for their branch, do `git checkout origin/their-branch` when checking out their branch. Git will complain about a detached HEAD, that's OK. Then later when they rebase and force push, just do the same thing again, and you never have to worry about making sure your own local branch for their branch is in sync.