From FGWiki
Jump to: navigation, search


Git is a Revision Control System. It is used to track changes to software and system configuration at Free Geek.

Free Geek Vancouver uses git in a more centralized manner. A main repository for most applications is kept in gitolite on This way updates can be automatically deployed in a repeatable and trackable manner.

Common git commands

Configure your identity for git

The first thing you should do on a system is tell git who you are, you only need to do this once. All users on FreeGeek systems have an email address which they can use of the form <username> @

 # Configure my name
 git config --global "Tyler Hamilton"
 # Configure my email
 git config --global ""

Getting a copy of a repository

See instructions in Gitolite.

Updating from the source

If the original repo changes you will want to get a copy of those changes, this will usually be done at the start of every session

 # Update to current
 git pull

Making changes to a repository

Let's assume you have edited some of the files in ~/src/puppet/site and want to save those changes.

 cd ~/src/puppet/site
 # Get a list of what has changed
 git status
 # Mark a file as belonging to this commit, you can do this for multiple files at
 # once or multiple times before commiting
 git add <filename>
 # Show the differences which are about to be commited
 git diff --cached
 # If you are satisfied with the changes
 git commit


Often it is very nice to develop a specific feature in a way which seperates it from other things you may be working on. Git supports branches which allow you to keep one repository with many features seperate from each other.

 # Create a new branch splitting from the current branch
 git checkout -b <new_branch>
 # Now any commits will be on this new branch, seperate from other features and seperate from the master branch
 # ... sometime later after some commits
 # Create a set of patches for all changes on this branch since splitting from master
 git format-patch master
 # Switch to another branch (in this case back to master)
 git checkout master
 # At this point let's say the feature is good enough to include in master
 # on branch master do
 git merge <branch_name>

Feel free to experiment, if you screw up a repository you can always delete it and reclone from the source. Also refer to documentation and guides on the web.

Sharing changes

So far we have only made changes to your personal copy. To be useful we need to share those changes and there are a couple of options.

Write access

If you have write access to the original source:

 # Push changes back to source
 git push origin

Patch file

If you would like to submit the change as a file suitable for inclusion on a ticket:

 # Create patch file for the last commit
 git format-patch HEAD^

This will leave a file in the directory named something like 0001-Fix-foo-bar-issue.patch, attach that file to the issue for somebody with write access to the original repo to commit.

Publish your copy

The final option is you could publish your copy someplace where other people can read it. How exactly to do this is beyond this guide, but someplace like might be a good start. Once your copy is published you can then let the original owners of the code know where the changes are and which ones they may be interested in.

Learn more

There is much more to know about git, a good starting place would be the git tutorial. For more information refer to the documentation.