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?
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.
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
On Thu, Mar 15, 2012 at 10:21 AM, Tim Donohue wrote:
>
> 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 perform a "Fork &
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: http://help.github
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 c
On Fri, Mar 09, 2012 at 10:36:58AM -0500, Chris Wilper wrote:
[snip]
> The workflow I like to follow is: While the work is in a local branch,
> commit early and often so I can rollback easily if I do something dumb
> a couple hours from now. Then, before pushing to origin, do surgery on
> the commi
Hi Mark,
On Fri, Mar 9, 2012 at 9:20 AM, Mark H. Wood wrote:
> While reviewing the IRC discussion, I came across something that
> seemed to want comment.
> [..]
Good post. I was glad to see that the vote to move DSpace code to
GitHub was a landslide. Although the tools should not dictate the
wor
While reviewing the IRC discussion, I came across something that
seemed to want comment.
There's some talk about how, when using a single central VCS (like
Subversion) one tends to let developing code sit around unprotected
until it's perfect and then commit a big bag of changes, while Git
lets yo
