Git: Difference between revisions
Jump to navigation
Jump to search
Line 85: | Line 85: | ||
* <tt>[http://sourceforge.net/projects/qgit/ qgit]</tt> — A graphical interface to git repositories using QT |
* <tt>[http://sourceforge.net/projects/qgit/ qgit]</tt> — A graphical interface to git repositories using QT |
||
== |
== Configuration == |
||
References: |
References: |
||
* [ |
* [http://book.git-scm.com/5_customizing_git.html Git Community Boot - Customizing Git] |
||
* Git handy feedback on command-line |
* Git handy feedback on command-line |
||
Line 101: | Line 101: | ||
git config --global user.name "Your Name" |
git config --global user.name "Your Name" |
||
git config --global user.email you@example.com |
git config --global user.email you@example.com |
||
</source> |
|||
<li>Add some frequently used aliases:</li> |
|||
<source lang="bash"> |
|||
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' |
|||
</source> |
</source> |
||
</ul> |
</ul> |
Revision as of 21:50, 16 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
- 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
- qgit — A graphical interface to git repositories using QT
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'
Frequently used
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
Tips - 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 ([1]). 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 [2]). - 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