In order to become an architect, in addition to learning to master Java advanced knowledge points, you must also learn to use one of the three essential tools (Git)

One, version control

1. What is version control

Version control is a system that records changes in the content of one or several files for future review of specific revisions. In addition to the project source code, you can version control any type of file.

2. Why version control

With it, you can backtrack a certain file to its previous state, or even roll back the entire project to the state at a certain point in time in the past. You can compare the details of the file changes to find out who modified which place in the end. In order to find out the cause of the weird problem, who reported a certain functional defect when and so on.

3. Local version control system

Many people are used to copying the entire project directory to save different versions, perhaps renamed and added backup time to show the difference. The only advantage of this is simplicity, but it is particularly easy to make mistakes. Sometimes it will confuse the working directory where it is located, and accidentally write wrong files or overwrite unexpected files.

In order to solve this problem, people have developed many kinds of local version control systems a long time ago, and most of them use a simple database to record the previous update differences of files.

4. Centralized version control system

Next, people encountered another problem, how to let developers on different systems work together? As a result, a centralized version control system (Centralized Version Control Systems, CVCS for short) came into being.

The centralized version control system has a single centralized management server that saves all revisions of files, and people working together connect to this server through the client to retrieve the latest files or submit updates.

Although this solves the criticism that the local version control system cannot allow developers on different systems to work together, there are still the following problems:

• Single point of failure : If the central server is down, others cannot use it; if the central database disk is damaged and there is no backup, you will lose all data. The local version control system also has similar problems. As long as the history of the entire project is stored in a single location, there is a risk of losing all history update records.
• Must be networked to work : Affected by network conditions and bandwidth.

5. Distributed version control system

So distributed version control system (Distributed Version Control System, referred to as the DVCS) appeared. Git is a typical distributed version control system.

In this type of system, the client does not only extract the latest version of the file snapshot, but mirrors the code repository completely. In this way, any server used for collaborative work can be restored afterwards using any mirrored local warehouse. Because every cloning operation is actually a complete backup of the code repository.

The distributed version control system can work without networking, because everyone's computer is a complete version library. When you modify a file, you only need to push your own modifications to others. However, when actually using a distributed version control system, it is rare to push changes directly, but to use something that acts as a "central server". The function of this server is only to facilitate the "exchange" of everyone's modifications, and everyone can do the same without it, but it is inconvenient to exchange and modify.

The advantage of a distributed version control system is not only that it does not have to be connected to the Internet, but we will also see Git's extremely powerful branch management functions later.

Two, know Git

1. A brief history of Git

The Linux kernel project team used the distributed version control system BitKeeper to manage and maintain the code. However, the commercial company that developed BitKeeper later ended the partnership with the Linux kernel open source community, and they took back the right of the Linux kernel community to use BitKeeper for free. The Linux open source community (especially Linus Torvalds, the creator of Linux) developed its own version system based on the experience and lessons learned when using BitKeeper, and made many improvements to the new version control system.

The main difference between Git and other version management systems

Git is very different from other version control systems when it saves and treats various information. Although the command forms are very similar, understanding these differences will help prevent confusion in your use.

Below we mainly talk about one major difference between Git and other version management systems: the way it treats data .

Git uses a method of recording snapshots directly, rather than comparing differences. I will introduce the difference between these two methods in detail later .

Most version control systems (CVS, Subversion, Perforce, Bazaar, etc.) store information in the form of file change lists. This type of system treats the information they save as a set of basic files and each file is gradually accumulated over time The difference .

The specific principle is shown in the figure below. It is actually very simple to understand. After we submit and update a file, the system record will record what updates have been made to the file, which is represented by the delta symbol Δ (Delta).

How can we get the final version of a file?

Very simple, basic knowledge of high school mathematics, we only need to add these original files and these additions.

What's wrong with this approach?

For example, if our increment is very large, if we want to get the final file, will it take time and performance?

Git does not treat or save data in the above manner. Conversely, Git treats data more like a set of snapshots of a small file system. Every time you submit an update or save the project state in Git, it mainly takes a snapshot of all the files at the time and saves the index of this snapshot. For efficiency, if the file is not modified, Git will not re-store the file, but only keep a link to the previously stored file. Git the data to be more like a snapshot stream .

3. The three states of Git

Git has three states, and your file may be in one of them:

1. Committed : The data has been safely stored in the local database.
2. Modified : Modified means the file has been modified, but it has not been saved in the database.
3. Staged : Indicates that the current version of a modified file is marked to be included in the next snapshot.

