The basic functions you need to master to play Git
version control
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.
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.
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.
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, other people 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 kept 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.
Distributed Version Control System
So the Distributed Version Control System (DVCS) came out. 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.
Get to know Git
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 a major difference between other Git 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 this file, 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 that 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 .
The three states of Git
Git has three states, and your file may be in one of them:
- Committed : The data has been safely stored in the local database.
- Modified : Modified means the file has been modified, but it has not been saved in the database.
- 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) as well as the staging area (Staging Area) .
The basic Git workflow is as follows:
- Modify the file in the working directory.
- Temporary file, put the snapshot of the file into the temporary storage area.
- Submit the update, find the files in the staging area, and store the snapshot permanently in the Git warehouse directory.
Quick start using Git
Obtain a Git repository
There are two ways to obtain a Git project repository.
- Initialization warehouse in an existing directory: project directory into the run
git init
command, which will create a named.git
subdirectory. - Clone an existing Git repository from a server:
git clone [url]
custom local repository name:git clone [url]
directoryname
Record each update to the warehouse
- Check the current file status :
git status
- 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) - Ignore file :
.gitignore
file - Submit updates:
git commit -m "代码提交信息"
(preparation before each submission, first withgit status
a look, is not it have been temporarily stored up, and then run the command is submittedgit commit
) - Skip use staging area updated :
git commit -a -m "代码提交信息"
.git commit
Plus-a
option, Git will automatically track all has been temporarily stores the documents to be submitted, thereby skippinggit add
steps. - Remove file :
git rm filename
( Remove from the staging area, then submit.) - Rename the file :
git mv README.md README
(This command is equivalent tomv README.md README
,git rm README.md
,git add README
a collection of these three commands)
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 use the following command to add: ·
git remote add origin <server>
, for example, we want to associate a local warehouse with a warehouse created on Github.git remote add origin https://github.com/dwyanewede/project-learn.git
-
Submit these changes to the remote repository:
git push origin master
(You can replace the master with any branch you want to push)So you can push your changes to the added server.
Removal and renaming of remote warehouses
- Rename test to test1:
git remote rename test test1
- Remove remote warehouse test1:
git remote rm test1
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 log
a command. git log
All 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=sxs
Undo 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 --amend
submission 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
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
Article reference source
https://github.com/Snailclimb/JavaGuide/tree/master/docs/tools
https://github.com/dwyanewede/JavaGuide/tree/master/docs/tools/ Enjoy GitHub.md like visiting Weibo and Moments
Article recommendation
Play GitHub like visiting Weibo and Moments
Official account recommendation
Welcome to follow the
official account , not only recommend the latest blog posts for you, reply [1024], you can also get massive programming materials and various resume templates!