Throughout your time in the co-op program (and in your future careers), you'll likely encounter a few different Version Control Systems, and various workflows that each team and company finds works for them. We use a simplification of the gitflow model, which is a pretty popular pattern that you might see in the workplace (minus the release branches).

Branches

Branches allow us to perform development in parallel, and isolate individual features. For our use cases here are two main types of branches:

• master (or the integration/release branch)
• feature branches

master

We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state (or a state with the latest delivered development changes for the next release). This means that any code that is in the master branch has been reviewed, tested, and signed-off by at least one of the Software Leads, and we should be able to clone the repository and flash the firmware onto a board without any issues. The only way to get code on the master branch is through a pull request.

Note: You should never, ever commit directly to master!

Feature Branches

All development is done in feature branches, before being merged into master.

A feature branch is branched off the master branch, and development on that feature happens in parallel with master. When development is complete, a pull request is submitted, after which it is merged back into the master branch.

Pull Requests

All code that is to be checked in will be reviewed and merged through a pull request. Pull requests can be created from the GitHub UI, and should target the master branch.

Naming Conventions

A pull request title should be in the format

JIRA-#: Short Message Here

If there is no JIRA ticket number, create a JIRA ticket for the commit.

Also, write your commit message/pull request title in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug." This convention matches up with commit messages generated by commands like git merge and git revert. If ever in doubt, try filling in the blanks

If you apply my commit, it will ___________

ELEC-19: Add FSM implementation

Sample Scenario

Alice is working on a project. She clones the repository

git clone https://github.com/uw-midsun/some-repository.git

and then creates a new feature branch.

git branch -b her_great_feature

Because Alice is a good developer, she routinely makes commits and pushes them to the remote repository (GitHub).

git push -u origin her_great_feature

Alternatively, she could have created the branch via the GitHub UI, in which case she can simply do

git push

Once she feels like her code is ready for review, she opens a pull request and puts the code up for review.

Continuous Integration Checkpoint

Now that your branch is pushed to origin and a Pull Request has been opened, the CI server will kick in. For feature branches, we will be running code linters and of course the unit tests against all the files in the repo. If the CI build fails, check the logs and push new commits to fix the issue.

Code Review Checkpoint

A Software Lead will work with her to review the code, and she'll make any changes, commit them, and add them to the review. Once this is approved by at least one Lead, the changes should be Squashed and Merged.

TL;DR

1. Create feature branch
2. Perform development in feature branch
3. Routinely push commits to remote tracking repository
4. Create a pull request and put code up for review
5. Make changes as necessary
6. Squash and Merge into master