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:
-
You modify files in your working tree.
-
You selectively stage just those changes you want to be part of your next commit, which adds only those changes to the staging area.
-
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
