Git for dummies
The basics: What you need to know
Setup
Set up your system:
sudo apt-get install git-core git config --global user.email somebody@somewhere.tld git config --global user.name "John Doe"
Note that if you are using debian etch, you will need to get a backport of git from backports.org.
Getting the repo
Get a copy of the library project (assuming the central repository is on a server named dev.freegeek.org):
git clone dev.freegeek.org:/git/library cd library/
Sort of like svn update:
git pull
Like svn update (but if you have local commits):
git fetch git rebase origin/master
(Master is like trunk is in svn.)
Making changes
Now edit a file
vi TODO
(See it's just like svn!!)
Now schedule this modification to be committed locally:
git add TODO
Want to see changes that you hain't yet git added?
git diff
Want to see what you are about to commit?
git diff --cached
Now commit it locally:
git commit
Now, if you want to commit all of the changes you've made, but don't want to "git add" a million files, you can shorted it to this:
git commit -a
The -a tells git to commit "all"
If you screw up changes to a file, and just want to put it back:
git checkout myfile
think of checkout (when used like this) as the git equivalent of "svn revert".
Now send your locally committed changes to the main repository:
git push
Cool toys: What you want to know
also known as "candy for the coders".
cool settings
TODO
git-rebase -i
TODO
reverting a commit
yes, you can rebase out a commit. But never make changes to commits that have already been pushed. The correct way to "undo" a pushed commit is to do this:
git revert SHA1_HASH_GOES_HERE
git-add -i
TODO
Complicated stuff: What you really don't want to know
Referencing a commit
TODO
Wtf is a refspec
TODO
Branches
TODO
Merging
TODO: explain how to merge
If you are going to merge something, for now make the changes in the branch, then merge it into trunk. This way it is tracked correctly. While cherry-pick can be used to get one commit from trunk into the branch, it does not track it as a merge.
Tags and all the associated evil
TODO
The evil: once you push a tag, it's final. you can push a new version of the tag, but anybody who has already fetched the tag will not even know about the change. When you screw up a tag, you have to either send out an email instructing people to delete the tag and refetch it or use a different tag name. Not a good thing to do. There is reasoning behind this, though. Git is targeted towards security, and works by the concept that if you know the 40 character SHA1 hash of the most recent commit, you can trust the entire tree of commits.
The index
So, with git you have multiple places where changes are "kept":
- remote repository
- local repository
- the index
- your working copy
The index is where you "stage" changes you are about to commit. git-add takes changes from your working copy and updates the index to match (this was called git-update-index in previous versions of git).
After you edit the file (in your working copy), there are a few steps to get it to the remote repository.
From working copy to index:
git add file
From index to local repository:
git commit
From local repository to remote repository:
git push