Git Workflows

workflows.md

Merge all the things (current workflow for the responsive-news repo)

0. Branch from develop
1. Commit as you go
2. Merge develop into your branch
3. Push branch, create PR
4. When branch is ready to merge, merge the PR

Pros

• Simple; everybody is familiar with it already
• Branch history is preserved in develop, even after branches are deleted
• git-blame is accurate since original author of all commits is preserved

Cons

• Develop is full of "Merge branch 'develop'..." commits
• Develop is full of work-in-progress commits
• Single changes are scattered across multiple commits

---

Squash locally and cherry-pick (current workflow for the responsive frameworks team)

0. Branch from develop
1. Commit as you go
2. Rebase develop into your branch
3. Push branch, create PR
4. When branch is ready to merge, squash commits locally and rebase (or cherry-pick) into develop

Pros

• Develop maintains a clean, "meaningful" history
• Branch history is preserved on GitHub

Cons

• Lack of merge commit removes context around merge (easily fixed by no-ff merging instead of cherry-picking into develop)
• GitHub becomes a branch graveyard
• git-blame is inaccurate if commits from multiple authors are squashed

---

Squash, force-push, merge PR

0. Branch from develop
1. Commit as you go
2. Rebase develop into your branch
3. Push branch, create PR
4. When branch is ready to merge, squash commits and force-push
5. Merge the PR

Pros

• Develop maintains a clean, "meaningful" history
• Merging into develop gives context of when change was merged as well as when it was authored

Cons

• Branch history is lost* when branch is deleted
• git-blame is inaccurate if commits from multiple authors are squashed

* Well, sort-of. You can still find the commits if you know what you're doing. But the commits will be "dangling", which means they're completely at the whim of Git's garbage collection.

Comment on the Squash locally and cherry-pick approach - you can delete branches and still have access to the commits within the PR.

If you are merging your own PR, then you can use the following:

git checkout master
git merge --squash feature_branch
git commit
git push

Within git commit we usually set the title as the PR title, and the description as Closes #<PR_num>.

@revett that's a really good point. Since GitHub creates a new branch for each PR (in refs/pull), the commits will never be dangling. That's completely sold me on your workflow, actually.

👍