- excellent intro to version control and git
- git book (online and available in print)
- the best "gentle introduction" to git that I've found.
- excellent introductory screencast. about an hour long, but well worth it
- a nice intro to using git-svn.
- some tips for emacs and git-svn
- git from the bottom up
If you're trying to use a non-default ssh key with git (e.g. for github) then this will help: http://help.github.com/multiple-keys/
if you've got a local branch that's not tracking a remote you can tell it to do so:
$ git branch --set-upstream master barrel/master
you can use git aliases to create your own git subcommands. here's an example of creating a very useful
- Handy Git tips to stop you getting fired
- a simple git branching model. a nice antidote to a few very complicated models I've seen floating around.
You can store your "dotfiles" in git, too, which is especially great now that we do so much work inside virtual machines. There seem to be two schools of thought:
I'm trying the first approach. It seems less complex.
Setting up a new machine looks like:
$ git init .
$ git remote add caboteria ssh://user@host/path_to_repo/dotfiles.git
$ git fetch caboteria mitre:caboteria/mitre
$ git checkout -fb mitre caboteria/mitre
- turns out there's a group of people that talk about how they've done this.
Some firewalls stomp on the git protocol so if you want to clone using URL's that start with "git:" you'll need to use a proxy to tunnel the git protocol over a different protocol like ssh (assuming the firewall lets ssh through).
Add a few lines to your
to tell git to use a proxy by default but to talk directly to machines inside your firewall:
gitproxy = "none" for "your-company-domain.com"
gitproxy = git-proxy
executable file somewhere on your path (
). Here's the contents of my
echo "proxy to $1:$2 via ec2" >&2
exec ssh ec2 nc "$1" "$2"
In my case "ec2" is a host on the public internet that I have set up passwordless ssh access to. You'll need to use a different host.
I usually don't like to have programs like this output anything, but in this case I emit one line because the proxy should run sometimes but not others so it's handy to see whether git has decided to run it or not.
The only downside of this is that you need to use fully-qualified domain names for machines in your corporate domain, because git uses the domain name to decide whether to use the proxy or not.
git, ssh, and cron can be a fussy combination. When debugging crontab's that involve git and ssh, it's often helpful to wedge a small script between git and ssh:
/usr/bin/ssh -vvv "$@"
Tell git to use this script with the
git filter-branch --index-filter 'git rm --cached --ignore-unmatch filename' HEAD