Pro git reading notes first knowledge of Git

A version control system, a VCS, is a system that records the changes in one or several file contents so that future revisions of a particular version are reviewed. In addition to versioning files for software source code, you can actually version any type of file. With version control we can go back to the previous state of a file, or even the entire project to the past at some point in time, you can compare the details of the file changes, to find out who finally changed the place, so as to identify the cause of the bug, and who reported a functional defect and so on.

The distributed Versioning System (distributed version control systems abbreviation DVCS), differs from the centralized version control system (centralized. Control systems abbreviation CVCS), Instead of just extracting the latest version of the file snapshot, the client mirrors the code repository completely. As a result, any server that works together fails and can be recovered using any of the mirrored local repositories afterwards. Because each cloning operation is actually a full backup of the code warehouse at one time.

　　git is a free, open source distributed version control system (DVCS), which is a content-addressable storage system. distinguish it from other file-based storage systems. (Content-based addressing: each time you commit an update or save a project state in Git, it essentially makes a snapshot of all the files at that time and saves the index of the snapshot.) To be efficient, if the file is not modified, Git does not re-store the file, but instead keeps a link to the previously stored file. Git treats data more like a snapshot stream . ）

Most operations in Git require only access to local files and resources, and generally do not require information from other computers on the network.

The mechanism that Git uses to calculate checksums (checksum or hash sum) is called SHA-1 hash (hash, hash). This is a string of 40 hexadecimal characters (0-9 and A-f), based on the contents or directory structure of a file in Git. The SHA-1 hash looks like this:24b9da6552252987aa493b52f8696cd6d3b00373

In fact, the information stored in a Git database is indexed by the hash value of the file content, not the file name.

Git has three states, and your files may be in one of them: committed (committed), modified (modified), and staged (staged). Committed indicates that the data has been safely saved in the local database. Modified to indicate that the file was modified but not yet saved to the database. Staged indicates that the current version of a modified file has been marked for inclusion in the next commit snapshot. This introduces the concept of three working areas of a git project: Git repositories, working directories, and staging areas.

The Git repository directory is where git stores the metadata and object databases for your project. This is the most important part of Git, where the data is copied when you clone a warehouse from another computer. A working directory is a separate extract of a version of a project. These files extracted from the compressed database of a Git repository are placed on disk for your use or modification. The staging area is a file that holds the file list information that will be submitted the next time, typically in a Git repository directory. Sometimes referred to as "index", but the general term is called the staging area.

The basic Git workflow is as follows:

1. Modify the file in the working directory.

2. Staging file, placing a snapshot of the file into the staging area.

3. Commit the update, locate the file in the staging area, and permanently store the snapshot in the Git repository directory.

　　

Git Install reference http://git-scm.com/book/zh/v2/%E8%B5%B7%E6%AD%A5-%E5%AE%89%E8%A3%85-Git

Git Windows Edition https://git-for-windows.github.io/

Git Initial Configuration

Get help: Enter git assist <command> on the command line to invoke the relevant command document e.g. to obtain a manual for the config command, simply execute the $ git help config

config has three levels of configuration:

1.--local local Configuration "default high priority": affects only this warehouse

2.--global "Medium priority": A git repository that affects all current users

3.--system "Low priority": affects the system-wide git repository

　　

Get the Git repository:

There are two ways to get the Git project warehouse. The first is to import all files into git under an existing project or directory, and the second is to clone an existing Git repository from a server.

1.) Initialize the repository in the existing directory:

If you plan to use GIT to manage existing projects, you just need to go to the project directory and type: $ git init

If you are initializing a Git repository for versioning in a folder that already has files (rather than an empty folder), you should start tracking these files and submitting them. You can git add implement a trace of the specified file by command, and then execute the git commit commit:

$git add *.c $ git add LICENSE$‘initial project version‘

2.) Clone the existing repository:

If you want to get a copy of a Git repository that already exists, you need to use the git clone command. This is an important feature of git that distinguishes it from other version control systems, and Git clones almost all of the data on the GIT repository server, rather than just copying the files needed to complete your work. When you execute a git clone command, each version of each file in a remote Git repository is pulled down by default. In fact, if your server's disk is broken, you can usually use any cloned client to rebuild the repository on the server.

The command format for the Clone warehouse is git clone [url] . For example, to clone a Git-linked library libgit2, you can use the following command:

$git clone https://github.com/libgit2/libgit2

This creates a directory named "Libgit2" under the current directory, initializes a folder under this directory .git , pulls all the data from the remote repository into the .git folder, and then reads a copy of the latest version of the file from it. If you enter this new libgit2 folder, you will find that all the project files are already in place and ready to wait for subsequent development and use. If you want to customize the name of the local repository when cloning a remote repository, you can use the following command:

$git clone https://github.com/libgit2/libgit2 mylibgit

This will perform the same operation as the previous command, but the name of the warehouse created locally becomes mylibgit .

Git supports a variety of data transfer protocols. The above example uses https:// protocols, but you can also use git:// protocols or SSH transport protocols, for example [email protected]:path/to/repo.git .

　　each file in the working directory is either of these states: tracked or not tracked. tracked files are those that are included in version control, have their records in the last snapshot, and after a period of work they may be unmodified, modified, or put into staging area. All other files in the working directory other than the tracked files belong to the non-tracked files, which neither exist in the record of the last snapshot nor put in staging area. when a warehouse is first cloned, all files in the working directory belong to the tracked file and are in an unmodified state. After editing some files, Git marks them as modified files since you made changes to them since the last commit. We gradually put these modified files into staging area, and then submitted all the pending changes, so again and again. so when using Git, the file life cycle is as follows:

　　

Lack of knowledge of command line, data Transfer Protocol, etc. Never forget to beginner's mind.

Reference excerpt from: Git Pro http://git-scm.com/book/zh/v2

Pro git reading notes first knowledge of Git