1. Git three workspace (work area, staging area and repository)
Workspace (WORKING DIRECTORY) : place directly edit files directly visible operation;
Temporary Area (STAGIN the AREA) : Local data (snapshots) temporarily stored;
Repository (GIT DIRECTORT (RESPOSITORY)): to store data has been submitted, push, when this area is to push data to a remote git repository.
git add is to the work area to modify the cache in the staging area, git the commit is the staging area snapshot of the data submitted to the local library
This is the first implementation of the reasons why the git add before git commit, if you do not perform add first, then the current will not submit content directly commit to the implementation of the code library.
2. Git basic concepts (entities, references and indexes)
entity:
All submissions to git code repository, including a description of each submitted information, directory structures, etc. that will be converted into solid git
All entities are present in .git / objects / directory
git each entity a 40 character hex string length to uniquely identify
git includes four types of entities:
1.blob- store file content
2.tree- storage directory structure and file names
3.commit- storage of submission, date, description, etc.
4.tag- storage submitted to a specific object reference
Quote:
Git, one branch (Branch), remote branch (remote branch) or a tag (Tag) (also referred to as a light tag) is merely a pointer pointing to an entity, where the entity is usually a commit entity. These references are stored in a text file is referenced in the directory .git / refs / symbol (Symbolic References) Git has a special reference symbol called a reference. It does not directly point to an entity, but rather a reference point to another. For example, .git / HEAD is a symbolic reference. It points to the current branch you are working.
index:
The index is a temporary storage area, stored in the form of binary file .git / index as in git add a file, the file git add information to the index when git committhe time, only the files submitted git listed in the index file to a local git warehouse
Entities, relationships between the references and indexes:
Test instruction:
1. Create a readme, txt and submitted to the local library
git add readme.txt git commit -m 'first commit'
2. Git log view commit entity , it can be seen for the SHA1 value 999976c43b0e684f1bf7af4bed1acd11b3afa636
3. git CAT-File catalog the contents of the commit entity, it can be seen that commit entity contains the author and global mail and other information submitted in addition to including a tree entity , SHA1 value of the entity bb527569763dcd71a5dcd4b9a4ba692f1ebb56c0
4. Use git ls-tree view of the tree entity , the entity found tree contains a blob entity, SHAl value of the entity 0cce6dff89d87d991136ad27e18c928eb65f5bb3
5. Use git cat-file -p XXX View blob entity content can be found blob storage entity is the contents of the file readme.txt
6. At this point we see .git / refs / heads / master file contents, you can find it just as SHA1 value commit entity, it means that master as a reference, and points to the last commit entity
7. In the just described, we know that the tag is stored to the specified entity references commit entity, let's create a label "version1.1", by git rev-parse tagname to see the SHA1 value tag entity, and through git cat -file -p XXXX can be found in the internal tag shall commit entity, and the entity is an entity commit the last commit
8. At this point we generated four entities, namely
---- 999976c43b0e684f1bf7af4bed1acd11b3afa636 the commit entity
--- bb527569763dcd71a5dcd4b9a4ba692f1ebb56c0 Tree entity
--- 0cce6dff89d87d991136ad27e18c928eb65f5bb3 BLOB entities
50e5866a324c6e2afaf6374c39b4b93d394b504a - Tag entity
8. Check each entity reference, the storage position of the index
Entity (.git / objects /): SHA1 to the first two as the file name
References (.git / refs): heads next store historical commit entity, each label is stored under tags
Index (.git / index):
By --stage git ls-files to see .git / index the contents of the file can be found not stored SHA1 value of the latest commit entity , but its commit entity associated blob entity SHA1 value
Test again .git / index the contents of the documents, we create a new index file and submit it to the local library
3. Git SHA1
git for each entity generates a 160-bit hash value, typically using a 40-character hexadecimal string length represented
Hash collision:
Almost hash collision does not occur (same SHA1, conflict)
Normally you do not need to worry about the hash value collision, to 160 digits, you have 2160 or about 1048 kinds of possible SHA1 hash value. How great this number, you can simply feel the next, even if you hire someone to produce one trillion per one trillion unique new blob object for one trillion years, you had only 1043 blob object, so you basically do not worry about the hash value collision, and only when different content produced the same SHA1 hash value can be called a collision.
git-based content SHA1:
The same as the corresponding content obtained never be the same SHA1
Git previously mentioned entities will generate a unique value for each SHA1 to identify the entity, and the entity git will generate a binary file stored in .git / objets directory, but when generating git and SHA1 not simply based on the file name, file path, the creator and creation time are combined, the opposite is git-based content to generate SHA1, imagine if there is a file a.txt our project, were stored under dir1, dir2 directory, this time git does not create two entities blob dir1 / a.txt and dir2 / a.txt file because a.txt although in both directories, but their content is exactly the same, so git in generating entity when, through a hash algorithm, git will find these two documents drawn SHA1 value is exactly the same, so git will only save a blob entity. This prevents When we re-renaming files, or moving files directory, generate duplicate blob entity, which also benefited from git hash algorithm-based content can well find these two files is actually the same file.
test:
4. git reference describes special symbol
git automatically maintains a special symbol for a particular purpose several references. These references anywhere can be submitted in use.
- HEAD always points to the current branch of the final submission . When switching HEAD branch is updated to point to the new branch of the submission date.
- ORIG_HEAD certain operations, such as saving the previous merage / reset will merge HEAD to ORIG_HEAD in order to rollback the state ORIG_HEAD may be combined prior to use after the merge (merging branch when generating a conflict, the conflict has been modified if and generate a new submission, but conflict resolution there is a problem, you want to restore the state before the re-merger, then you can use
git reset --hard ORIG_HEADto restore to the state before the merger). - FETCH_HEAD when using the command
git fetchto fetch remote repository update, FETCH_HEAD preserved HEAD branch recently crawled. - MERGE_HEAD when a merge is in progress, other branches of the head temporarily recorded in MERGE_HEAD, in other words, MERGE_HEAD is being merged into HEAD submission.