Git Forking Workflow

We've actually been using this workflow all along to a lesser degree, when submitting assignments.

A forking workflow looks something like this. The idea is that...

One person acts as the git master and creates the main repo. He/she also manages the code that's merged into the repo.
Everyone else forks the main repo so that they have a copy of it. This copy is isolated from the main repo.
In the fork, work is done in branches known as feature branches until the feature is finished.
Once the feature is finished, you'll want to do what's called an upstream pull. This will allow any changes from the main repo to be reflect in your fork. Assuming everyone works in separate branches, this should not create any merge conflicts.
Once the upstream pull is finished, you can push your changes to the Github fork, and then create a pull request. This will allow the git master to merge the changes.
Finally, once the pull requests have finished, pull from the upstream so the latest changes are in the fork.

Setting up the Repo

Choose one person to be the git master
- This person should create a new repository. Let's call it forking-test
- Once the repository is created, clone it to your computer
Once the repo is created by the git master, the other group members should get a link to the new repo and fork it.
- Each group member should clone their forked repo to your computer

Setting up Upstreams

Try running git remote -v. This will be a list of remote repositories. By default, origin is the remote of your fork on Github. We're going to add another remote to reference the main repo, so if there are any changes, they can be pulled from the main repo into the fork.

Group members other than the git master should follow these steps
- Go back to the main repo (not the fork) and copy the SSH link
- cd into your cloned fork
- Add the remote by running in the terminal (pasting the SSH link in lieu of the one provided):

git remote add upstream [email protected]:gitmasterusername/forking-test.git

Testing the upstreams
- Have the git master create a change in the main repo on the master branch. Add the change, commit it, and push it to Github
- Once the git master has pushed changes, group members should try running git pull upstream master

If successful, group members should receive the change in their forks.

Working on Changes

Practice making changes by creating new branches, switching to them, and making commits. Note that the git master should also be working in a separate branch, as not to pollute the master branch. Keep it sacred!

Merging Changes

Once group members have made some changes in separate branches, push those changes to Github, then try making pull requests on Github.

Once pull requests have been made, the git master should go to Github, view the pull requests, and merge them! Or, you can have a conversation about why the changes shouldn't be merged.

Conclusion

The forking repo is one of the widely used git workflows available. It's used to contribute to open source projects, as well as internally by some companies.

Git Forked Flow