Skip to content

Instantly share code, notes, and snippets.

@wildlyinaccurate

wildlyinaccurate/workflows.md

Last active August 29, 2015 14:08
Show Gist options
  • Save wildlyinaccurate/a0c0b66bae759f6d29a4 to your computer and use it in GitHub Desktop.
Save wildlyinaccurate/a0c0b66bae759f6d29a4 to your computer and use it in GitHub Desktop.
Download ZIP
Git Workflows
Raw
workflows.md

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

  1. Branch from develop
  2. Commit as you go
  3. Merge develop into your branch
  4. Push branch, create PR
  5. 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)

  1. Branch from develop
  2. Commit as you go
  3. Rebase develop into your branch
  4. Push branch, create PR
  5. 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

  1. Branch from develop
  2. Commit as you go
  3. Rebase develop into your branch
  4. Push branch, create PR
  5. When branch is ready to merge, squash commits and force-push
  6. 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.

@wildlyinaccurate
Copy link
Author

@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.

@stevenjack
Copy link

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment