Git: Difference between revisions
Jump to navigation
Jump to search
m (→References) |
|||
Line 5: | Line 5: | ||
** [https://git.wiki.kernel.org/index.php/GitFaq Git FAQ] |
** [https://git.wiki.kernel.org/index.php/GitFaq Git FAQ] |
||
** [https://git.wiki.kernel.org/index.php/GitTips Git Tips] |
** [https://git.wiki.kernel.org/index.php/GitTips Git Tips] |
||
* [http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html Git Tutorial] |
* '''[http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html Git Tutorial]''' |
||
* [https://help.ubuntu.com/community/Git Git on Ubuntu] |
* [https://help.ubuntu.com/community/Git Git on Ubuntu] |
||
* [http://progit.org/ Pro Git] |
* [http://progit.org/ Pro Git] |
Revision as of 21:59, 7 February 2011
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
- 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