Pull Requests

[JohnSundell]

I'd like to start a discussion around how we handle pull requests, both on internal projects and on open source ones. I personally think agreeing on a certain workflow for pull requests that we try to stick to most of the time is super valuable, since it tends to increase productivity and decrease friction (especially when dealing with a large number of projects, as we do).

Having clear guidelines also helps for external contributors, since it sets clear expectations of how we work and deal with PRs.

So, what I'd like to suggest to kick off the discussion is a few points (not saying we're not doing these at the moment, just my ideas on what I think makes a good PR workflow for teams):

• Always use descriptive PR titles & descriptions.
• Squash commit history if full of "temp" and "experimental" commits that don't add value to the history.
• Keep PR size to a minimum to make them easy to review and low-risk to merge in. (IMO, a 500 line change limit is a good guideline).
• Keep individual forks of our repos, and keep experimental branches there. Submit a PR when ready. On private projects we can use a branch prefix (for example josu/experimental-) to distinguish experimental branches.
• Favor private branches instead of "WIP" PRs. Reduces noise for the rest of the team. Clearly mark WIP PRs when really needed (for example if testing out things on CI).

What do you guys think of the above? Agree/disagree, or anything you'd like to add? Let the discussion...BEGIN! 💃

[vadymmarkov]

I agree with all your points @JohnSundell 👍 . The only thing I'm still a bit sceptical about is "everyone keeps their own fork" workflow when it comes to private projects. But maybe it's just me 🙂

[zenangst]

What @vadymmarkov said, I think this is a huge step forward for our process but I do share the same concern that I have some questions about the private repos. Maybe that's not a problem when we start doing it. I would propose to start doing this for open source straight away and then continue and see how this would work for private repositories. Ideally, I'd like to have the same flow for both public and private repositories.

[onmyway133]

How can I disagree 😄 Like @zenangst we can start now with open source repos to see how comfortable we are with it.

Also as we agree that the PR should has reviews and merged by the author, should we try this https://help.github.com/articles/about-protected-branches/ ?

[zenangst]

YEAH! Let's do this!

[zenangst]

One thing that I've noticed is that GitHub Desktop can get a bit confused when the push url differs from pull. I ended up just pushing from the Terminal.

[onmyway133]

@JohnSundell I begin to like the push url approach more than two remote 😇

[JohnSundell]

@onmyway133 🎉 Yeah it's a lot easier 😄