Again, gitflow IS nice if you have a bunch of juniors who don't know much what they do. And they keep trashing your project every single day... But for such projects I'd rather use Gerrit and enforce a tight review chain.
If you have a mature team then you don't need all this stuff. If someone mails to the list that he is working towards 1.7.2 then I hope that everybody will simply not commit any experimental stuff to this branch. LieGrue, strub > On Wednesday, 28 January 2015, 23:00, Thiago Veronezi <[email protected]> > wrote: > > Hmmm... I think I see how it works now. It starts to make more sense. :) > Something doesn't feel right though. Why Gitflow is so popular? How would > it protect the companies from having bad commits? I need to think about it. > Just wanted to let you know that I see your point. > > []s, > Thiago. > > > > On Wed, Jan 28, 2015 at 4:32 PM, Romain Manni-Bucau > <[email protected]> > wrote: > >> 2015-01-28 22:29 GMT+01:00 Thiago Veronezi <[email protected]>: >> > But if you only have master, any quick fix would bring unnecessary >> baggage, >> > right? >> > I mean, merging the fix changes from 2.x.x to master would be trivial >> > because it would only contain changes for that particular fix. >> > >> > If the release tags are on master, for a quick fix, we would need to >> create >> > a new branch from the latest release tag, do the fix in the new branch >> and >> > release it again. Where would this new release tag live? Do we keep > this >> > new branch just to hold a minor code change for a bug fix? >> >> If that's a fix for a recent release we just create a branch for the >> release, release, tag, delete the release branch - like we'd have do >> it just after the release ignoring all commit in between. >> >> Otherwise you are back to current status = you merge all commit done >> on 2.x on master which is: >> 1) useless >> 2) makes a lot of noise when done >> 3) makes getting started not obvious (need doc) >> >> >> > >> > []s, >> > Thiago >> > >> > >> > On Wed, Jan 28, 2015 at 4:17 PM, Romain Manni-Bucau < >> [email protected]> >> > wrote: >> > >> >> well you shouldn't rebase/merge from a lower to upper branch > IMO - ie >> >> it is always fixed first on mainstream then backported if needed - > or >> >> just dev in the lower version if specific. >> >> >> >> That said this doesn't justify 2.x while master = 2.x >> >> >> >> >> >> Romain Manni-Bucau >> >> @rmannibucau >> >> http://www.tomitribe.com >> >> http://rmannibucau.wordpress.com >> >> https://github.com/rmannibucau >> >> >> >> >> >> 2015-01-28 22:12 GMT+01:00 Thiago Veronezi > <[email protected]>: >> >> > Maybe it can be something like... >> >> > >> >> > Quick bug fix in 2.x.x: >> >> > * You fix your issue in "2.x.x" >> >> > * Call a vote for "2.x.x". >> >> > * The vote passes. You merge "2.x.x" back to > "master". >> >> > * You create a new tag in 2.x.x -> Let's call it > "tag 2.0.2" >> >> > >> >> > Normal 2.x.x release >> >> > * You rebase "2.x.x" >> >> > * You follow the same steps as the ones for "quick bug > fixes in 2.x.x" >> >> > >> >> > This way we avoid the auxiliary branches. We just need to be > sure that >> >> > "2.x.x" is not a development branch. It needs to be > stable. So, once >> we >> >> > rebase it, we need to make it stable before merging it back > to master. >> >> > "2.x.x" is the branch that contains the release > tags. >> >> > >> >> > []s, >> >> > Thiago. >> >> > >> >> > >> >> > On Wed, Jan 28, 2015 at 4:07 PM, Thiago Veronezi > <[email protected] >> > >> >> > wrote: >> >> > >> >> >> Hi, >> >> >> This is what I was thinking... >> >> >> >> >> >> Quick bug fix in 2.x.x: >> >> >> * You create a new auxiliary branch from 2.x.x. -> > Let's call it >> "2.0.2" >> >> >> as example >> >> >> * You fix your issue in this new "2.0.2" branch >> >> >> * Call a vote for "2.0.2". >> >> >> * The vote passes. You merge "2.0.2" back to > "2.x.x". >> >> >> * You create a new tag in 2.x.x -> Let's call it > "tag 2.0.2" >> >> >> * You destroy the auxiliary branch "2.0.2" >> >> >> * You merge "2.x.x" back to master. >> >> >> >> >> >> Normal 2.x.x release >> >> >> * You rebase "2.x.x" >> >> >> * You follow the same steps as the ones for "quick > bug fixes in >> 2.x.x" >> >> >> >> >> >> []s, >> >> >> Thiago. >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Jan 28, 2015 at 3:54 PM, Romain Manni-Bucau < >> >> [email protected] >> >> >> > wrote: >> >> >> >> >> >>> If I have a fix to do in 2.x, where do I code? 2.x.x > or master? >> While >> >> >>> master = 2.x I'm not convinced we need it. Doesnt > solve the need of >> a >> >> >>> release branch while mvn tools are not compliant with > tomee setup. >> >> >>> >> >> >>> >> >> >>> Romain Manni-Bucau >> >> >>> @rmannibucau >> >> >>> http://www.tomitribe.com >> >> >>> http://rmannibucau.wordpress.com >> >> >>> https://github.com/rmannibucau >> >> >>> >> >> >>> >> >> >>> 2015-01-28 21:52 GMT+01:00 Thiago Veronezi > <[email protected]>: >> >> >>> > Please note that having "2.x.x" covers > all the requirements: >> >> >>> > * master is the bleeding edge - it doesn't > need to be stable >> >> >>> > * no code-freeze necessary >> >> >>> > * stable and ready for production > "2.x.x" branch >> >> >>> > * quick bug fix release possible without > interrupting development >> on >> >> >>> master >> >> >>> > >> >> >>> > []s, >> >> >>> > Thiago. >> >> >>> > >> >> >>> > On Wed, Jan 28, 2015 at 3:34 PM, Romain > Manni-Bucau < >> >> >>> [email protected]> >> >> >>> > wrote: >> >> >>> > >> >> >>> >> well while master = 2.x.x I wouldn't > create it but yes (Tomcat >> model >> >> >>> >> basically is nice 1 maintaince branch by N-1 > maintained version + >> >> >>> >> trunk for last one). >> >> >>> >> >> >> >>> >> >> >> >>> >> Romain Manni-Bucau >> >> >>> >> @rmannibucau >> >> >>> >> http://www.tomitribe.com >> >> >>> >> http://rmannibucau.wordpress.com >> >> >>> >> https://github.com/rmannibucau >> >> >>> >> >> >> >>> >> >> >> >> >> >> >> >> >> >
