[LRUG] Keeping a nice git history with a pull request workflow on github

[Bradley Wright]

On 16 Jul 2013, at 15:31, Chris Adams <wave at chrisadams.me.uk> wrote:

> Anyone on the list found a nice way to combine the transparency and code review of a pull request based workflow, with the tidiness a well maintained git history?

Most people have mentioned a reasonable GitHub-based workflow already, but here's a summary of some patterns we're using every day on GOV.UK:

- Make feature branch, hack away (personally I will continually commit "WIP" "WIP" etc. over the course of work)
- Rebase branch to combine and tidy commits (into separate things - as Murray said, not necessarily showing your work)
- Send pull request
- React to feedback in the pull request - this is where things diverge.
  - Some people are happy to rebase the feedback changes into the branch, which makes for those slightly annoying "So and so discussed an outdated diff" messages on the pull request; or
  - Some like to do it as separate commits specifically addressing feedback. I'm agnostic about which of these two you pick, depends on the team and the kind of changes they are, really.
- Code is all good and passes review, but needs to be updated from master. Rebase master over the branch, fix conflicts.

This gives you a nice master history like:

* Merged team/feature-1 into master
\
 * Addressed feedback on feature-1
 * Tests for feature 1
 * Main thing for feature 1
/
* Some bug fix
* Some other single commit to master
* Merged team/feature-2 into master
\
 * Etc.

So there are clear branch/merge points when large features are merged, and it's explicit. (Should the worst come to pass, a single merge commit is easier to back out as well.)

An example of how this looks on GitHub:

https://github.com/alphagov/whitehall/compare/build-4900...build-4909

Brad