Pro Git - 笔记1

Getting Started

About Version Control

　　Local Version Control Systems

　　Centralized Version Control Systems

　　Distributed Version Control Systems

A Short History of Git

　　2005, Linus Torvalds, Linux Community

　　goals of Git:

• Speed

• Simple design

• Strong support for non-linear development (thousands of parallel branches)

• Fully distributed

• Able to handle large projects like the Linux kernel efficiently (speed and data size)

Git Basics

　　Snapshots, not differences

　　With Git, every time you commit, or save the state of your project, Git 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. Git thinks about its data more like a stream of snapshots.

　　This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS.

　　Nearly every operations is local

　　Git has integrity

　　Everything in Git is check-summed before it is stored and is then referred to by that checksum. This means it’s impossible to change the contents of any file or directory without Git knowing about it.

　　The mechanism that Git uses for this checksumming is called a SHA-1 hash.

　　In fact, Git stores everything in its database not by file name but by the hash value of its contents.

　　Git generally only add datas

　　When you do actions in Git, nearly all of them only add data to the Git database. It is hard to get the system to do anything that is not undoable or to make it erase data in any way.

　　The three states

　　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.

　　This leads us to the three main sections of a Git project: the Git directory, the working tree, and the staging area.

　　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 tree 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 file, generally contained in your Git directory, that stores information about what will go into your next commit. Its technical name in Git parlance is the “index”, but the phrase “staging area” works just as well.

　　The basic Git workflow goes something like this:

1. You modify files in your working tree.

2. You selectively stage just those changes you want to be part of your next commit, which adds only those changes to the 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.

The Command Line

Installing Git

　　Linux:

　　on Federo, RHEL, CentOS

$ sudo dnf install git-all

　　on Debian, Ubuntu

$ sudo apt install git-all

　　Mac OS:

$ git --version

　　Windows:

　　http://git-scm.com/download/win

　　From source:

　　...

First-Time Git Setup

　　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:

　　/etc/gitconfig file

　　~/.gitconfig or ~/.config/git/config file

　　config file in the Git directory (that is, .git/config) of whatever repository you’re currently using

　　Your identity

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

　　Your Editor

$ git config --global core.editor emacs

　　On a Windows system, if you want to use a different text editor, you must specify the full path to its executable file.

$ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -nosession"

$ git config --global core.editor "'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -nosession"

　　Check your settings

$ git config --list
user.name=John Doe
user.email=johndoe@example.com
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto
...

　　You can also check what Git thinks a specific key’s value is by typing git config <key>:

$ git config user.name
John Doe

Getting Help

$ git help <verb>
$ man git-<verb>

　　Example:

$ git help config

　　in additon:

$ git add -h
usage: git add [<options>] [--] <pathspec>...

    -n, --dry-run         dry run
    -v, --verbose         be verbose

    -i, --interactive     interactive picking
    -p, --patch           select hunks interactively
    -e, --edit            edit current diff and apply
    -f, --force           allow adding otherwise ignored files
    -u, --update          update tracked files
    -N, --intent-to-add   record only the fact that the path will be added later
    -A, --all             add changes from all tracked and untracked files
    --ignore-removal      ignore paths removed in the working tree (same as --no-all)
    --refresh             don't add, only refresh the index
    --ignore-errors       just skip files which cannot be added because of errors
    --ignore-missing      check if - even missing - files are ignored in dry run
    --chmod <(+/-)x>      override the executable bit of the listed files

$ git add --help

Summary