Hello So a question on gitflow given that commits are now underway. When working on a feature in a local repo which is a branch off the develop branch...do you push the feature branch to the central repo? This then can be merged by someone else as a sort of code review/pull process?
Thanks Joe On Mon, Dec 8, 2014 at 11:40 PM, Joe Witt <[email protected]> wrote: > All, > > Now that we have our code up it is important to establish a process around > git in particular. A general consensus in the thread appears to be that > gitflow workflow is a reasonable option. > > > https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow > > To that end I've added a develop branch off of master from which features > can be built. As we converge toward a release then we'll address/introduce > some of the other aspects of gitflow. > > Please discuss/comment if there are views that we should be taking another > path. > > Thanks > Joe > > On Sat, Nov 29, 2014 at 8:16 AM, Benson Margulies <[email protected]> > wrote: > >> On Sat, Nov 29, 2014 at 3:45 AM, Sergio Fernández <[email protected]> >> wrote: >> > Hi Adam, >> > >> > one remarks about this: >> > >> > On 28/11/14 18:07, Adam Taft wrote: >> >> >> >> Knowing how we work today, if it were me, I would suggest using the >> above >> >> workflow combined with the "forking workflow" to guard access to the >> >> production release (master) branches. A very small subset of the >> >> incubator's commiters should have the ability to merge the "develop" >> >> branch >> >> down to a master "release" branch. >> > >> > >> > Suck workflow is not in place in ASF. On the one hand, the current git >> > infrastructure does not provide such branches' management, like >> > bitbucket/stash do for instance. On the other hand, and more important, >> a >> > project is not hierarchical organization, but a a meritocratic one. >> > >> > I recommend you this blog post in case you want to read a bit more: >> > http://communityovercode.com/2012/05/meritocracy-and-hierarchy/ >> > >> > If someone has permissions to do (i.e., he is a committer), he can do >> it, >> > simple The tool provide you instruments to revert those changes in case >> on >> > involuntary errors. >> > >> >> It would be ideal to have someone who >> >> is NOT performing the majority of changes on the "develop" branch take >> >> this >> >> role to coordinate releases, ensure minimal coding standards, run >> through >> >> unit and integration tests, before signing off on the release and >> issuing >> >> the release artifacts. >> >> You seem to be imagining an individual with a job which is shared in >> by the community. In healthy communities, a release happens when >> there's a consensus to have a release. There is no person who 'ensures >> minimal coding standards', that's everyone watching commits. There's >> no one 'running unit and integration tests' because (a) every >> committer does this before every commit, (b) Jenkins does it, (c) the >> release process does it. (d) there's no signing off on a release. The >> RM puts it up for a vote, and PMC members vote. >> >> >> > >> > >> > Release comes after that. The release manager is responsible on >> creating a >> > proper release, which must include a code release and should include >> > binaries too. Each artifact release must be signed. Demonstrate your >> ability >> > as a project to produce releases is one of the goals of the incubation. >> But >> > we are not yet there, step by step. >> > >> > Hope that helps. >> > >> > Cheers, >> > >> > >> > -- >> > Sergio Fernández >> > Partner Technology Manager >> > Redlink GmbH >> > m: +43 660 2747 925 >> > e: [email protected] >> > w: http://redlink.co >> > >
