or if you want less commands git checkout BRANCH git pull --rebase origin master git push origin BRANCH:master git push origin :BRANCH
but personally I prefer to separate the fetch from the rebase as you have at least more of a feeling of control (e.g. you can check the git log origin/master locally first before doing the rebase On 16 January 2017 at 09:11, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > I do not thing we want an overly heavy process. > > For the 3.5.0 release I suggest we try the following. Rebase so that it is > a fast-forward merge > > git checkout BRANCH > git fetch origin > git rebase origin/master > git push origin BRANCH:master > > if that git push fails, > > fetch > rebase > push > > once your push has succeeded > > git push origin :BRANCH > > > On 16 January 2017 at 08:51, Christian Schulte <c...@schulte.it> wrote: > >> Am 16.01.2017 um 09:00 schrieb Fred Cooke: >> > No, not correct in my books. >> > >> > git checkout BRANCH # Assuming it's local already >> > git fetch upstream # risk free, unlike pull! >> > git rebase upstream/master # diff difftool merge mergetool settings are >> > useful, prompt = false and specify your diff tool in advance >> > git push --force upstream BRANCH # After verifying no one has pushed to >> it >> > # create pull request/email someone/communicate your intention to have >> it >> > merged >> > >> > ^ correct in my books, others may differ. >> >> I merged pull requests from others in the past as well. Create pull >> requests for master even if I am a committer? Really? That would mean I >> would create a pull request I will pull in myself afterwards? Leave the >> merge commit so that the merges can be tracked back to the PR? >> >> Regards, >> -- >> Christian >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> >
