PR's are certainly convenient. There's no much difference, for a committer, between pushing a branch to the official repo and pushing a branch to some personal repo on github. The same integration workflow can be used either way to close out the PR upon merge.
However, in a CTR project, it seems perhaps excessive to _require_ feature branches for small fixes as opposed to just committing them directly to develop. At day job we do mostly do branch-per-jira, but some people might find that onerous. Pushing to the official repo leaves more history that someone might find interesting some day. Also more clutter; some people are very concerned about repacking before merging to develop. Another issue with gitflow is the master branch. The master branch is supposed to get merged to for releases. The maven-release-plugin won't do that, and the jgitflow plugin is unsafe. So one option is to 'use gitflow' but not bother with the master versus develop distinction, the other is to do manual merges to master at release points. On Tue, Dec 9, 2014 at 10:22 AM, Joe Witt <[email protected]> wrote: > 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 > >> > > > > >
