Lone Solitary Nine Swords (0x01)-General summary

This is a creation in Article, where the information may have evolved or changed.

The total tactic: "to the younger sister to be without a jump, without the convergence of people, the fan trend." A turn to C, C to G, Geng to the third. The turn of the son ugly, Chen has the turn, the afternoon did not turn. Storm is a change, Yamasawa is a change, fire and fire is a change. The universe is excited, the shock is against the phase, and the Sunda phase is stimulated. Three increases to five, five increase and nine ... "(a total of 3,000 words)

Solitary nine swords pay attention to the enemy, no recruit wins. In the program world, there is a need to iterate according to different needs. The system can not be changed like a sword, often need to spend countless personal months "recently realized that you can make changes into an interface, left to the user, to respond to part of the demand change." 程序＝算法＋数据结构, very few like TeX, in terms of algorithms and data structures are nearly perfect, Donald alone completed 99.99%, even the number of bugs, are less to the point of astonishing. I think the most important program design is the data structure, a deep understanding of data structures, the design of the most appropriate structures, status quo, to seize the essence of demand, to solve the user's pain point, to change in demand or transformation, the smallest changes.

General decision

Status Quo

Bad programmers are concerned with code. Good programmers are concerned with data structures and the relationships between them.

Data

GIT data structure is very well designed, it is said that in the next more than 10 years of development, feature expanded countless, the basic data structure is rarely changed. Experience the passage of Linus:

Git's design is very simple, its data structure is very stable, and has a rich description of the document. In fact, I'm very much in favor of designing code around our data structures, not others, and I think that's one of the reasons why Git succeeds [...], in my opinion, the difference between a good programmer and a bad programmer is that they think the code is more important or the data structure is more important.

Tickle your heart, let's get a glimpse of Git's mysteries.

The design idea of git

• Direct recording of snapshots, rather than differential comparisons

Git does not store file differences and sees 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. 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. If the file changes compared to the previous version, the new file (snapshot) is stored in the next version. If there is no change, only the index of the previous file is stored, as shown in the dashed box.

• 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. You can happily submit it until there is an Internet connection to upload again.

• Git guarantees integrity

All data in Git calculates checksums (using SHA-1 hashes) before they are stored, and is then referenced by checksums. This means that it is not possible to change any file content or directory content when Git does not know it. 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 typically only adds data

The git operation that you perform almost only adds data to the GIT database. It's hard to get Git to do any irreversible action, or to have it erase data in any way.

• Three types of Git states

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 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.

The life cycle of a Git file

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:

How Git saves your data

To make it more image, let's say we have a working directory with three files that will be staged and submitted. The staging operation calculates checksums for each file (using the SHA-1 hashing algorithm), and then saves the current version of the file snapshot to the Git repository (Git uses BLOB objects to hold them), and finally officer and joins the staging area for submission:

$ git add README blob.go LICENSE$ git commit -m 'The initial commit of dit'

When you commit using git commit, Git calculates the checksum for each subdirectory (only the project root in this case), and then saves those checksums as tree objects in the Git repository. Git then creates a commit object that contains pointers to the tree object (the project root), in addition to the information mentioned above. As a result, Git can reproduce this saved snapshot when needed.

Now there are five objects in the Git repository: three BLOB objects (holding a snapshot of the file), a tree object (which records the directory structure and the Blob Object index), and a Commit object (containing pointers to the preceding tree object and all commit information).

Make some changes and commit again, the resulting commit object will contain a pointer to the last committed object (the parent object).

Reference

1. ProGit2