← Home — Code

Git Workflow

We follow a “fork and pull-request” model of software development. At a high level that means that everyone should fork the main repository and have their own version. This allows each developer to have a sandbox to play in without worrying of screwing things up for anyone else. It also means that if you do break everything completely, you can delete it all and fork it again.

Here’s how it works:

1. Fork the main or upstream repository. Now you have your own version of the repository. This is your origin repo.

Let’s interrupt real quick and talk naming. The convention here is that the master branch on upstream is what will be deployed at some point. That means that it needs to be in proper working order. Do not commit directly to master and do not push directly to upstream. Do your branching on your own fork (origin) in order to keep upstream clean.

2. Clone it to your local machine.

3. Create branches for features and bugfixes. These should be intelligently named and end with the issue number, preceeded by a hash (#). spline-reticulator-#11 or fix-data-deletion-#23 are good. fixes is bad.

4. Commit early and often. Commit messages should also be intelligent and describe what changed. It is recommended taking the present tense with commit messages, so that it completes this sentence: "This commit...".
5. Push the commits to that branch on origin (remember this is your fork)

6. When ready, create a Pull Request (or Merge Request on Gitlab). This should have a good title and descriptive message.

7. The developer should assign another developer (or more) to review the PR.
8. Reviewers can comment on code, request changes, or approve the PR.
9. Once approved, the PR can be merged into the master branch.
10. Others can then pull from upstream to get the most up to date code.

You’ll be doing git pull upstream master a lot in order to stay up to date. Frequent smaller commits also helps avoid conflicts.