Hi, If I get it right...
* "origin/master" is just a regular branch, and a branch represents what we want it to be. For the "gitflow", "origin/master" is our latest release. In this case, if someone performs a checkout of master and builds the application from it, she/he will build the 1.7.1 distribution. Note that currently it points to "2.0.0-SNAPSHOT". So maybe it is not in good shape because this source code it is not production ready. * "origin/develop" is our tomee 2.0 * "origin/tomee-1.7.x" is our tomee 1.7.x If we talk about commands, we would use the following in our development process [Just tested it to be sure. :) ]... // check out the source code. "origin/master" is the default. We don't commit to this guy. git clone https://git-wip-us.apache.org/repos/asf/tomee.git my_source Cloning into 'my_source'... remote: Counting objects: 236092, done. remote: Compressing objects: 100% (73416/73416), done. remote: Total 236092 (delta 115784), reused 233010 (delta 114168) Receiving objects: 100% (236092/236092), 35.93 MiB | 986 KiB/s, done. Resolving deltas: 100% (115784/115784), done. // go to new directory cd my_source // create a local "develop" branch for for tomee 2.0 from "origin/develop" git checkout -b develop origin/develop Branch develop set up to track remote branch develop from origin. Switched to a new branch 'develop' // create a local "feature" branch for for tomee 2.0 from the local "develop" git checkout -b cosmetic develop Switched to a new branch 'cosmetic' // now we work on the tomee 2.0 feature and commit git status git add pom.xml git commit -m "moving end tag up" // ready to merge back to develop git checkout develop // update develop git pull // merge our local branch git merge cosmetic Updating edaf6d2..21ad55b Fast-forward pom.xml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) // push to remote develop git push // delete local branch git branch -d cosmetic Deleted branch cosmetic (was 21ad55b). // if we have a new feature, we repeat step from this step... git checkout -b new_feature develop ... Basically, we don't touch "origin/master". Only when we merge "origin/tomee.1.7.x" (or "origin/develop") back to it. I don't see a problem. We just need to keep in mind what "origin/master", "origin/develop" and "origin/tomee.1.7.x" represent. Is that right? []s, Thiago. On Wed, Jan 28, 2015 at 4:59 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > well it is by design opposed to apache way since if it is used it is > to have the ability to change commit history - if not it is really > useless. > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-01-28 10:57 GMT+01:00 Andy Gumbrecht <agumbre...@tomitribe.com>: > > I know I set it up this way, but I am really +0 at the moment. I don't > feel > > any anger towards it though. It is not 'my way', rather the Gitflow way. > > > > I'm not going to push it other than to point to the description of > Gitflow. > > It's only going to make sense if you use it, and then really only if you > > play release manager, and then only if you are managing both 1.7.x and > > develop releases. > > > > The scenario is described here in extreme detail - > > > https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow > > > > It just 'looks' future safe to do it that way, and until the Gitflow has > > been tried and tested on the upcoming releases we will not know. Jon > should > > give us his feedback after the releases are done. And then we should all > > look at the repo. The decision to use it was based on that description > and > > they guy who 'invented' it - > > http://nvie.com/posts/a-successful-git-branching-model/ > > > > I actually don't know what is so painful about using '-b develop' on the > > initial developer checkout? That's it, everything else is identical. As a > > developer it is trivial. Where are the hard line drawbacks to it other > than > > to say it's crap? Why is is so painful for some? I really want to > understand > > what is causing the hate? > > > > The simple idea is that 'master' only ever contains production ready > code, > > that's it. No more no less. > > > > Anyway, if everyone agrees on a way forward then votes on it then I > really > > am +0, as it is not hard to do it either way. > > > > That doesn't mean: > > -1 It's crap! > > > > That does mean: > > -1 It's crap because.... and I will document 'my way' for everyone to > follow > > to the letter. > > > > Andy. > > > > > > On 28/01/2015 09:55, Romain Manni-Bucau wrote: > >> > >> hehe feel less alone now, +1 > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau > >> http://www.tomitribe.com > >> http://rmannibucau.wordpress.com > >> https://github.com/rmannibucau > >> > >> > >> 2015-01-28 9:53 GMT+01:00 Mark Struberg <strub...@yahoo.de>: > >>> > >>> Hi folks! > >>> > >>> Just noticed that our branch naming schema in GIT is still outerwordly > >>> fucked up. > >>> > >>> > >>> > >>> Why don't we do it as everyone else does? > >>> What does this crap of development branch do? It's total nonsense to > have > >>> it! > >>> > >>> There is NO RTC for development at whole ASF except for MAINTENANCE > >>> BRANCHES maybe. All the standard community work is CTR (Commmit Then > Review) > >>> That's a community wide modus operandi and we should follow it as well. > >>> > >>> > >>> So I for one will totally ignore this development branch when working > on > >>> the TCK in the next days. > >>> > >>> Can we please finally merge in all the good work in the development > >>> branch to master and delete it finally? > >>> > >>> > >>> LieGrue, > >>> strub > >> > >> > >> > >> -- > >> Andy Gumbrecht > >> https://twitter.com/AndyGeeDe > >> http://www.tomitribe.com >
