thiago, there is absolutely no sense in all the gitflow stuff. The more I think about it the more I come to the conclusion they never did a big project yet.
Really the ONLY reason for such a workflow is if you have tons of uneducated juniors working on the codebase and trashing your project by committing more bad things than good things. But I hope that is NOT the case for ASF projects... Btw, for such projects I'd rather suggest to use gerrit and not gitflow... How does it work usually. 1.) trunk/master is the 'next planned big release'. Most of the work happens there. 2.) For each released version we have a tag. If we need maintenance on those (like we have with 1.7.x then we simply create a maintenance branch for it. 3.) If there is a need for a hotfix then simply grab the tag of the release and create a branch from it. Then just apply the fixes you really need and no bit more. That works that way since years and I've never seen any issues. The point is that it doesn't make much sense to do all the work upfront because you _might_ need it. Just do the work IF you need it instead. That's really easy to do with GIT. LieGrue, strub > On Wednesday, 28 January 2015, 14:05, Thiago Veronezi <[email protected]> > wrote: > >>> ...oops for tomee you dont get the snapshot > I agree. But that's the whole point. We shouldn't get the snapshot from > master, according to the "Gitflow". I think it pays off when we have a > hotfix like critical security bugs. Instead of rushing all the on-going > tasks in order to close them for a new release, we would simply create a > hotfix branch out of master, do the fix and merge it to develop and back to > master. The link Andy provided has a chart that shows exactly how it would > help. See the "hotfixes" line: http://nvie.com/img/[email protected]. > > If the "pom.xml" file in "origin/master" does not use the > "SNAPSHOT", it > raises a flag to the developer. "Where the hell are the snapshots?" :) > She/he would need to switch to the develop branch. > > []s, > Thiago. > > > > On Wed, Jan 28, 2015 at 7:09 AM, Romain Manni-Bucau > <[email protected]> > wrote: > >> was the idea but: >> - doesnt make sense @asf >> - are we numerous enough to commit to let it get any sense? >> - do we want this ability at all? >> >> IMO we dont >> >> master = 2.0.0-SNAPSHOT = last version of the main version so it is >> not wrong even if not sexy. >> >> What we'll do basically when releasing is just merging all to master >> if we keep develop so we just added noise for external guys >> >> >> When you go on github what do you do? >> >> git clone xxxxx >> cd xxxxx >> mvn clean install >> >> >> ...oops for tomee you dont get the snapshot >> >> >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-01-28 13:06 GMT+01:00 Thiago Veronezi <[email protected]>: >> > 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 < >> [email protected]> >> > 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 > <[email protected]>: >> >> > 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 > <[email protected]>: >> >> >>> >> >> >>> 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 >> >> >> >
![http://nvie.com/img/[email protected]](http://nvie.com/img/git-mo...@2x.png){kind=link}