Consider Squash or Rebase only?

[devlinjunker]

Describe the Improvement:
Just using Merge can create confusing looking network graph:

Should we consider only allowing Squash and Merge and Rebase and Merge?

Benefits:

• Clean network graph (no repeating dates like in image above)
• Rebase ensures latest commits are up to date

Drawbacks:

• Lose history of commits during development (how important is this?)
• Squash has issues with PR diffs when you branch off squashed branch and want to merge later

How to Compare:
TBD

[devlinjunker]

considering Squash only for #4 and conventional commit messages

[devlinjunker]

As part of auto-merge action described in #5

[devlinjunker]

Losing the history and relationship between commits seems like a big deal to me

Cons

• Being able to create branch B off of branch A and then merge branch A without any problems in branch B merge is worthwhile.
• Also there was the problem with squashing andthe githook large change warning being able to determine the last time a PR was made.

How often does looking at the commit history matter? Why does it need to be pretty?

[devlinjunker]

Seems like the best way is:

• on merge to develop branch from feature or fix branches, always squash, this means each feature will end up being 1 commit
• on merge to main branch from develop, use basic merge to keep history
• on merge to develop from main after release, use basic merge to keep history

Right now, we use bulldozer (see #43) to auto-merge PRs into develop, and this always does a squash so we prefer that.

For release/hotfix PRs into main, we do these manually, so we should use the merge button in the PR for these