Question about collaborating on GitHub Projects

I am working with two other people on a project for school. The goal is intended to be a course registration system. I have only used GitHub for my own projects, so if the other person adds the starting code to their own repository how would that work for me? Like, what if I wanted the repository on my GitHub page so a potential job recruiter could see it?

Github acts as a “remote” source for code. You will be working locally and will push your changes to your repo on github. You can also pull changes from github to update your local repo with those changes. In this sense github can be though of as a “shelf” where you can push/pull changes to/from. Other’s will have a similar experience.

There’s essentially 2 ways to work with others using github+git.

  1. A “fork” based flow, which is used for most open source projects.
  2. Multiple contributors on the same repo

The “fork” flow is where one person(s) (the maintainer or maintainers) has the “rea” repo, and other’s fork it. (the button in the upper right)

From there the forked repos start the same, but are essentially just copies of the original repo. Any changes made in the fork aren’t automatically carried over to the original repo. This is where pull request come in, where a fork can open a PR to make changes back to the original repo. This allows the original maintainers to review/merge/reject those changes.

This flow is more convoluted, as it requires more work on those who want to contribute but lets maintainers “protect” their codebase over time, as anyone can see the code and contribute, but only through this pull request+review flow. Anyone who forks the repo needs to update their fork over time from the original, and possibly deal with issues related to changes to what they were working on (merge conflicts).


The other approach, is where you give other github users direct access to your repo as contributors. In this flow they have as much permission as the “maintainer” or owner of the repo in regards to contributing directly to the repo it self and changing the code directly through push and pulls from their local changes.

This would mean they can delete the code, update, and push directly to the repo without any review flow. You can still go through a review flow, where instead of creating a pull request from a fork, you do it from a branch, but the choice is more up to you.

I personally would just add them as contributors to your repo and give them write access. Then decide if you want to use pull requests or not.

In both flows you can still end up with merge conflicts, as changes you make locally might collide with changes on github, or on other contributors machines. Dealing with these is out of scope of this reply though. Just in general you should plan who is working on what, and keeping the amount of changes pushed at a given time to a minimum. Its easy to figure out a single merge conflict between a few files. Its another to try to merge everything last minute. Commit and push often


Regardless of which approach you take, as long as the repo is set to public, it will appear on your github profile. A fork will be your “copy”, or if your a maintainer, you can add it to your github profile, even if the repo isn’t under your name.

In both cases you should document who the contributors are in your README on the “original”.

1 Like

If you want to have your own copy of the project that you control, then I would suggest creating a fork when the class project is done. If you’re not wild about the project itself and just want your GitHub profile show that you participated in it, that will be in your contribution history regardless of who controls the repo.

Honestly though, I wouldn’t sweat it too much. Few prospective employers are likely to look at your GitHub profile and any who do probably won’t care about school projects.

1 Like