Git / GitHub Rebase Workflow

[apbendi]

Moving forward, we want to follow a rebase workflow on the project, rather than a merge workflow. In brief, this means:

• Each new feature should be developed in an independent, short running branch
• The developer or developers working on said feature are responsible for keeping it up to date with main, that is, rebasing their branch to main as it evolves
• Every PR merged should be a fast-forward only, or should be merged with GitHubs Rebase and Merge button
• Force pushing to feature branches is a normal part of this workflow, but developers should not force push to main
• If a PR cannot be merged via rebase due to a conflict, it's the responsibility of the developers working on that branch to perform the rebase of their branch, resolving conflicts in the process

The advantages of this system are:

• Encourages short-running feature branches with fewer opportunities for merge conflicts
• Encourages the developer of the feature to be the one that resolves merge conflicts related to said feature, reducing the likelihood of a bug or regression slipping in due to conflict resolution
• Keeps commit history clean and easy to read

[thelostone-mc]

Quick question here @apbendi ! How does resolving conflicts work against main work when 2 contributors are working of the same branch ?
Do we still wanna stick to rebase ? cause if i do rebase on a PR we both are working on -> it's going to amend every commit you've made with my name

[apbendi]

Do you mean what happens if there's a long running feature branch, and two different devs branch off that feature branch? First part of the answer is: avoid doing that wherever possible. Second part of the answer is, when completely unavoidable, cherry-pick commits onto the base branch when a divergence occurs.

[apbendi]

Adopted and added to the contributors guide in #96