On 16/04/2015 23:00, John Maddock wrote:
So I have a rebase vs pull question:
Lets say I have a PR, if I merge that to my local tree using "git pull --rebase remote-repro branch-name" then I get a nice clean history locally without those pesky merge commits cluttering everything up. But...
Now I can't fast-forward when I push to the remote, *because I've changed the existing history of the develop branch*. Would this not be a) bad form, and b) potentially dangerous to push to the remote develop branch?
"git pull --rebase" is for updating "feature" branches -- ie. it's what the submitter of the PR would do on the PR branch itself to incorporate changes made on the parent branch (eg. "develop") into the PR branch, to make it easier to merge. You should never ever run that command on your mainline branches (master and develop). If you want to merge a PR without a merge commit, then you should cherry-pick it, as others have said. It's not unreasonable to have a merge commit in this case, though, since you are merging some third-party work. Typically the case where you want to avoid merge commits is when you're doing work yourself on a local feature branch. Also note that Github has convenience tools for automatically merging PRs, although the downside of that is that you don't get to test the results before they end up on your mainline branch.