Git (one of the learning) basic concepts

Git Learning Notes

#####################################################

qq:1218761836

QQ Group: 150181442

#####################################################

Directory

Git. 1

first, about version control ... 1

second, the local version control system ... 1

three, centralized version control system ... 2

Iv. Distributed version Management control system ... 3

Five, Git 's History ... 3

Six, Git how it works ... 4

Seven, Git Guaranteed Integrity ... 5

Eight or three states of ... 6

Gitfirst, about version control

What is version control? Versioning is a system that records one or more content changes so that future revisions of a particular version are reviewed. Any type of file can be versioned.

How do you write a book, need to constantly modify, then record you every time you write a chapter after saving, then modify after saving, continue to write the book, continue to save, so repeatedly modified save, there are many word files. And then when you're ready to delete the first time you save, think about it and dare to delete it, if you want to have a software to manage the documents you write to save, then Git is a great tool to record each version, user (description), date

That way, you don't have to manage it manually.

second, local version control system

Many people are accustomed to copy the entire project directory in a way to save different versions, and perhaps renamed with backup time to show the difference, so the only advantage is simple, but especially easy to make mistakes, there is time to confuse the working directory, accidentally write the wrong file or overwrite the intended file,

To solve this problem, many local version control systems have been developed a long time ago, mostly using some simple database to record the changes in the file.

650) this.width=650; "style=" width:884px;height:562px; "src=" http://s3.51cto.com/wyfs02/M00/73/C7/ Wkiol1yhd9xtj40naafcj0izdj8703.jpg "title=" 1.png "alt=" wkiol1yhd9xtj40naafcj0izdj8703.jpg "vspace=" 0 "width=" 884 " height= "562" hspace= "0" border= "0"/>

three, centralized version control system

The software of this kind of system mainly includes: CVS, subversion and Perforce etc., all have a single centralized management server, save the revision of all files, and the people who work together are connected to this server through the client, Check out the latest files or submit updates.

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M01/73/C9/wKiom1YHeDmwCq_nAAFKyk_SSac999.jpg "title=" 2.png " alt= "Wkiom1yhedmwcq_naafkyk_ssac999.jpg"/>

Cons: Single point of failure

Iv. distributed version Management and control system

software for this type of system: Git, Mercurial, Bazaar, DARCS, etc.

Instead of just extracting the latest version of a file snapshot, the client mirrors the code repository intact, and each time the full cloning operation is actually a full backup of the Code warehouse.

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M01/73/C7/wKioL1YHeE_RBNZ6AANJ6xAorpc921.jpg "title=" 3.png " alt= "Wkiol1yhee_rbnz6aanj6xaorpc921.jpg"/>

Pros: You can specify and interact with several different remote code warehouses, and you can collaborate with people from different working groups in the same project, and you can set up different collaborative processes, such as hierarchical model workflows, based on your needs.

v. History of Git

Many people know that Linus in 1991 to create the open source of Linux, since then, the development of Linux systems, has become the largest server system software.

Linus while Linux was created, Linux was grown by enthusiastic volunteers around the world, and so many people were writing code for Linux around the globe, how does Linux code manage it?

The fact is, before 2002, volunteers from all over the world sent the source code files by diff to Linus, and then by Linus himself to merge the code by hand!

You might think, why Linus not put Linux code in the version control system? Don't you have CVS, SVN, these free version control systems? Because Linus is firmly opposed to CVS and SVN, these centralized version control systems are slow and must be networked to use. There are some commercial version control system, although more than CVS, SVN, but that is paid, and the Linux open source spirit does not match.

However, by the year 2002, the Linux system has been developed for 10 years, the size of the code base makes it difficult for Linus to continue to manage by hand, the community's brothers also expressed strong dissatisfaction with this way, so Linus chose a commercial version control system BitKeeper, BitKeeper's owner, BitMover, has granted the Linux community free access to this version control system in the spirit of humanitarianism.

The great situation of unity and stability was broken in the 2005, because the Linux community cattle gathered, inevitably contaminated with some Liangshan heroes of the lakes and rivers habits. Andrew, who developed samba, tried to crack BitKeeper's protocol (and he was not the only one), and was discovered by the BitMover company (monitoring works well!). ), so BitMover company anger, to recover the free use of the Linux community.

Linus you can apologize to BitMover company and make sure to discipline your brethren later, well, that's impossible. The reality is this:

Linus It took me two weeks to write a distributed version control system in C, which is git! Within one months, the Linux system's source code has been managed by Git! How does a cow define it? You can appreciate it.

Git quickly became the most popular distributed version control system, especially in 2008, when the GitHub website was launched, it provided free git storage for open source projects, and countless open source projects began to migrate to GitHub, including Jquery,php,ruby and so on.

History is so accidental, if not the BitMover company to threaten the Linux community, we may now have no free and super good Git

