Git Flow

For introduction to git, please see section Git Intro

Spartronics Git Workflow

Overview

The Spartronics Programming Team uses GitHub's fork & pull request workflow. This workflow balances flexibility with productivity for the individual developers.

Individuals have the flexibility of working on their own repos, while
collaborating as a small team, such as pair programming or getting code
reviews from mentors before a pull request (PR)
Standard practice is for developers to push their local repos to their
remote forks, ensuring code continuity and code backup
Programming leads can monitor and review code contributions and ensure
that the master branch is always production ready

Resources

Workflow Steps

Basic git commands and process flow is documented here. If you are new to git, please start with our Git Intro.

Start with forking the team repo on GitHub and cloning your repo on your computer. This command is handy to stay in sync with the upstream branch: $ git pull upstream master.

Make changes on your local repo
Test changes on the robot
git add the changed files
git commit to package and document the changes
git push origin master to send the commits to GitHub
Make a pull request at your fork's GitHub page
Make changes as requested in the review process, and push them to GitHub
git pull upstream master after the pull request is accepted and merged

Top 5 Commands

git status
- Shows the current status of your git repository, including:
  - What files you've edited (shown in red until you git add them)
  - What you've deleted (shown in red until you git add them)
  - What things are ready to be committed (shown in green)
  - Whether you have any conflicts (shown in a different color)
  - Whether your code has been pushed to your fork ("Your branch is up-to-date...")
git add/stage <file1> <file2>
- Adds ("stages") files to the index, which is where git commit pulls
  changes from
- You can just use git add src to add every change you've made inside the
  src folder.
  - Please make sure you actually intend to commit EVERYTHING you change
    inside that folder before you run this.
- Before moving on, it is worthwhile to use git status to double-check the
  list of files you want to add
git commit
- Takes the changes staged by git add and records them as a new commit
- When you run this, it opens the vi editor by default, so you can write a
  message for your commit. See the readme for instructions on using vi
- You can also use git commit -m "your message in quotes here" to write a
  short message directly
git pull
- Pulls down commits from the specified remote
- Most often used like git pull upstream master -- this means "pull the
  master branch from the upstream remote
- You need (well, you should) do this both daily and before using
  git push, to ensure your changes don't cause conflicts
git push
- Pushes your commits to a remote
- Most often used like git push origin master -- "push the master
  branch to origin"
- Do this frequently to make sure your changes are backed up on GitHub

PreviousNext Level Git NextFAQ: git, vi, bash shell

Last updated 4 years ago

Was this helpful?

Overview

The Spartronics Programming Team uses GitHub's fork & pull request workflow. This workflow balances flexibility with productivity for the individual developers.

Individuals have the flexibility of working on their own repos, while

collaborating as a small team, such as pair programming or getting code

reviews from mentors before a pull request (PR)

Standard practice is for developers to push their local repos to their

remote forks, ensuring code continuity and code backup

Programming leads can monitor and review code contributions and ensure

that the master branch is always production ready

Resources

Workflow Steps

Basic git commands and process flow is documented here. If you are new to git, please start with our Git Intro.

Start with forking the team repo on GitHub and cloning your repo on your computer. This command is handy to stay in sync with the upstream branch: $ git pull upstream master.

Make changes on your local repo

Test changes on the robot

git add the changed files

git commit to package and document the changes

git push origin master to send the commits to GitHub

Make a pull request at your fork's GitHub page

Make changes as requested in the review process, and push them to GitHub

git pull upstream master after the pull request is accepted and merged

Top 5 Commands

git status

Shows the current status of your git repository, including:
- What files you've edited (shown in red until you git add them)
- What you've deleted (shown in red until you git add them)
- What things are ready to be committed (shown in green)
- Whether you have any conflicts (shown in a different color)
- Whether your code has been pushed to your fork ("Your branch is up-to-date...")

git add/stage <file1> <file2>

Adds ("stages") files to the index, which is where git commit pulls
changes from
You can just use git add src to add every change you've made inside the
src folder.
- Please make sure you actually intend to commit EVERYTHING you change
  inside that folder before you run this.
Before moving on, it is worthwhile to use git status to double-check the
list of files you want to add

git commit

Takes the changes staged by git add and records them as a new commit
When you run this, it opens the vi editor by default, so you can write a
message for your commit. See the readme for instructions on using vi
You can also use git commit -m "your message in quotes here" to write a
short message directly

git pull

Pulls down commits from the specified remote
Most often used like git pull upstream master -- this means "pull the
master branch from the upstream remote
You need (well, you should) do this both daily and before using
git push, to ensure your changes don't cause conflicts

git push

Pushes your commits to a remote
Most often used like git push origin master -- "push the master
branch to origin"
Do this frequently to make sure your changes are backed up on GitHub