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 puppet.shop.lan. 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> @ shop.freegeekvancouver.org
# Configure my name git config --global user.name "Tyler Hamilton" # Configure my email git config --global user.email "firstname.lastname@example.org"
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.
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.
If you have write access to the original source:
# Push changes back to source git push origin
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 github.com 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.