Hi folks, Actually, master is already an ancestor of v2 ... in other words, there is nothing in master that hasn't already been merged into v2. So I don't need to be quite so drastic to switch the branches.
I've created origin/v1, which is now the maintenance branch for future v1.x releases. And I've then merged master up into v2, as in: git checkout master git merge origin/v2 --ff-only git push master So, if you have been working in the old master, for whatever reason, then you just need to pull down "v1" instead. Thanks Dan On Thu, 7 Nov 2019 at 11:01, Dan Haywood <d...@haywood-associates.co.uk> wrote: > Hi folks, > > we're edging closer towards a v2 release, and we think it's now time to > switch over so that "master" is now the "v2" branch. > > My plan is to create a "v1" branch for where "master" currently is, so > that goes into maintenance mode. (There may well be another v1 release, > because it's been a while and there are some changes on that branch). > > In other words (if github/ASF karma lets me), I intend to: > > git checkout master > git checkout -b v1 # new 'v1' branch at same place as master is > today > git push origin v1 -u # push to origin/v1 > > git branch -f master origin/v2 # force master to same place as v2 > git checkout master # checkout that branch and ... > git push origin master -f # force origin/master to same place > as origin/v2 > > If you happen to have master checked out locally, then don't do a "git > pull" because that would have the effect of merging in the v2 branch. It's > always a good idea anyway to do a "git fetch" to bring down new commits and > then take a look around. > > To carry on working on master, it'll be a matter of switching to the new > origin/v1 branch > > Hope to do this today at some point, > > Thanks all, > Dan > > >