Git The goal set at the outset

Speed

A simple design

Strong support for non-linear development patterns (allows thousands of parallel-developed branches)

Fully distributed

Ability to efficiently manage hyper-scale projects like the Linux kernel (speed and data volume)

vi. how git works

Direct recording of snapshots, rather than differential comparisons

Git The main difference from other version control systems, including subversion and approximation tools, is how git treats the data. Conceptually, most other systems store information as a list of file changes, such systems (CVS, Subversion, Perforce, Bazaar, and so on) view their saved information as a set of basic files and a gradual accumulation of each file over time

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M02/73/C9/wKiom1YHeF3TFZ34AAMttbV6was543.jpg "title=" 4.png " alt= "Wkiom1yhef3tfz34aamttbv6was543.jpg"/>

Store differences between each file and the initial version

Git Instead of treating or saving data as described above, git is more likely to think of data as a set of snapshots of small file systems. Every time you commit an update, or save a project state in Git, it basically makes a snapshot of all the files at that time and saves the index of the snapshot, in order 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, and git treats the data more like a snapshot stream.

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M02/73/C7/wKioL1YHeG7BFJlGAAPkB8vrc_E163.jpg "title=" 5.png " alt= "Wkiol1yheg7bfjlgaapkb8vrc_e163.jpg"/>

storing snapshots of items over time

This is an important difference between git and almost any other version control system. So git reconsidered the many aspects of the previous version control system. Git is more like a small file system, offering many powerful tools that are built on the ground, not just a simple CVS,

Nearly all operations are performed locally

Most operations in Git require only access to local files and resources, and generally do not require information from other computers on the network. If you are accustomed to a centralized version control system with network latency overhead for all operations, GIT does not need network latency because you have a complete history of the project on your local disk, so most of the operations appear to be done instantaneously.

For example: To browse the history of a project, GIT does not need to connect to the server to get history and then show it-it simply gets it directly from the local database. You can see the project history immediately, and if you want to see the changes introduced between the current version and the one-month-old version, Git will look for a local difference calculation one months ago instead of being processed by a remote server or pulled back from the remote server to the previous version.

This also means that you can do almost anything when you're offline or without a VPN. If you want to do some work on the plane or on the train, you can submit it happily until there is an Internet connection to upload it. If you go home after the VPN client is not normal, you can still work, using other systems, it is not very laborious, such as with Svnsvs you can modify the file, but not to the database to commit changes (because your local database offline). That's the difference between git.

vii. git guarantees integrity

Git all of the data in the store calculates the checksum before it is stored, and is then referenced by a checksum, which means it is not possible to change any of the file contents or directory contents without Git's knowledge. This feature is built on the git floor and is an integral part of the GIT philosophy. If you lose information or corrupt files during the transfer process, git can find it.

Git the mechanism used to calculate the checksum 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, and the SHA-1 hash looks like this:

24b9da6552252987aa493b52f8696cd6d3b00373

Git This hash value is used in many cases, you will be wonderful to see this hash value, in fact, the information stored in the GIT database is indexed by the hash value of the file content, not the file name.

Git generally only add data

The git operation, which only adds data to the GIT database, makes it difficult for git to perform any irreversible operations, or let him erase the data in any way. As with other VCs, content that may be lost or scrambled when the update is not submitted, but once you commit the snapshot to git, it is difficult to lose data again, especially if you regularly push the database to other warehouses.

This makes it a safe and enjoyable process for us to use git because we know we can do all kinds of things without risking the mess.

eight or three different states

Git There are three statuses: committed (committed), modified (modified), staged (staged).

Committed indicates that the data has been safely saved in the local database.

Modified to indicate that the file has been 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.

Git Three workspace concepts: git repositories, working directories, and staging areas.

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M00/73/C9/wKiom1YHeHPh_JvaAAIXrpYCXB0850.jpg "title=" 6.png " alt= "Wkiom1yhehph_jvaaaixrpycxb0850.jpg"/>

Git The repository directory is where git stores the metadata and object database of the project, which is the most important part of git, and the data is copied from the other computer when it is cloned from the repository.

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.

Staging area is a file that holds the file list information that will be submitted the next time, typically in a git repository directory. It is sometimes referred to as an "index". But the general term is still called the staging area.

The basic git workflow is as follows:

1. 1. modifying files in the working directory

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

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

If a particular version of a file is saved in the Git directory, it is in the committed state, and if modified and placed in the staging area, it is in the staged state, and if it has been modified since the last time it was removed and has not been placed in the staging area, it is the modified state.

Resources

Http://www.git-scm.com/book/en/v2  

http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000

This article is from the "Little Rookie" blog, please be sure to keep this source http://xiaocainiaox.blog.51cto.com/4484443/1698557

Git (one of the learning) basic concepts