本文共 7421 字，大约阅读时间需要 24 分钟。

• Overview

  Page: 1~63

• Version Control

  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.

  Before Git, there are:

  • Local Version Control Systems: RCS
  • Centralized Version Control Systems(CVCSs): CVS, Subversion, Perforce
  • Distributed Version Control Systems(DVCSs): Git, Mercurial, Bazaar, Darcs

• History of Git

  Git began with a bit of creative destruction and fiery controversy.

  1991-2002, changes to Linux Kernel were passed around as patches and archived files;

  2002-2005, began using BitKeeper;

  2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down;

  2005, Git was born.

• How Git Think the World

  • Snapshots, Not Differences

    理解delta-based version control

    Other systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they store as a set of files and the changes made to each file over time, which is described as delta-based version control.

    Git thinks of its data more like a series of snapshots of a miniature filesystem, in other words, 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 Operation Is Local

    Most operations in Git no need network latency overhead;

    This also means that there is very little you can’t do if you’re offline or off VPN.

  • Git Has Integrity

    Everything in Git is checksummed (used which is called SHA-1 hash) before it is stored and is then referred to by that checksum.

    Git stores everythin in its database not by file name but by the hash value of its contents.

  • Git Generally Only Adds Data

    This make it hard to get the system to do anything that is not undoable or to make it erase data in any way.

  • The Three States & Three Sections

    Three States:

    1. modified means that you have changed the file but have not commited it to your database yet (file was changed but not been staged)
    2. staged means that you have marked a modified file in its current version to go into your next commit snapshot (file was added to the staging area)
    3. commited means that the data is safely stored in your local database (file in Git direcroty)

    

    Three Sections:

    1. 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
    2. 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”
    3. Git Directory is where Git stores the metadata and object database for your project. It’s what is copied when you clone a repository from another computer.

  • git clone not git checkout

    If you want to get a copy of an existing Git repository, the command you need it git clone, prefer to other VCS like Subversion’s checkout, This is an important distinction – instead of getting just a working copy, Git receives a full copy of nearly all data that the server has.

    git clone pulls down all the data for that repository, and checks out a working copy of the latest version.

• How to use Git

• The basic Git Workflow

  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

• Common Command

• Git Basics

• Recording Changing to the Repository

  Each file in your working directory (check out copy) can be in one of two states:

  1. tracked: that were in the last snapshot which means files that Git knows about
  2. untracked: that were not in your last snapshot and are not in your staging area

  

• Ignoring Files

  Often ,you’ll have a class of files that you don’t want Git to automatically add or even show you as being untracked. You can create a file listing patterns to match such files named .gitignore

  A repository might have a single .gitignore file in its root directory, which applies recursively to the entire repository, however, it is also possible to have additional .gitignore files in subdirectories, the rules in these nested .gitignore files apply only to the files under the directory where they are located.

• Viewing Your Staged and Unstaged Changes

  What have you changed but not yet staged?

  What have you staged that you are about to commit?

• Commiting Your Changes

  Anything that is still unstaged – any files you have created or modified that you haven’t run git add on since you edited them – won’t go into this commit.

• Removing Files

  To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit.

• Viewing the Commit History

  The author is the person who originally wrote the work, whereas the committer is the person who last applied the work.

• Undoing Things

  You can’t always undo some of these undos, this is one of the few areas in Git where you may lose some work if you do it wrong.

• Working with Remotes

  Remote repositories are versions of your project that are hosted on the Internet or network somewhere.

  origin: is the default name Git gives to the server you cloned from

  git fetch command only downloads the data to your local repositories – it doesn’t automatically merge it with any of your work or modify what you’re currently working on;

  git pull command automatically fetch and then merge that remote branch into your current branch, if your current branch is set up to track a remote branch.

  git clone command automatically sets up your local master branch to track the remote master branch on the server you cloned from.

  git push command works only if you cloned from a server you have write access and nobody has pushed in the meantime; otherwise, you’ll have to fetch their work first, and incorporate it into yours before you’ll be allowed to push.

• Tagging

  Git supports two types of tags:

  • lightweight tag is very much like a branch that doesn’t change - it’s just a pointer to specific commit
  • annotated tags are stored as full objects in the Git database,

  By default, the git push command doesn’t transfer tags to remote servers.

• Git Aliases

  Git doesn’t automatically infer your command if you type it in partially.

• Git Internals

  Git is fundamentally a content-addressable filesystem (which means that at the core of Git is a simple key-value data store) with a VCS user interface written on top of it.

  $ ls -F1config		# project-specific configuration optionsdescription	# only used by the GitWeb programHEADhooks/ 		# client- or server-side hook scriptsinfo/		# keeps a global exclude file or ignoref patterns that you don't want to track in a .gitignore fileobjects/ refs/

  The core parts of Git:

  HEAD : points to the branch you currently have checked out

  index(yet to be created): stores your staging area information

  objects: all the content for your database

  refs: stores pointers into commit objects in that data

• Git object

  1. blob

     83baae61804e65cc73a7201a7252750c76066a30: the SHA-1 key

     存储文件内容content

  2. tree

     solve the problem of storing the filename and also allows you to store a group of files together.

     

  3. commit

     Information about who saved the snapshots, when they were saved, or why they were saved.

• References

1. Chacon, S., & Straub, B. (2014). Pro Git. Pro Git.