I've added a README to https://github.com/TEIC/Guidelines-TEST with some
basic "getting started" advice. Feedback, additions, and corrections
gratefully accepted.
We'll have to establish a workflow policy. Personally, I think that we
should reserve the pull request approach for people outside the committers
list. For big changes that we want reviewed before they are merged into the
master branch I think we should just use branches. What I'd like to do is
try to get people up to speed on using GitHub so that we're all in a
position to comment and then we can establish a workflow. It sounds like
James and I are in agreement about the basics.
On Thu, Jul 30, 2015 at 10:08 AM, James Cummings wrote: Can I ask what the policy for workflow will be on this? In SVN we all have
a copy of the repository, make changes and commit them back directly. I'm
told that the "right" way to do this in git is for us each to fork the
master repository, set this up as a named upstream branch, before working
pull from upstream, do our work, commit back to our repository, push this
to our repository, and then issue a pull request back to the main TEI-C
repository for review before it gets added. Or, if we have rights to do
so, could we just push directly back into the TEI-C repository. (i.e. I find the latter so much easier than the former, though understand
why the former might be technically better if I was doing a huge set of
changes. However, usually we aren't all touching the same set of files at
the same times if my svn notifications are to be believed.) -James On 29/07/15 17:23, Hugh Cayless wrote: All, I've pushed up a copy of the my own synced git-svn copy of the Guidelines
at https://github.com/TEIC/Guidelines-TEST. It's got issues and a wiki
enabled, so we can try those out as we like. Commits to SF should be synced periodically by my server, but changes you
push here will not automatically be sent back to SourceForge (so you can
try it out, with the foreknowledge that they'll probably be deleted).
Currently in-use branches have been copied, but I've not bothered to
create
the old ones (the history is there, but they're not visible as branches).
I've also not bothered to create any tags. This may be something that has
to be done manually, as git tags are not branches, unlike svn tags. I bet
there's a script for it somewhere. If not, I don't think writing one would
be hard. Request for everyone: can you try out cloning and messing with this? In
particular I'd like to know what *doesn't* seem to work, and what the pain
points are. All of them. We will obviously need to develop new
tutorials/documentation for this, so I very much want to know what's
confusing, up to and including "I don't even know where to start with this
git thing". Please don't be shy or embarrassed—you will not be judged.
This
is a new thing to many of us and will be to new members of Council in the
future. GUI clients for those who prefer them are available at
https://windows.github.com and https://mac.github.com. I've zero
experience
with them, but they may be nicer to work with if you're less comfortable
in
the command line. --
Dr James Cummings, James.Cummings@it.ox.ac.uk
Academic IT Services, University of Oxford --
tei-council mailing list
tei-council@lists.tei-c.org
http://lists.lists.tei-c.org/mailman/listinfo/tei-council PLEASE NOTE: postings to this list are publicly archived