Git: Difference between revisions

From miki
Jump to navigation Jump to search
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]
* [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:51, 7 February 2011

References

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:
  • 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:
  • git config --global color.ui true
    
  • Define author/email
  • 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:
  • git diff                          # First see what's in the working tree (or git status)
    git commit -a                     # Commit all changes
    
  • Give git commit a directory argument instead of using -a:
  • git commit fs/                     # Commit all changes in directory fs
    
  • 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.
    1. 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.
    2. Switch back to starting point, and do:
    3. git diff -R target > diff             # diff to target
      
    4. Edit diff file, to select only those changes we want to include in a first commit. Then do a git-apply diff
    5. Test, finalize the last changes before commits (redo git diff -R target if necessary).
    6. Commit, and repeat from step 2.