Suggestions for how to use GitHub for a large project,
where "large" refers to the number of contributors.
In my opinion many projects should be large, because you
want to encourage new people to contribute.

Suggested setup:

1. There is one "definitive" version of the source.  It resides
in a GitHub repository.  One or more people have control over
that repository.  You don't need to know who they are.

Everyone's goal is to contribute to the definitive version.

2. Every person who want to contribute to that project has
a "fork", which is a repository under their own personal
account on GitHub.  (Those mysterious people who have
control over the "definitive" version:  they also have their
own forks on their own GitHub accounts.)  A fork is a copy
of the definitive version, and your fork is completely under
your control.

3. Everyone who wants to contribute to the project has a copy
of their fork on their own computer.  I'll refer to this as
"the version on their laptop", although their computer might
be a desktop machine, or something in the cloud, or something
else.  (The technical term for "version on your laptop"
is 'clone', but we will not use that terminology. But keep in
mind that the version on your laptop was copied from your fork,
not from the definitive version.)

4.  The version on each person's laptop knows about two
repositories on GitHub:

a) Their own fork, which is called "origin"
b) The definitive version, which is called "upstream".

Both of those are called "remotes" of the version on the laptop.

To summarize, everyone has a version on their laptop.  Everyone
has the same "upstream": it is the definitive version.  Everyone
has a different "origin", which is their fork in their account
on GitHub.

Once all of that is set up, you go through the exact same cycle every
time you want to contribute changes to the project.  But before
we describe that process, we need to know about branches.  (Only at
the workshop will we talk about how to set everything up, because you
don't really need to understand how to do that: you just need to
get it done once, and then  forget about it forever.)

In a big complicated project, like a textbook, there are lots
of different things that may need attention.  Maybe you need to
put in the solutions to the problems in chapter 6, or maybe
you need to add a section on the chain rule in Chapter 4,
or maybe you need to edit the introduction to Section 5.3.

The idea of a "branch" is that you make a temporary copy of the
document for taking care of a specific task -- such as the
examples listed above.  Maybe you plan do take care of all
of the things mentioned in the previous paragraph: well then
you would make 3 different branches, and in each branch you
would be doing something a bit different.

Why is this good?  Many reasons, two of which are:
i) You don't need to mess up the working version of the document,
because you are just working on a copy
ii) Independent actions can be evaluated independently.

Item ii) is significant because of a principle which has not
been mentioned yet:  the process of *suggesting* a change to the
"definitive" version is separate from the process of *accepting*
that change.  This may seem silly if you are thinking in terms of
a single person writing a book.  But if it is a group effort,
and many people are contributing, it makes perfect sense for
all changes to require at least two people: the person who wrote
the new material, and the person who agreed to add that material
to the definitive version.

So, you make a "branch" when you are about to start working on
some aspect of the document.  You may work on that branch for
just an hour, or for several days.  You may switch to working on
other branches.  If it sounds confusing at first, it won't be
confusing once you start doing it, and it is totally worth it.
For example, suppose you have finished making the solutions to
the problems in Chapter 6.  Good, because now you can propose those
changes to be included in the definitive version, and it is
no problem that you have not yet finished the other work you
are going, because those are on different branches.  Juggling
several things has just become easier.

One least bit of terminology:  proposing that the changes in 
a branch go into the definitive version is called a "pull request".
As in "I request that the overlords pull my changes into the
definitive version."  Once they accept your pull request,
the changes from your branch are now incorporated into the
definitive version.

Now that we understand branches, we can describe the process
you will go through every time you want to contribute to the
project.
# comments after each command

git checkout master
# git is the program that takes care of everything
# checkout means to switch branches
# master is the main branch, which you will continually keep
# up-to-date with the "definitive" version

# So now we are on you master branch.

git pull upstream master
# remember that "upstream" is the name your laptop gives to the
# definitive version.  you just updated your master branch with
# the latest definitive version

git branch branch_name
# make a new branch called "branch_name".  choose a short but
# descriptive name for the work you will do on that branch

git checkout branch_name
# recall that "checkout" switches branches.  now we are on the
# new branch you just created.  it looks just like the master
# branch, but once you make changes, those are only on this
# branch: you will not be changing the master.

# now do whatever you want to do on that branch.  occasionally
# you should do

git commit -a -m "useful message goes here"

# "commit" means that you really want the changes you have just
# made.  without the commit, those changes don't really count.
# commit whenever you are about to take a break, and whenever
# you have reached a small milestone.  it is good to commit often.

# now suppose you did all the changes you planned.

git push origin branch_name

# remember that "origin" is your laptop's name for your fork of the
# project in your GitHub account.
# now your fork has a new branch, which you would like to put into
# the definitive version.

# use your browser to go to GitHub, and go to your fork of this
# project.  GitHub knows that you just put a new branch on that
# fork, so you should see a prominent green button on the right
# which says "Compare & pull request".

# click that button and you will see a page with a text box where
# you can describe the changes you have made.  it is considered
# polite to describe where those change can be seen (in the final
# product, not in the source files) so that the reviewer can
# take a look at what you did.  for example "new exercises in
# section 3.2, see page 88".

# then click the green "create pull request" button.
# you are done.

# you are done with the work you planned for that branch, but
# probably you want to do something else.  so it is a good
# idea to do

git checkout master

# so that you are back on your master branch.
# you might also want to do

git pull upstream master

# so that you will have any new changes since the last time you pulled.

# when in doubt do

git status

# and it will tell you what branch you are on, and if you have any
# uncommitted changes.

--------

What might happen next?

Hopefully someone with control over the definitive version will
accept your pull request.  But maybe they want you to make some
changes; perhaps they found a typo or other error.  No problem:
just checkout that branch again, make the corrections, commit,
and push the changes to your branch on your fork.  Your pull request
will be automatically updated.

It may happen that you (the person who made the pull request)
are also a person who has control over the definitive version.  In that
case you can actually go the definitive version on GitHub and accept
your own pull request, However, many projects adopt the policy that
people are not supposed to accept their own pull request.  You need
to work that our with your main collaborators.