On 21/04/2015 00:35, Vladimir Panteleev wrote:
<snip>
In the other thread I referred to this
http://stackoverflow.com/questions/5010754/github-collaborators-have-commit-access
which makes it sound as though it's possible to do the same thing in GitHub.
Is that
page wrong?
This question pertains to private GitHub repositories (a feature of paid plans).
One of the comments there: "Or you make your repository public, then everyone (who is not
a collaborator) has read-only access"
And everyone who _is_ a collaborator has what?
Regardless, I do not recommend attempting to shoehorn your previous SVN
workflow into git
and GitHub. The usual way contributions are done with GitHub is that anyone
with a GitHub
account can create a pull request (a series of commits, initially published on
their own
fork of the repository), which the repository owner (or collaborators) can then
accept
(merge) into the main repository.
https://en.wikipedia.org/wiki/Fork_%28software_development%29
implies that a fork is a divergent development branch - a separate copy of the project
that has no ongoing link to the original. Is the Git concept of a fork different?
Instead of designating a group of committers as in SVN,
you would simply need to review pull requests and click the "merge" button to
accept them.
If you do not foresee yourself being available often enough to review/accept
pull
requests, you can designate a few collaborators who can do it as well.
Maybe I'll do that. Most of the time I should be available enough, but there's always the
chance that I'll be away for a week every now and again (possibly longer if I'm lucky).
Stewart.
--
My email address is valid but not my primary mailbox and not checked regularly. Please
keep replies on the 'group where everybody may benefit.
