The only commands you need to know

Git has many commands and options but you will only use a small fraction of them in everyday use. The following 11 commands will get you through 99% of use cases:

Setup

1. Create a github account (if you do not already have one)
2. Create a fork of http://github.com/jeresig/processing-js
3. Clone your fork

After you first clone your forked repository there are a few setup tasks you should perform which will make your life easier down the road.

Adding remotes

Remotes are named shortcuts to other repositories you plan on working with. By default a remote named “origin” will be created pointing to the repository you cloned from (your public github repository).

You will need to create a remote named “upstream” which refers to the super repository you forked from (jeresig/processing-js).

git remote add upstream git://github.com/jeresig/processing-js.git

Add remotes for fellow processing-js community members

git remote add annasob git://github.com/annasob/processing-js.git

git remote add asalga git://github.com/asalga/processing-js.git

git remote add asydik git://github.com/aSydiK/processing-js.git

git remote add dhodgin git://github.com/dhodgin/processing-js.git

git remote add mlam19 git://github.com/mlam19/processing-js.git

List all remotes

git remote -v

Work flow

Follow the beaten path and you will not fail.

Before we get started I want to stress 2 rules:

1. Check the status of your working directory often!

Get in the habit of checking your status. When you are not sure what you added, what branch you are on, if you made changes you haven’t committed yet, etc. You cannot run this command enough. Run it before you do anything! This will help you catch mistakes before they happen.

git status

2. Double check that what you are changing is correct

If git status looks fine, check the diff to make sure you didn’t leave in any test code, changed something you shouldn’t have, etc.

git diff

Running git diff with no arguments will take a diff of your current directory vs. your last commit.

If you have already added files to the index you can diff the index vs the HEAD commit.

git diff HEAD

Adding and Committing files

This is your basic everyday workflow for adding and committing files. Update a file in your working tree, add it to the index, and then commit. It doesn’t get much simpler than that but many people new to git are prone to making mistakes and end up making dirty commits.

SVN users new to git will often try to skip the adding phase and will use the git commit -a shortcut to add all modified files to the index and commit. Ooops you just committed your database config file by mistake with your username and password, or your Makefile with custom path, or a bunch of scratch files which will be propagated to anyone who merges your patch.

When adding files don’t take any shortcuts. Be aware of exactly what you are adding and more importantly NOT adding before making a commit. You do this by adding each file individually.

1. Check which files have updated

First I run git status and it shows me that I am on branch 0.6. The status is divided into 2 sections Changed files and Untracked files. I can see that there are 2 changed files and 1 untracked file. In this situation I am only interested in adding the changes I have made to processing.js to the index. The Makefile contains a custom path to my js-shell, I don’t want that committed.

zetagun processing-js.0.6 $ git status
# On branch 0.6
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#  modified:   Makefile
#  modified:   processing.js
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#  test/unit/not_ready_to_be_added.pde
no changes added to commit (use "git add" and/or "git commit -a")

2. Check the diff

If you know you are only going to be adding one file you can specify the file you wish to diff in order to filter out any changes from the Makefile for example.

zetagun processing-js.0.6 $ git diff processing.js

Everything looks good so it is time to stage this file.

3. Stage the files to be committed

Next we add the individual processing.js file and then run status again to doublecheck that everything is correct.

zetagun processing-js.0.6 $ git add processing.js
zetagun processing-js.0.6 $ git status
# On branch 0.6
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#  modified:   processing.js
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#  modified:   Makefile
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#  test/unit/not_ready_to_be_added.pde

Now we can see that status is showing us 3 different sections, Changes to be committed (files added to the index), Changed, and Untracked. The processing-js file is now staged to be committed.

4. Commit

You now know exactly what is going into this commit with no surprises. Let’s commit.

zetagun processing-js.0.6 $ git commit -m "#123 Fix bug in stroke for 3D context."

The -m option allows you to include a commit message, it is a good idea to use the number and title from the lighthouse ticket.