CODEWITHSUNDEEP
gitgithub
meyousikmann
meyousikmann

Reputation: 861

Git pull requests and rebasing

I am confused with GitHub pull requests.

I am trying to follow a workflow where a feature branch is created from master when work is started on a new feature. When the feature is ready to be merged to master, a pull request is required (meaning the master branch is locked so an approval is required before merge).

The problem I am having is that a PR can be a long lived process. So it is quite common that by the time the PR is approved, the feature branch needs to be rebased on top of master before it can be merged. The act of doing the rebase causes the PR to be re-opened and require another approval. Depending on how long it takes to get approval on the PR, this could be a never ending cycle.

Here are the steps of what I am talking about:

  1. feature branch created from master
  2. development on feature branch
  3. feature development complete and PR request opened
  4. some time passes and master branch has new commits
  5. PR approved for feature
  6. since master is ahead of feature branch, rebase feature branch on top of master
  7. PR is "reset" and now requires another approval
  8. goto step 4

It is easy to simply say 'get the PR approved faster', but I am dealing with multiple teams across the globe so it is not always possible.

Is my workflow unreasonable? Are there Git commands I should be using that I am unfamiliar with to help alleviate this issue?

Upvotes: 2

Views: 1729

Answers (1)

Carol Chen
Carol Chen

Reputation: 997

I think your dev process is fine, here are two points you may be missing.

  • If a rebase is required, then that means that someone else edited the code that the PR is working with; in which case there's a good chance the PR will have to be manually adjusted. These cases should be uncommon, however Github has a handy rebase and merge feature which makes such cases a non-issue. If there's a conflict, Github will tell you.

  • If a certain PR is taking a particularly long time, this may be a clue that the feature should be broken down into multiple pull requests.

Upvotes: 1

Related Questions