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 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. There For our use cases here are two main types of branches:

...

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 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!

...

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 yourher_great_feature

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

git push -u origin yourher_great_feature

Once she feels like her code is ready for review, she will squash her branch using an interactive rebase.Alternatively, she could have created the branch via the GitHub UI, in which case she can simply do

git rebase -i 

This will open her editor, allowing her to choose which commits to squash.

pick f33b240 Add some commit
pick 73bbc09 Add some other commit

You can choose which commits to squash by changing pick to squash.

...

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.

Image Added

TL;DR

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