Git
References
- Git Home
- Git Tutorial
- Git on Ubuntu
- Pro Git
- Git, from the bottom up
- Linux Greatest Invention
- Tech Talk: Linux Torvalds on git
- Git cheat sheet
Introduction
Git Features:
- Reliability
- Performance
- Distributed
Distributed
Originally from BitKeeper. Other distributed SCM is Mercurial.
- No single repository. Everybody always has his own copy of the repository. The repository content is pulled from other people's repository.
- No politics, no commit access control. All work is always done locally, so there is no need to define such politics.
Reliability
Every change, file, directory, etc. is cryptographically hashed (sha1sum).
- Easy corruption detection. Any tampering to a file or directory content (either malicious or because of hardware failure) is immediately detected.
- Easy distribution. Moreover because the repository is distributed all over the place, it is very easy to repair a given repository. You only need to drop all broken objects, and get all missing objects from a remote copy.
Performance
Very fast commit. Local repository
Terminology and Concepts
- commit
- A commit is a snapshot of your working tree at some point in time. There are different ways to name a commit:
- branchname — a branch name is an alias for most recent commit on that branch
- tagname — similar to a branch alias, but that does not change in time
- HEAD — currently checked out commit
- c82a22c — the SHA-1 hash id of the commit (can be truncated as long as it remains unique)
- name^ — the parent of commit name
- name^^ — the grand-parent of commit name (and so on)
- name^2 — the 2nd parent of commit name (and so on)
- name~10 — the 10th ancestor of commit name (same as name^^^^^^^^^^)
- name:path — reference a specific file/directory in a given commit
- name^{tree} — reference the tree held by a commit
- name1..name2 — a commit range, i.e. all commits reachable from name2 back to, but no including, name1 (if either name is omitted, use HEAD instead)
- name1...name2 — refers to all commits referenced by name1 or name2, but not by both. For
git diff
, refers to all commits between name2 and the common ancestor of name1 and name2. - master.. — to review changes made to the current branch
- ..master — after a
fetch
, to review all changes occured since lastrebase
ormerge
- --since="2 weeks ago" — all commits since a certain date
- --until=”1 week ago” — all commits up to a certain date
- --grep=pattern — all commits whose commit message matches the regular expression pattern.
- --committer=pattern — all commits whose committer matches the pattern
- --author=pattern — all commits whose author matches the pattern
- --no-merges — all commits in a range that have only one pattern (i.e. ignore all merge commits)
- detached head
- When HEAD is no longer a reference to anything (like ref: refs/heads/branch), but instead contains the actual hash of a commit.
git checkout -b newbranch # To attach HEAD back on a new branch...
- hunk
- individual change within a file (basically a file diff output is made of a sequence of one or more hunks).
Install
Packages:
- git-core — the main program
- git-gui — a gui front-end
- Web interface:
- gitweb
- ViewGit
- git-doc — documentation
- Project management:
Other handy tools:
- tig — a text-mode repository browser interface to git and color pager.
tig # launch browser
git show | tig # Use as pager. Colorize output of git-show
- gitview Git Repository browser
- gitg — a Git repository browser targeting Gtk+ / GNOME Version delivered with Lucid/Maverick is a very old one. Compile from the sources to get the latest version. Alternatively the repository ppa:pasgui/ppa contains a more recent version.
- qgit — A graphical interface to git repositories using QT
To install the repository, create a file /etc/apt/sources.list.d/pasgui-ppa-lucid.list (change lucid as necessary):
deb http://ppa.launchpad.net/pasgui/ppa/ubuntu lucid main
deb-src http://ppa.launchpad.net/pasgui/ppa/ubuntu lucid main
Then add the apt key:
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys F599ACE3
Configuration
References:
- Git Community Boot - Customizing Git
- Git handy feedback on command-line
Global per-user configuration settings are stored in file ~/.gitconfig
- Add color to git output for all commmands:
- Define author/email
- Add some frequently used aliases:
git config --global color.ui true
git config --global user.name "Your Name"
git config --global user.email you@example.com
git config --global alias.st 'status'
git config --global alias.ci 'commit'
git config --global alias.co 'checkout'
git config --global alias.br 'branch'
git config --global alias.last 'log -1 HEAD'
How-To
Here we shall describe how to perform some tasks in Git.
Getting git to a server
Reference: [1]
Clone a local repository to remote server griffin, through ssh. Repositories are all stored in a directory repositories/ in home directory of remote user git :
git clone --bare my_project my_project.git # Create a bare clone of your repository, if not available yet
scp -r my_project.git/ git@griffin:repositories/ # Copy the repository to server - requires SSH access
Now any other user that has SSH access to git@griffin may get a copy of that repository with
git clone git@griffin:repositories/my_project.git # Clone repository and create working tree in my_project/
Now, the user that created the repository at the first place can
- either delete his own repository and clone the remote one as any other user,
- or more safely, he can tell git to add the remote repository and set up tracking branch for master:
git remote add -f origin git@griffin:repositories/my_project.git # Add remote repository and fetch automatically
git remote set-head -a origin # Set origin/HEAD automatically - see man git-remote, set-head
git branch --set-upstream master remotes/origin/master # Set master to track remote branch master from origin
See #git-clone git-clone below for more details.
Mirroring
Reference: [2]
Commands
Here we'll summarize how to use some of the Git commands
git-clone
The command git clone /dir/repo/project.git
is identical to running the following commands:
git init # Create an empty repo
git remote add -f origin /dir/repo/project.git # Add a remote repo called 'origin' and fetch
git set-head -a # Set default remote branch for remote 'origin' automatically
git checkout --track origin/master # Create a tracking branch 'master', and update working tree
Another equivalent option for last command is git checkout -b origin origin/master
(since the start-point is remote, git creates a tracking branch).
Some variants:
- To get a local copy of a remote repository, but without changing the working tree (i.e. keeping all local changes), just change the last command to:
git init
git remote add -f origin -m master /dir/repo/project.git
git branch --track master origin/master # Branch 'master' set up to track remote branch 'master' from 'origin'
- To merge remote branch locally, but without creating a tracking branch, change the last command to :
# ...
git merge origin/master # Merge
git-remote
- git-remote set-head
- Sets / deletes the default branch for a remote. For remote origin, this creates the reference refs/remotes/origin/HEAD with content ref: refs/remotes/origin/master if default branch is master.
Use set-head to follow the changes in another branch than the default one:
git remote set-head origin exoticbranch
git diff remotes/origin # Show diffs with remote branch exoticbranch from origin
# ... shortcut for git diff remotes/origin/exoticbranch
git-rebase
TBC
Tips
Frequently Used Commands
git commit -a # Add all changes and commit in one pass
git commit --amend # Amend tip current branch (message, add some files) - also for merge commits
Working the Git Way
- Check project diff before
commit -a
: - Give
git commit
a directory argument instead of using-a
: - Clean up an ugly sequence of commits ([3]). Better than hunk-based commit because (1) each stage can be tested individually, (2) intermediate commits may contain changes that is not in the final one.
- First make sure that the ugly sequence is on some temporary branch target (what we aim for), and that end result is good and clean.
- Switch back to starting point, and do:
- Edit diff file, to select only those changes we want to include in a first commit. Then do a
git-apply diff
- Test, finalize the last changes before commits (redo
git diff -R target
if necessary). - Commit, and repeat from step 2.
- Use
gitk
to get a graphical visualisation of current commit, or some subsets. For instance - Use
git stash
to save the current state of the working tree (see [4]). - Forgot to add some files in the previous commit? Mistyped the commit message? Use
git commit --amend
:
git diff # First see what's in the working tree (or git status)
git commit -a # Commit all changes
git commit fs/ # Commit all changes in directory fs
git diff -R target > diff # diff to target
gitk # View current commit and all ancestors
gitk master.. # View changes to current branch (i.e. reachable from HEAD, excluding master)
git stash # Save current work in working tree
... # (whatever, including git reset --hard...)
git stash apply # Bring back changes in working tree
git commit # Oups! forgot one file
git add somefile # ... Add the missing file
git commit --amend # ... and replace the previous commit