git squash-merge — for people who hate:
* Long-lived branches
* Change history
* Parallel/decoupled maintainence of application/features and CI pipelines.
* Nice things.
git squash-merge — for people who hate:
* Long-lived branches
* Change history
* Parallel/decoupled maintainence of application/features and CI pipelines.
* Nice things.
You love your change history, you say? Do you love it enough not to litter it with `lint fix` and `fix typo` and `empty commit to retry failed CI job` commits from feature branches? If not, it's a lukewarm fondness. :-)
@gthb Yes.
Squash merges are good for exactly two things:
1. Writing abbreviated history
2. Preventing (sensitive?) metadata leaking.
There are other and better ways to be a neat freak about your git history, and if you want to want to prevent metadata escaping, you should be doing your squashed commits off in a separate repo anyway.
@gthb
On the other hand, squash merge strategies require the whole team to strictly abstain from large parts of git's basic feature set (and usage idioms) – lest you end up with repeated problems that are hard to decipher and to untagle.
Even veteran git users often have a hard time reasoning about how and why things went wrong and frequently end up force-resolving conflicts incorrectly and thereby losing valuable changes (and then the evidence of that gets wiped after the merge).