On 16/04/2015 23:52, Gavin Lambert wrote:
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).
Indeed, and I've found a way to do what I want: 1) Create a temporary local branch off develop and switch to it. 2) Merge the PR using git pull --rebase: now the PR commit is somewhere in the commit history prior to your last commits. 3) Revert the tree to the last commit from the PR. 4) Merge from develop using rebase - now the commits will be swapped round so the PR ends up at the end of the commit log. 5) Test. 6) Merge temp branch into develop: you should now have a clean history in develop with the PR commits at the end. 7) Delete the temp branch. Cheers, John.