-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 After reading over the link Akkaash sent and doing a little more research, I think we'd be okay with the "Feature Branch Workflow". However, if we really want to get structured, we could move up to the "Gitflow Workflow".
It seems like the Feature Branch Workflow is really similar to how we currently work with subversion, except that with subversion, our "branches" are just our local working copies. When I have something to work on, I make sure my local copy is up to date, then do the work, then commit it back to trunk. If changes have been made in trunk to the files I'm committing, I have to merge those changes in to my local copy before I can do the commit. With git, we'd actually be creating branches for doing work, which would definitely provide some great benefits, but I feel like the workflow would be really similar. Josh On Wednesday, June 10, 2015 11:03:51 AM Andy Kurth wrote: > On Tue, Jun 9, 2015 at 1:47 PM, Mark Gardner <[email protected]> wrote: > > Switching to git (well DVCS of any kind) from subversion will require us > > to > > have a discussion of workflow as there was only one way to work with > > subversion but git is more of a version control toolkit (even more than > > other DVCS tools). Workflow will be where people will feel most lost right > > after the change. > > > > Mark > > -- > > Mark Gardner > > -- > > Good point Mark. It is not appropriate at this point to have a vote or > make a request to infrastructure. It would be helpful if the workflow was > discussed/planned/documented before switching. This would be very > beneficial for both committers and non-committers. > > The link Akkaash sent is a good starting point. I haven't worked much with > git so this is helpful. Things I'd like to be worked out and documented > (actual git commands should be included for all of these): > -General development workflow for committers > -Workflow for non-committers who are interested in contributing code/patches > -Workflow for creating a release > -How to handle major vs. minor/bugfix releases > > On a related note, migrating to git affects how we plan for the next > release. We never created a post-2.4.2 bugfix branch in subversion and > some commits have been made to trunk which should have probably been > mirrored into a bugfix branch. We need to decide how to handle this. > Should we create a bugfix branch in subversion from the 2.4.2 tag before > the migration to git and apply changes made to trunk, or work this out > after migrating? > > -Andy - -- - ------------------------------- 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----- Version: GnuPG v2 iEYEARECAAYFAlWIZOAACgkQV/LQcNdtPQNfdACffN8fgQDPU2VUBmBUUo1LD9U0 ZNwAnieblZS8WqWN6gFetDqvK/sRzB1e =Wy/l -----END PGP SIGNATURE-----
