Workflow: git with feature branches, rebase, pull requests (not open-source project)

Question

We have 5 developers in a team submitting pull requests regularly (daily) to master branch of a single repo. Typical workflow is like this:

• Clone repo from server
• Create local feature branch from master branch
• Make changes, commit, iterate until done
• Rebase onto master branch (squash commits)
• Push to server
• Submit pull request

The problem is that if multiple developers submit pull requests, only 1 of them can be successfully merged into master branch. Once that is done, all others fail because master branch is ahead of the feature branches. Then all devs must again rebase and push. Then only 1 can be merged and the rest fail. Iterate until all PRs are merged.

There must be a better way, right?

Answer 1

Bitbucket has the following merge strategies available. It sounds like your team has selected either "Fast-forward only" or "Squash, fast-forward only". This will reject a PR if it is not fully rebased, and as you have noticed this is annoying when PRs are lined up.

If you want to keep the clean history graph and also not have merge commits (which I assume was the reason for choosing that option to begin with), then two other options you could use instead are: "Rebase, fast-forward", or "Squash". These will do the rebase at completion time and should not block the request if they are queued.

Side note: I personally prefer what some other tools call "semi-linear merge", which would be equivalent to the BitBucket option "Rebase, merge". This forces a merge-commit which is nice so you can see all the commits that are associated with that PR, and enables you to view the --first-parent history which shows the actual changes made to the master branch. But, in your case, if everyone is squashing down into a single commit for every PR, then perhaps there would be little to no value gain for you. But if you ever decide to allow multiple commits in a single PR, then it might tip the scales in that direction.

Answer 2

The later PRs shouldn't fail, PRs don't need to be rebased or targeting head necessarily in order to be merged.

If you are facing constant conflicts then the team is not decoupling the components and they are all working on the same files. Or you are setting a repository strategy as TTT mentions.

I work on a github project with 40 devs, at least over 20 daily PR and we never face that specific problem. In fact I don't usualy rebase before PR unless I know my file will probably cause conflict when merging.