GitHub Pull Requests Between Branches
My organization is making the transition from SVN to Git (hosted on GitHub) and we have basically adopted the git-flow branching model.
We have been using pull requests to merge between branches. We use the GitHub web interface to process the merge and close the request.
Pull requests are merged with –no-ff. So a merge commit will occur in the destination branch.
So…. We merge from develop to master often – so what happens after the merge is the develop branch will be both behind (due to the merge commits not being in master) and ahead (due to new work being done in develop).
Over many iterations, we end up with “develop branch is both 23 commits behind and 7 commits ahead of master” – which seems ridiculous. Should we just not worry about this? Should we merge manually and not through the GitHuib web interface?
One Solution collect form web for “GitHub Pull Requests Between Branches”
If the only reason that develop is ever behind is because of merge commits, then you should be able to routinely schedule a sync.
git fetch git checkout develop git merge --ff-only master git push
If you have some hotfix branch that went in, then the worst case is that the above will fail. However then you’re just going to merge without the
--ff-only tag. That’s perfectly acceptable and expected (see the comment on the answer).
While it’s convenient to use GitHub’s pull request system to manage pulls from other remotes, you should do some internal cleanup now and then without using GitHub.