Skip to content

Instantly share code, notes, and snippets.

@AnthonySteele
Last active January 22, 2017 12:40
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save AnthonySteele/6e590e8f720e5c8cd5d0ea5666c47615 to your computer and use it in GitHub Desktop.
Save AnthonySteele/6e590e8f720e5c8cd5d0ea5666c47615 to your computer and use it in GitHub Desktop.

The git Pull Request is a powerful tool. But just because you have it, does not mean that you have to use it all the time.

I am thinking of a team that owns on a codebase and works on it regularly. Pull requests give outsiders a powerful thing that they did not have before: controlled access to apply changes that they need, with review by the owners. However it is not a good process to apply across the board to those same owners as a matter of course.

I always think of it as like a gate in an ancient walled city: A stranger can come in, if they pass inspection at the gate. Without the gate, they would be reduced to standing outside and shouting over the wall "We need this feature! And you need to update some urls!" and hope that it happens soon. So the gate allows them to come in and get business done, while respecting the local customs. But would you put that checkpoint inside the city and apply it to every citizen?

Pull request give review. There are other ways to do review. Human review is inconsistent, time-consuming, not scalable or repeatable and invariably has a political aspect. Review helps, but it is not a good substitute for e.g. simple test coverage.

Pull requests do not scale - you can wait for one PR to be merged before the next one, or you can anticipate trouble. They increase cycle time.

Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies to a shared mainline several times a day. https://en.wikipedia.org/wiki/Continuous_integration

They encourage you to forget that the "Integration" in "Continuous Integration" literally means "Merge to master". A branch or PR is by defintion not integrated. You can test a PR, but you can't Continuously integrate it without closing it.

If I was starting from scratch with setting up a process, I would work hard to avoid mandatory Pull Requests and encourage Trunk-based development. It might be that the lack of PRs would force you to do other things: good, those other things are things worth having.

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