Thus introducing the concept of three working areas of the Git project: Git repository (.git directoty) , ** the working directory (Working Directory) ** and staging area (Staging Area) .

The basic Git workflow is as follows:

1. Modify the file in the working directory.
2. Temporary file, put the snapshot of the file into the temporary storage area.
3. Submit the update, find the files in the staging area, and store the snapshot permanently in the Git warehouse directory.

Three, Git quick start

1. Obtain the Git repository

There are two ways to obtain a Git project repository.

1. Initialization warehouse in an existing directory: project directory into the run git initcommand, which will create a named .gitsubdirectory.
2. Clone an existing Git repository from a server: git clone [url]customize the name of the local repository:git clone [url] directoryname

2. Record each update to the warehouse

1. Check the current file status :git status
2. Propose changes (add them to the staging area) : git add filename(for specific files), git add *(all files), git add *.txt(support wildcards, all .txt files)
3. Ignore file : .gitignorefile
4. Submit updates : git commit -m "代码提交信息"(preparation before each submission, first with git statusa look, is not it have been temporarily stored up, and then run the command is submitted git commit)
5. Skip use staging area updated : git commit -a -m "代码提交信息". git commitPlus -aoption, Git will automatically track all has been temporarily stores the documents to be submitted, thereby skipping git addsteps.
6. Remove file : git rm filename( Remove from the staging area, then submit.)
7. Rename the file : git mv README.md README(This command is equivalent to mv README.md README, git rm README.md, git add READMEa collection of these three commands)

3. A good Git commit message

A good Git commit message is as follows:

Title line: Use this line to describe and explain your submission

The main part can be a few lines to add more details to explain the submission. It is best to give some relevant background or explain what problems the submission can fix and solve.

Of course, the main part can have several paragraphs, but you must pay attention to line breaks and sentences not to be too long. Because in this way, when using "git log", the indentation is better.

The title line description submitted should be as clear as possible and summarized in one sentence as much as possible. This facilitates the display of related Git log viewing tools and other people's reading.

4. Push changes to the remote warehouse

• If you have not cloned an existing warehouse and want to connect your warehouse to a remote server, you can add it using the following command:, For · git remote add origin <server>example, if we want to associate a local warehouse with a warehouse created on Github, we can do thisgit remote add origin https://github.com/Snailclimb/test.git
• Submit these changes to the remote repository: git push origin master(You can replace master with any branch you want to push)

So you can push your changes to the added server.

5. Removal and renaming of remote warehouses

• Rename test to test1: git remote rename test test1
• Remove remote warehouse test1: git remote rm test1

6. View submission history

After submitting several updates, or cloning a project, you may want to review the submission history. Accomplish this task the most simple and effective tool is git loga command. git logAll updates will be listed by submission time, with the most recent update at the top.

You can add some parameters to see what you want to see:

Just look at someone’s submission record:

git log --author=bob

7. Undo the operation

Sometimes we found that a few files were missing and not added after the submission, or the submission information was written incorrectly. At this point, you can run with a -- amendsubmission attempt to resubmit the command options:

git commit --amend

Unstaged files

git reset filename

Undo the modification of the file:

git checkout -- filename

If you want to discard all your changes and commits locally, you can get the latest version history on the server and point your local master branch to it:

git fetch origin 
git reset --hard origin/master

8. Branch

Branches are used to insulate feature development. When you create a repository, master is the "default" branch. Develop on other branches and merge them into the main branch after completion.

We usually choose to create a branch when developing new features, fixing an urgent bug, etc. Whether single-branch development is better or multi-branch development is better, it still depends on the specific scenario.

Create a branch called test

git branch test

Switch the current branch to test (When you switch branches, Git will reset your working directory to make it look like it was back to the last commit you made on that branch. Git will automatically add, delete, and modify files to Make sure that your working directory at this time is exactly the same as when the branch was last committed)

git checkout test

You can also create a branch directly like this and switch to it (combination of the above two commands)

git checkout -b feature_x

Switch to the main branch

git checkout master

Merging branches (may have conflicts)

git merge test

Delete the newly created branch

git branch -d feature_x

Push the branch to the remote warehouse (visible to others after the push is successful):

git push origin

---

Reference material: "Comprehensive Analysis of Java Intermediate and Advanced Core Knowledge" is limited to 100 copies. Some people have already obtained it through my previous article!
Seats are limited first come first served! ! ! There are more Java Pdf learning materials waiting for you! ! !
Students who want to get this learning material can click here to get it for free """""""