Basic use of Git

Insert a picture description here

  1. git cloneClone a remote resource to a local directory as a working directory.
  2. Then add or modify files in the local clone directory.
  3. If the remote modification, need to synchronize the remote content, directlygit pullYou can update local files;
  4. Local after the modification, can passgit statusView the modified file. Then use thegit addAdd modified files temporarily to buffer;
  5. After being added, it can be usedgit commitAdd to the current workspace;
  6. After the modification is complete, if errors are found, the submission can be withdrawn and modified and submitted again;
  7. git pushPush local changes to a remote Git server.

Version management mode

Each developer has write permissions for his repository and read permissions for everyone else’s repository. In this case there is usually an authoritative repository representing the “official” project.

To contribute to the project, you need to clone your own public repository from the project and push your changes there.

You can then request the official repository maintainer to pull the update and merge it into the main project.

Maintainers can add your repository as a remote repository, test your changes locally, merge them into their branch and push them back to the official repository.

Insert a picture description here

  1. The project maintainer pushes to the main repository.
  2. Contributors clone the repository and make changes.
  3. Contributors push data to their own public repositories.
  4. Contributors send emails to the maintainer asking to pull their updates.
  5. The maintainer adds the contributor’s repository to a remote repository in its own local repository and merges changes.
  6. The maintainer pushes the merged changes to the main repository.

!!!!! Of course you also can be used as the use of SVN a central warehouse to exchange information (periods of low project personnel are commonly used this way), but this way of working and SVN is not all the same, the difference is that using git for development personnel, every node (each computer on the local repository) has a complete warehouse, It also works when you lose the connection to the central repository (commit to the local repository first).

3. Storage Implementation Principle (Git object)

Git stores files as key-value pairs.

It allows content of any type to be inserted and returns a key value by which the content can be retrieved at any time.

Git kv values generally have the following types: BLOb, tree, and commit.

Git Add principle

Git Add generates a BLOb object, which is then placed in the index section.

(1) Generate Blob objects

First, we need to initialize a new Git version library

$ git init
Initialized empty Git repository in D:/GitTest/.git/
Copy the code

Then let’s look at the generated directory structure

$ find .git/ -typeGit/refs. git/refs/heads /refs/ pack. git/ refs. git/refs/heads/refs. git/refs/ refs/heads .git/refs/tagsCopy the code

All objects generated in Git are stored in objects. Since we study git storage principles, we will focus on this directory.

$ find .git/objects/ -typeF # View all files in.git/objectsCopy the code

Git hash-object can be used to store arbitrary data in the.git/objects directory and return a unique key (kv) that points to that data object.

$ echo 'first add file'>readme.md

$ git hash-object -w readme.md
warning: LF will be replaced by CRLF in readme.md.
The file will have its original line endings in your working directory.
6A0b867bdc470c582c15906f264b9fec371cdbfc # # this warning because the newline character format is different in different systems, in order to distributed development, adaptive system transformationCopy the code

Git hash-Object will accept whatever you pass to it, and it will only return a unique key that can be stored in a Git repository.

The -w option instructs the command not only to return the key, but also to write the object to the database. This command outputs a 40-character checksum.

This is a SHA-1 hash — a sha-1 checksum that combines the data to be stored with a header.

Let’s look again at the Objects directory

$ find .git/objects/ -type f
.git/objects/6a/0b867bdc470c582c15906f264b9fec371cdbfc
Copy the code

This is how Git originally stored content — each file corresponds to one piece of content, and the file is named after the sha-1 checksum of that content along with certain header information.

The first two characters of the checksum are used to name subdirectories, and the remaining 38 characters are used as file names. You can see that its hash value is the same value that we generated earlier.

It’s worth noting that as long as the content doesn’t change, the hash value doesn’t change, which means no new objects will be generated.

You can use giit cat-file to view objects in this directory. -t indicates the type of the object and -p indicates the content of the object.

$ git cat-file -t 6You can use only partial prefixes, as long as you ensure that a unique object can be found. blob $ git cat-file -p6a0b867bdc470c5
first add file
Copy the code

(2) Add changes to temporary storage (index)

Git status can be used to check the status of the index section. You can obviously see that our file is red, indicating that the file has not been added to the index section.

Git update-index is next used to add the file to the index section, since the first time you add the file you use the –add option

$ git update-index --add readme.md
Copy the code

Git status is used to check the status of the index section again, and readme.md has turned green, indicating that we have successfully added to the index section.

Git update-index \–add readme. Md: git update-index \–add readme. Md: git update-index \–add readme.

2. The git commit principle

When code is committed, the tree object is generated as a COMMIT object based on the contents of the staging area, and the records are then logged to the logs folder.

(1) Generationtreeobject

You can write the staging area contents to a tree object using the git write-tree command.

$ git write-tree
d8d965c56c04e851e3b47f524c6c52a24c396857
Copy the code

Git cat-file = git cat-file = git cat-file = git cat-file = git cat-file

$ git cat-file -p d8d965c56c0
100644 blob 6a0b867bdc470c582c15906f264b9fec371cdbfc    readme.md
Copy the code

100644 indicates that the file type is text.

Blob represents the object type.

6 a0b867bdc470c582c15906f264b9fec371cdbfc said the hash value of the file.

And you can see that it’s the same value as when we wrote it.

We add a directory and add it to the index section, regenerating it into a new tree object to see how the directory structure is represented in the tree.

