The introduction

Although I have been using Git as a code management tool, I have not systematically studied the use and principle of Git. Now I am an intern. I thought git was just ok before, but NOW I regret it very much. It took me half a day to write the code and have a problem submitting it. Ah, forget the pain. So I write this document to learn about Git.

Git base paper

A database is a place where the state of a file or directory is recorded and a history of changes to the content is stored. Under the management of the database, the history of file and directory changes is placed in the corresponding directory.

Remote datasets and local databases

Git databases are divided into remote databases and local databases

Modification record submission

To save file or directory additions and changes to the database, you need to commit. After a commit is executed, a revision of the last committed state and the current state is generated in the database.

Commits are stored in the database in chronological order. With this commit and the latest file status, you can see past changes and what they were.

Working tree and index

Under Git, the directory in which you actually operate is called the working tree. There are indexes between the database and the working tree, and indexes are the areas in preparation for committing to the database.

Git does not save the state of the working tree directly to the database when it commits. Instead, it saves the state set in the middle index region to the database. Therefore, to commit a file, the implementation needs to add the file to the index region.

Git senior post

branch

In the introductory section, we briefly covered the basics of using Git. In the advanced section, we will first explain how to use and operate branches.

When developing software, there may be multiple simultaneous features or bug fixes for the same software, and there may be multiple releases that need to be maintained

What is a branch

The purpose of branching is to bifurcate the overall process of modifying records. Forks are not affected by other branches, so multiple changes can be made simultaneously in the same database.

Bifurcated branches can merge

To protect yourself from other developers, you can create your own dedicated branch on top of the main branch. When you are done, merge the changes on your branch into the main branch. Because a history of each commit is saved, it is much easier to locate and modify the commit that caused the problem when it does occur.

The master branch

After the initial commit to the database, Git creates a branch called Master. Therefore, subsequent commits will be added to the Master branch before switching branches

Use of branches

You can branch in Git. However, to make effective use of branches, you need to determine the rules for the use of two types of branches (“Merge branches “and “Topic branches “)

The merge branches

A merge branch is a branch created so that releases can be released at any time, and it can also be used as the source branch of a Topic branch. It is important to preserve branch stability. If changes are made, the topic branch is usually created first, and for that branch, the master branch is used as the Merge branch

Topic branch

Topic branches are branches created for tasks such as developing new features or fixing bugs. To do more than one task at a time, create multiple topic branches

The Topic branch is created from the stable Merge branch. After completing the task, merge the Topic branch back into the Merge branch.

Branch switching

To switch branches of a job, do the checkout operation. When you checkout, Git restores the changes committed to the target branch from the work tree. Commit records after checkout are appended to the target branch

HEAD

The HEAD points to the last update of the branch that is currently in use. The default usually points to the last update for the Master branch. By moving the HEAD, you can change which branch is used

stash

Uncommitted changes and newly added files are moved from the original branch to the target branch when they are left in the index area or in the working tree to switch branches.

But checkout will fail if the same file is modified in the target branch of checkout. Either commit the change first or use Stash to store the change temporarily and then checkout.

Stash is an area where file changes are temporarily saved. Stash holds changes in the working tree and index that haven’t been committed yet, and you can pull them out later and apply them to the original branch or to other branches

Merging of branches

The topic branch is merged back into the merge branch. There are two ways to merge branches: use merge or rebase. Using both methods, the history of the merged branches will be quite different.

merge

Using merge a process that merges multiple histories.

As shown in the figure below, Bugfix bifurcates from the Master branch.

Merging the Bugfix branch into the Master branch is very simple if the master branch’s state has not changed. The history of the Bugfix branch contains all the history of the master branch, so git merges by moving the master branch to the latest branch of Bugfix. This is called a fast-forward merge.

However, the history of the Master branch may be updated after the Bugfix branch forks. In this case, the changes from the Master branch are merged with the changes from the Bugfix branch.

rebase

Instance tutorial

Is not the concept of the front look in the clouds in the fog. That’s okay. Let’s just do an example.

Git checkout -b branch creates branches and switches

Remote database

pull

As we explained in the basics, pull can retrieve the history of a remote database. Next, we use diagrams to explain the details of the database commit.

First make sure there are no changes to the updated local database branch.

In this case, only the fast-forward merge is performed. The master in the figure is the master branch of the local database, orgin/master is the master branch of the remote database origin.

If the master branch of the local database has a new history, you need to merge the changes from both sides

Perform pull to perform the merge. At this point, the merge commit is automatically created if there are no conflicting changes. If a conflict occurs, resolve the conflict first and then manually submit it.

fetch

Perform pull, and the contents of the remote database are automatically merged. However, sometimes you just want to validate the contents of your local database rather than merge. In this case, use FETCH

Fetch retrieves the latest history of the remote database. The fetched references are imported into the unnamed branch, which can exit from a branch named FETCH_HEAD.

The label

The label is given an easy-to-understand name to make it easier to refer to a submission

Git can use two types of tags: light tags and annotation tags. The label is fixed and cannot be moved like a point.

Light label
- Add the name
Note the label
- Add the name
- Add annotations
- Add a signature

Typically, publishing tags use annotation tags to add annotations or signatures. Light labels are intended for temporary unemployment or one-time use locally.

Instance tutorial

Let’s actually do it again

Git tag -d <> git tag -d <>Copy the code

Rewrite submitted

This one is a little bit harder

Modify the most recent commit

If you specify the amend option to perform the commit, you can modify the most recent commit and comments for the same branch

Main applications

Add file letters that were missed in a recent submission
Modify recently submitted annotations

Cancels past commits

You can cancel a specific submission under Revert. You can delete the commit using the rebase-i or reset mentioned later. However, you can’t just delete a published commit; you need to create the one you want to negate through revert.