Consider teaching people to fork

[danielballan]

No description provided.

[danielballan]

This could take the form of a section on collaboration models:

1. One person working alone (no forks)
2. An informal collaboration (forks of a personal repo)
3. An organization (forks on an upstream repo)

[danielballan]

And borrow from the numpy docs, which are a surprisingly detailed tutorial on getting git set up: https://docs.scipy.org/doc/numpy/dev/development_environment.html#development-environment

[danielballan]

For collaboration across multiple people:

1. Fork the repository.
2. Clone from your fork. git clone https://github.com/YOUR_USER_NAME/REPO_NAME
3. Add the upstream remote git remote add https://github.com/ORGANIZATION_NAME/REPO_NAME.
4. Check out a "feature branch". git checkout -b my-cool-feature
5. Make changes. Remember to git add ... and git commit.
6. Push changes to your fork. git push origin my-cool-feature.
7. Go to GitHub and open a Pull Request.
8. When your PR or others' are merged, bring your local copy of the master branch up to date. git pull upstream master.

[tacaswell]

bike shedding the remote names a bit, githubs tools (hub) pushes you towards 'origin' being the canonical upstream and using user names for all other forks (including your own). I know I have taken a different position before, but have given up.

It also fits the work flow of "clone some repo to install/test it (so it is 'origin'), make some changes, realize you need to make your fork, add it as a remote" which is at least my normal flow through things.

[danielballan]

Yeah, I recently switched conventions myself. I will switch conventions here. We must be careful to make the instructions self-consistent throughout.

[klauer]

👍 on keeping the canonical upstream as 'origin'. I tend to follow the same workflow as @tacaswell.