What is our git workflow?

[clemens-tolboom]

After merging #22 not paying enough attention we need to make sure how to merge PRs.

I personally don't care about my commit messages but as I wrote in http://build2be.com/content/do-we-need-git-squash-and-thus-forced-pushes squashing is an ok workflow.

Cherry picking on the other hand is too much of a burden regarding PRs. Github provides a nice workflow regarding merging providing a 'delete branch' in the end.

So let's do the squash workflow:

• evaluate all tasks from the issue
• check the code
• squash the branch
• merge the PR
• delete the branch

@clue what do you think?

[clue]

In my opinion a messed up branch with lots of unrelated changes is a bad thing just as much as a squashed branch with only a single changeset.

So personally, I prefer a approach somewhere inbetween: The commit history is there for a reason and it should contain each independent changeset. This allows to later move, merge, rebase or cherry-pick changesets between branches and to more easily see what's actually going on.

Squashing may still be useful if the branch is cluttered with uninteresting/useless commits that can be grouped to a single changeset (like "remove A from B", "remove A from C", "remove A from D" could be squashed to a single "remove A from B,C and D" commit).

Other than that, your suggested workflow looks okay to me.

That being said, I always prefix incomplete PRs with a "[WIP]" (work-in-progress) marker to indicate they're not yet to be merged and still have some incomplete tasks. This has proven to be quite useful as it highlights the current working tasks and encourages input to the current stage.

[clue]

I think this can safely be closed now.

If you feel there's still need for any discussion, just re-open this ticket or file a new one.

[clemens-tolboom]

Thanks.