Table of contents
1.1. Local version control system
1.2. Centralized version control system
1.2. Distributed version control system
4. The working principle and process of git
5. Use of git (trilogy of local warehouse management: modify, add, submit)
5.1. Git configuration (create folders that need to be managed)
5.2. Configuration information
5.3. How to save modifications to the temporary storage area
1. About version control
What is "version control"? Why should I care about it? Version control is a system that records changes in the content of one or several files so that you can check the revision status of a specific version in the future. In the examples shown in this book, we version control files that hold software source code, but in fact, you can version control any type of file.
If you are a graphic or web designer, you may need to save all revisions of a certain image or page layout file (this may be a feature you are very eager to have). Using a version control system (VCS) is a wise choice. With it, you can roll back the selected file to its previous state, or even roll back the entire project to the state at a certain point in the past. You can compare the change details of the file and find out who last modified which place. , to find out what caused weird problems, who reported a certain functional defect when, and so on. Using a version control system also usually means that even if you mess around with and delete files throughout the project, you can still easily restore them to their original state. But the additional workload is minimal.
1.1. Local version control system
Many people are used to copying the entire project directory to save different versions, and perhaps changing the name and adding the backup time to show the difference. The only advantage of doing this is that it is simple, but it is also very easy to make mistakes. Sometimes the working directory is confused, and the wrong file is accidentally written or an unexpected file is overwritten.
In order to solve this problem, people have developed many local version control systems a long time ago, most of which use some kind of simple database to record the differences in previous updates of files.
Figure 1. Local version control.
One of the most popular is called RCS, and it can still be seen on many computer systems today. RCS works by saving a patch set on the hard disk (a patch refers to the change before and after file revision); by applying all the patches, it can be recalculated The file contents of each version.
1.2. Centralized version control system
Next, people encountered another problem, how to let developers on different systems work together? As a result, Centralized Version Control Systems (CVCS) came into being. Such systems, such as CVS, Subversion and Perforce, have a single centrally managed server that saves revisions of all files, and people working together connect to this server through clients to retrieve the latest files or commit renew. This has become standard practice for version control systems over the years.
Figure 2. Centralized version control.
This approach brings many benefits, especially compared to the old-school on-premises VCS. Now, everyone can see to some extent what others in the project are working on. Administrators can also easily control the permissions of each developer, and managing a CVCS is far easier than maintaining local databases on each client.
There are two sides to everything, good and bad. The most obvious disadvantage of doing this is that the central server is a single point of failure. If it is down for one hour, no one can submit updates during this hour, and no one can work together. If the disk on which your central database resides becomes corrupted and you don't back it up properly, you will undoubtedly lose all data - including the project's entire change history, leaving only the individual snapshots that people keep on their respective machines. A similar problem exists with local version control systems. As long as the entire project's history is kept in a single location, there is a risk of losing all historical update records.
1.2. Distributed version control system
So the Distributed Version Control System (DVCS for short) came out. In such systems, such as Git, Mercurial, Bazaar, and Darcs, the client does not only extract the latest version of the file snapshot, but completely mirrors the code warehouse, including the complete history. In this way, if any server used for collaborative work fails, any mirrored local warehouse can be used to recover afterwards. Because every cloning operation is actually a complete backup of the code repository.
Figure 3. Distributed version control.
Furthermore, many of these systems can be designed to interact with several different remote code repositories. This way, you can collaborate with people from different working groups on the same project. You can set up different collaboration processes as needed, such as hierarchical model-based workflows, which was not possible in previous centralized systems.
2. What is git?
Git is a distributed source code management tool (version control tool).
Git’s data is more like a series of snapshots of a miniature file system (this snapshot is similar to creating a snapshot in a virtual machine). With Git, every time you commit or save the project state, Git will completely mirror the code repository, including the complete history, and store a reference to the snapshot. For efficiency, if the file hasn't changed, Git won't store the file again, just a link to the last identical file it already stored. Git thinks of its data more like a snapshot stream and stores the data as a snapshot of the project for a period of time. Version management of projects from very small to very large can be handled efficiently and at high speed. He is also the "Father of Linux", an open source version control software developed by Linus Torvalds to help manage the development of the Linux kernel.
With the development of computer technology, the structure of software is becoming more and more complex and the scale is getting larger. Version control, code hosting and collaborative development in software development are also becoming more and more important. Git is a distributed version control system. It is powerful, easy to operate, and can solve the above problems well.
3. What is the role of git?
When you need to do a big project, the file management is very huge, because you need to constantly modify and update the file content, and you may also need to keep the old version to ensure that it can be restored, so you need to back up multiple versions of the file. .
And in most cases a project needs to be maintained by a majority of people. In this case, it is also very troublesome to merge the modified content between different people. In this case, you can use git to easily solve these problems. Also when writing projects on a daily basis, effective project version control can bring you great convenience and a high fault tolerance rate!
4. The working principle and process of git
5. Use of git (trilogy of local warehouse management: modify, add, submit)
5.1. Git configuration (create folders that need to be managed)
Directly use cmd to enter the command line interface
Initialize the folder: Use thegit init command to initialize it as a local repository
Come to the folder to verify
This file with the suffix .git is very important, do not delete it
5.2. Configuration information
Since Git is a distributed version control system, when using it for division of labor and collaboration, different machines must be distinguished. This can be done by configuring the machine's name and email address. GitDuring initial use, you will also be prompted for configuration. The configuration command is as follows: it config –global u
$ git config --global user.name "Your Name" // 配置git的用户名$ git config --global user.email "[email protected]" // 配置git的邮箱地址- $ git config --list // View all git configuration information
In actual use, you can replace “Your Name” and “email@example” with your actual name and email address.
5.3. How to save modifications to the temporary storage area
According to the git usage process explained above, the local version library is equivalent to a local warehouse, which records various versions of our local files and the differences between different versions. When we add, delete, or modify files, we must add the changes to the workspace to save them temporarily. To add modifications and save them to the workspace, you need to use the git add command. The git add command is used as follows:
#Add all changes to the staging area
git add .
#Add the specified file to the temporary storage area, for example, hello.txt is specified here.
git add hello.txt file
Above: First create a test file, hello.txt
5.4. Check the workspace status
When you have created hello.txt and have not added it to the staging area, if you use the git status command, you will get something similar to the following Output (Chinese):
# 位于分支 master## 初始提交## 未跟踪的文件:# （使用 "git add <file>..." 以包含要提交的内容）## hello.txt提交为空，但是存在尚未跟踪的文件（使用 "git add" 建立跟踪
What is this? This is a reminder that there are modified files in your workspace that have not been submitted to the temporary storage area. After you execute git add, you will get output similar to the following:
# 位于分支 master## 初始提交## 要提交的变更：# （使用 "git rm --cached <file>..." 撤出暂存区）## 新文件： hello.txt#
As for No commits yet: This is to remind you what content in the staging area needs to be submitted to the local warehouse.
In fact, thegit status command is used to check the status of the current workspace, that is, which files have been modified but have not yet been submitted to the temporary storage area. In the actual development process, when faced with complex program files, you often need to check which files you have modified. In this case, the git status command is very useful.
5.5. Undo modifications
Detailed explanation:
git checkout -- The function of filename is to undo the modifications of the filename file in the workspace to the content of the most recent git add or git commit
For example, in the check.txt file of the workspace, initially put a line of content "one" in it, then perform git add, and then git commit
At this time, edit check.txt and add a line of content "two". At this time, check.txt has not been added or committed.
Call cat check.txt and you will see that the file content of check.txt has indeed been changed.
At this point call git checkout -- check.txt
After the call is completed, the content of check.txt returns to the time when there is only one line of content, because the most recent operation on check.txt was a commit operation! Therefore, the content of check.txt in the workspace is undone to the content of check.txt during the most recent commit operation.
In git, checkout means "checkout". This command is used to switch branches or restore working tree files. The syntax is "git checkout branchName" or "git checkout parameter option branch".
checkoutThe command usage is as follows:
git checkout hello.txt
After we modified the project version to v2.0, without making any additions or submissions, we suddenly found a business logic error in the project. At this time, we can use the git checkout file name to restore the project to the most recent submission or temporary save. In the status of the area, we have just submitted v1.0, now execute git checkout file name
View the file contents again;
5.6. How to submit changes to the local warehouse
Adding changes to the staging area only temporarily saves your work and does not add it to the local warehouse. This process can be compared to writing a file. Adding modifications to the temporary storage area is equivalent to putting the content into the cache area first. Therefore, we must submit the contents of the workspace to the local repository to truly save the modifications.
To submit changes to the local warehouse, use the commandgit commit. Its usage is as follows:
git commit -m "示例提交"
-mThe parameter is followed by the specific content of this submission, which is used to describe the modifications you have made in this submission. This description is required.
The local explanation ends here!