-
Notifications
You must be signed in to change notification settings - Fork 1
Source Control
The two philosophies of git:
"Commit early and commit often."
"Branch early and branch often."
To clone the repo to your own computer: git clone https://github.com/zamora18/robot-soccer.git. This will create a folder called robot-soccer on your machine in the directory you are in.
Branches in git allow you to have multiple 'copies' of your repo, each with their own differences and commit history. It's as if you had multiple GitHub repos, except that branches are all in the same repo and are related because the project is the same, albeit in different states. Branches will allow us to have a competition (branch master) state and an in development (branch: develop) state. A similar structure is followed in industry – that way buggy code never touches production servers.
Here is a reference. Mostly, just look at the picture that shows different branches.
Along with the branches master and develop, each person should have their own feature branch, i.e., a branch solely for the current feature being developed by that individual. Typically, these feature branches stay on the developers computer and rarely are pushed to the repo for other developers to see; but in the spirit of transparency, each team member in robot soccer that is working on code or other assets should create a branch (off of develop) for that particular feature/asset.
Branch names should be created using all lowercase with underscores in place of spaces. The branch name should begin with the name of the branch owner, e.g., parker_simulator. These public feature branches should be committed to frequently to allow other members of the team to see what various team leads are working on.
When that feature is complete, the owner of that branch will create a pull request (PR for short). After tagging each team member and writing a short description of the code being merged in, the person who created the PR will merge in their own request. The purpose of this is to notify all other team members of the new code that was added to develop, allowing them to peruse the new code if interested in the changes. See example below.