$mkdir -p com/git #'add new file and dirs'>com/git/test. TXT $git add -a # Add all workspace changes to index section $git write-tree956902378ddcc3a768459a852253d1c69bb3a21e
$ git cat-file -p 956902378ddcc3a76
040000 tree 108f37e7bececc2fd72e90d34e9e75ef49b65265    com
100644 blob 6a0b867bdc470c582c15906f264b9fec371cdbfc    readme.md
Copy the code

We can see that the file type of the directory is 040000 and it is represented as a tree object in objects, so the structure is already obvious.

If we look at the com tree object, we will find the Java tree object, and then we will find the test.txt blob object.

(2) generationcommitobject

A COMMIT object can be created by calling the commit-tree command, specifying the SHA-1 value of a tree object and the commit’s parent, if any.

We’ll start with the first tree object we created earlier:

$ echo 'first commit' | git commit-tree d8d965c56c04e8
f742a0cde276d89f79505a500071b6e2577dda45
Copy the code

Depending on the creation time and author data, you will get a different hash value. We look at the COMMIT object

$ git cat-file -p f742a0cde276d
tree d8d965c56c04e851e3b47f524c6c52a24c396857
author jyx <xxxxxx@163.com> 1586695870 +0800
committer jyx <xxxx@163.com> 1586695870 +0800
Copy the code

The format of the submission object is simple: it first specifies a top-level tree object that represents the project snapshot of the submission point; Then there are possible parent commits (that is, the last commit, the commit object described earlier did not have any parent commits);

Then author/submitter information (based on your user.name and user.email configuration, plus a timestamp);

Leave a line blank and submit the comment at the end.

Next, we’ll create another commit object that references the previous commit (as its parent) :

$ echo 'second commit' | git commit-tree 956902378ddcc3a7 -p 9fc68968003d
3d87a34c5c890d15a3c9eacf935d65085621694d
Copy the code

Git log

to see a commit history.

$ git log --stat 3d87a34c5
Copy the code

Insert a picture description here

Then a COMMIT object can be represented as follows

Insert a picture description here

3.git branch/git tagThe principle of

(1) Create a branch/label

Now that we’ve covered all of our objects, how does branch and tag work? If you’re smart enough to figure it out, yes, use Pointers.

Since our project does not currently have any branches, first we create a branch based on the commit point. (A master branch is created by default on the first commit of a new project)

$git branch master3D87a34c5c890d15a3c9eacf935d65085621694d # # based on branches create $git branch dev master # # based on branch create tag $git tag tag_from_master $git branch branch_from_tag tag_from_masterCopy the code

Use Git branch to view branch information

$ git branch
  branch_from_tag
  dev
* master
Copy the code

Use git tags to view tags

$ git tag
tag_from_master
Copy the code

(2) Implementation principle

Git /refs/heads/. Git /refs/heads/

Insert a picture description here

You can see that these files are the three branch names that we created earlier, and we look at the contents of these three files.

Insert a picture description here

We are looking at the tag file, which is stored under.git/refs/tags/

Insert a picture description here

So far we know that the so-called branches and tags are generated based on the commit object, and they refer to a commit object.

4. The Head pointer

A head pointer on each branch represents the latest commit point for the current branch.

We have a HEAD file in our.git folder. We open it to view the content, then use Git Checkout to switch branches and view the content

Insert a picture description here

We found that the branch switch actually changes the total HEAD pointer to a branch file under.git/refs/heads.

When you use Git reset, you actually have to point the HEAD pointer to the commit point that you want to roll back (either tag/branch/commit, but both are actually commit objects).

With that in mind, even if we sometimes make the mistake of rolling back with –hard, we can also find the previous COMMIT object to restore the version before rolling back.

Four,

Insert a picture description here

In this diagram, you can see how some Git commands affect the workspace and staging (stage, index).

  1. The workspace is on the left and the version library is on the right. The area marked “index” in the repository is the staging area (stage, index), marked asmasterismasterThe directory tree represented by a branch.
  2. We can see in the picture that at this pointHEADIt’s actually a pointer to the master branch. So the graphical command appearsHEADWhere you can use itmasterTo replace.
  3. In the figureobjectsThe area identified is Git’s object library, which is actually located.git/objects"Directory.
  4. When you run the “git add” command on a workspace modified (or added) file, the staging directory tree is updated, and the contents of the workspace modified (or added) file are written to a new object in the object library, whose ID is recorded in the staging file index.
  5. When a Git commit is performed, the directory tree of the staging area is written to the repository (the object repository) and the master branch makes updates accordingly. The directory tree that the master points to is the directory tree of the staging area at commit time.
  6. When you performgit reset HEADCommand, the staging area directory tree is rewritten and replaced by the directory tree pointed to by the master branch, but the workspace is not affected.
  7. When you performgit rm --cached <file>Command deletes files directly from the staging area, leaving the workspace unchanged.
  8. When you performgit checkoutorgit checkout -- <file>Command to replace workspace files with all or specified files in the staging area. This operation is dangerous and clears changes in the workspace that have not been added to the staging area.
  9. When you performgit checkout HEADorgit checkout HEAD <file>Command to replace the files in the staging area and workspace with all or part of the files in the Master branch pointed to by HEAD. This command is also dangerous because it clears uncommitted changes in the staging area as well as uncommitted changes in the workspace.

!!!!! Knowing the basics of Git will make it easier to use it as a tool that works for you. This article refers to the official Git documentation.

From: blog.csdn.net/weixin_42762133/article/details/105458252