Chapter 1. Getting Started

1.  Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.

 

2.  Local Version Control Systems have a simple database that kept all the changes to files under revision control while Centralized Version Control Systems have a single server that contains all the versioned files, and a number of clients that check out files from that central place.

 

3.  The most obvious downside of CVCS is the single point of failure that the centralized server represents.

 

4.  In a Distributed Version Control System (such as Git, Mercurial, Bazaar, or Darcs), clients don't just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. Every checkout is really a full backup of all the data.

 

5.  Most other systems think of the information they keep as a set of files and the changes made to each file over time:
 

 
Git thinks of its data more like a set of snapshots of a mini filesystem. Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn't store the file again—just a link to the previous identical file it has already stored.

 

 
6.  Most operations in Git only need local files and resources to operate—generally, no information is needed from another computer on your network. Because you have the entire history of the project right there on your local disk, most operations seem almost instantaneous.

 

7.  Everything in Git is check-summed before it is stored and is then referred to by that checksum. The mechanism that Git uses for this check-summing is called a SHA-1 hash. This is a 40-character string composed of hexadecimal characters (0–9 and a-f) and calculated based on the contents of a file or directory structure in Git. Git stores everything not by file name but in the Git database addressable by the hash value of its contents.

 

 

8.  Git has three main states that your files can reside in: committed, modified, and staged. Committed means that the data is safely stored in your local database. Modified means that you have changed the file but have not committed it to your database yet. Staged means that you have marked a modified file in its current version to go into your next commit snapshot.

 

9.  The Git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer.
The working directory is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.
The staging area is a simple file, generally contained in your Git directory, that stores information about what will go into your next commit. It's sometimes referred to as the index, but it's becoming standard to refer to it as the staging area.
 

 
10.  The basic Git workflow goes something like this:
  1)  You modify files in your working directory.
  2)  You stage the files, adding snapshots of them to your staging area.
  3)  You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.

 

11.  If a particular version of a file is in the Git directory, it's considered committed. If it's modified but has been added to the staging area, it is staged. And if it was changed since it was checked out but has not been staged, it is modified.

 

12.  To install git from source:
  1)  Install the dependencies of Git : curl, zlib, openssl, expat, and libiconv.
        $ yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel   (on Fedora)
        $ apt-get install curl-devel expat-devel gettext-devel openssl-devel zlib-devel  (on Debian based system)

 

   2)  Grab the latest snapshot from: http://git-scm.com/download

 

  3)  Compile and install :
        $ tar -zxf git-1.6.0.5.tar.gz
        $ cd git-1.6.0.5
        $ make prefix=/usr/local all
        $ sudo make prefix=/usr/local install

 

   4)    Then you can get updates via Git itself:
        $ git clone git://git.kernel.org/pub/scm/git/git.git

 

13.  Git comes with a tool called git config that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places:
    1)  /etc/gitconfig file: Contains values for every user on the system and all their repositories. If you pass the option --system to git config, it reads and writes from this file specifically. (for windows it’s Msys root which is where you install the msysgit.)
    2)  ~/.gitconfig file: Specific to your user. You can make Git read and write to this file specifically by passing the --global option.
    3)  config file in the git directory (.git/config ) of whatever repository you're currently using: Specific to that single repository.

      4) config file in any folder you specified, you can specify the config file path by passing the –file or –f option.

 

Each level overrides values in the previous level.

 

14.  The first thing you should do when you install Git is to set your username and e-mail address which is immutably baked into the commits you pass around:
    $ git config --global user.name "Sean Zhou"
    $ git config --global user.email [e-mail]

 

15.  You can configure the default text editor that will be used when Git needs you to type in a message. By default, Git uses your system's default editor, which is generally Vi or Vim. If you want to use a different text editor, such as Emacs, you can do the following:
    $ git config --global core.editor emacs

 

16.  You can configure the default diff tool to use to resolve merge conflicts:
    $ git config --global merge.tool vimdiff
Git accepts kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff as valid merge tools.

 

17.  You can use the git config --list command to list all the configurations Git can find at that point. You can also check what Git thinks a specific key's value is by typing git config {key}

 

18.  There are three ways to get the manual page (manpage) help for any of the Git commands:
      $ git help <verb>
      $ git <verb> --help
      $ man git-<verb>