Thanks for starting this Josh! You mentioned and linked to the "Gitflow Workflow". There are endless Git workflow arguments on the web. *IMHO, Git workflows are like diets -- you'll always find a contrarian who's more than happy to explain why yours is doomed.* But anyway, I think we should think about what our goals are and design a workflow around that.
I think a primary goal should simplicity/ease of use. With that in mind, I'm wondering what value does maintaining an additional *develop* branch buy us? I'm mainly concerned about what may be the default workflow for a non-committer who hasn't found or read our dev docs and hasn't examined all of the branches in the repo. This could happen: * Clone the *master *branch * Work on something (yay!) * Do some git pulls throughout development (hmm, VCL releases are few and far between, not much is changing, no conflicts to worry about) * Try to contribute it via patch or PR (yay!) * Work is based on *master*, *develop *is now very different, contribution is now extremely difficult to merge and parts of it may now be irrelevant (fail!) We have seen this sort of thing happen with Subversion where someone checked out the last release (not trunk), did some major work, then hoped to contribute it. I'm thinking something more akin to the Forking Workflow <https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow> would be an improvement. Other ASF projects are using something similar: https://deltaspike.apache.org/suggested-git-workflows.html https://bookkeeper.apache.org/community/contributing/ https://cwiki.apache.org/confluence/display/COUCHDB/Git+Workflow I think a forking model coupled with using PRs would have a few benefits: * People would fork to their own repo. Work however they want. Branch/pull/rebase/push *(to their own repo)* however they want as they develop. * Using PRs will add a code review process. We have never done this but it will be useful. It will help eliminate poor quality commits to master, features being committed but never totally finished/refined, and horrendously lacking commit messages. The VCL dev community and activity level is *svelte *enough that this shouldn't be much of a burden. * Project continuity - having other committers examine and review parts of the code they ordinarily don't work on can't hurt. * Forked repos may be tracked/linked/visible from the main VCL Github repo. This will better let us see who is active. Having additional repos, if public, may also help improve the project's visibility via search results. Either way, the devil is in the details. Git can be highly user unfriendly. One thing I think we need and I'd be happy to help contribute is a bunch of cookbook style git commands in the documentation. Thoughts? Thanks, Andy On Mon, Apr 30, 2018 at 2:15 PM, Josh Thompson <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > All, > > I created the following page to explain how to work with our Git repo > using > the Gitflow workflow. Please review the page and see if it seems > sensible. > Feel free to edit it. Once we get it to a point we agree it works, I'll > remove the line at the top about it being in a draft state and then link > to it > from the navigation area. > > https://cwiki.apache.org/confluence/display/VCL/Working+With+Git+Source > +Control > > Thanks, > Josh > - -- > - ------------------------------- > Josh Thompson > VCL Developer > North Carolina State University > > my GPG/PGP key can be found at pgp.mit.edu > > All electronic mail messages in connection with State business which > are sent to or received by this account are subject to the NC Public > Records Law and may be disclosed to third parties. > -----BEGIN PGP SIGNATURE----- > > iF0EARECAB0WIQRMIdRtWXideTZDK31X8tBw1209AwUCWuddPwAKCRBX8tBw1209 > A1TSAJ9EkIFyJCFYzycndm9fmnZHVZBHgACfRXZ4L/hhBjTDB8vYxoDbRZp5jgk= > =0ZVj > -----END PGP SIGNATURE----- > > > > -- *Andy Kurth* Research Storage Specialist NC State University Office of Information Technology P: 919-513-4090 311A Hillsborough Building Campus Box 7109 Raleigh, NC 27695
