Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

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 variation of the gitflow model, which is a pretty popular pattern that you might see in the workplace.

Branches

Branches allow us to perform development in parallel, and isolate individual features. There 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). 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.

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.

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 your_great_feature

Once she feels like her code is ready for review, she opens a pull request and puts the code up for review. 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, the changes can 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
  • No labels