Maybe even simpler than that. Git and GitHub give us a lot of
flexibility for different contributors to work in the ways they find
best. Maybe the questions we need to answer are: are there any patterns
that we want to avoid? Can we set the tools up to prevent them
without undue complication?
Hi Mark,
Yes, you are correct of course. The two approaches are not mutually
exclusive. But, I do feel we need to develop our own best practices
around which approach(es) we recommend for which cases.
In other words, if all the Committers are taking different approaches to
collaboration, then
Maybe a more simple perspective.
1.) Fork, Pull and Branch is best for non-commiters and external projects.
IE, if your going to run a local DSpace instance and want to maintain your
customizations in github or if you are working on addons or other fun
things that are not considered central.
2.)
Mark,
Thanks for beginning this Git Workflow discussion! From all I've read,
it seems like one of the first decisions we need to make is which
collaboration model we'd like to use.
Namely, GitHub suggests there are two main Collaborative models they've
seen (described at:
On Thu, Mar 15, 2012 at 10:21 AM, Tim Donohue tdono...@duraspace.orgwrote:
2. Shared Repository Model
In this model, Committers develop directly in the main repository
itself, and make heavy use of branches to isolate individual changes.
(However, non-Committers would likely still need to
Hi Mark,
I see a potential for Git to facilitate a workflow that denies us early
profit from (anyone with access to the repo. can start to review, use,
and build on your work), because you get (your work is protected from
mishap) and (you can easily roll back changes that didn't work out)
by
