Git: Difference between revisions
Jump to navigation
Jump to search
m (→Install) |
(→Terminology: detached head) |
||
Line 28: | Line 28: | ||
Very fast commit. Local repository |
Very fast commit. Local repository |
||
== Terminology == |
== Terminology and Concepts == |
||
; [http://sitaramc.github.com/concepts/detached-head.html detached head] |
|||
: When <tt>HEAD</tt> is no longer a reference to anything (like <tt>ref: refs/heads/branch</tt>), but instead contains the actual hash of a commit. |
|||
<source lang="bash"> |
|||
git checkout -b newbranch # To attach HEAD back on a new branch... |
|||
</source> |
|||
; hunk |
; hunk |
||
: individual change within a file (basically a file diff output is made of a sequence of one or more hunks). |
: individual change within a file (basically a file diff output is made of a sequence of one or more hunks). |
Revision as of 11:18, 7 February 2011
References
- Git Home
- 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
- 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
Configuring Git
References:
- [htp://book.git-scm.com/5_customizing_git.html 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
git config --global color.ui true
git config --global user.name "Your Name"
git config --global user.email you@example.com
Tips - Working the git way
References:
- Linus Torvalds [1]
- Check project diff before
commit -a
: - Give
git commit
a directory argument instead of using-a
: - Clean up an ugly sequence of commits ([2]). 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.
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