Version control system

version control system, VCS　　 ) helps us to record and track changes in the content of each file in the project.

Distributed Versioning Systems (distributed version control system, DVCS　　 Also, its main goal is to help document and track changes made in the project. The difference between it and the traditional version control system is that developers synchronize the changes to each other in different ways.

Version Library The Repository

　　The repository (Repository) is where the version control system stores all the historical data.

Most version control systems store the current state of each file in the repository, the time it was modified, who made the changes, and the reason for the change.

Version control systems such as CVS and Subversion belong to the centralized repository (centralized Repository) mode . In this mode, all programmers will commit their changes to a common repository on the server. In the local working directory tree, you can see only the latest version of the code, and if you want to query history to modify records, you must deal with the repository on the server. This poses a problem: You must use the network.

If you are using a Distributed version control system , you will not encounter problems with the inability to surf the internet.

This is the biggest advantage of a distributed version control system represented by Git.

Instead of connecting to a common repository on the server, everyone will have their own repository on-premises. All historical records are stored in the local repository.

Working directory tree working Trees

　　The working directory tree is where programmers develop their programs.

In a traditional version control tool, the working directory is local, and the repository is on the server, not in Git.

　　In Git, the repository is not on the server and is stored in the ". Git" directory of the local working directory tree.

　　There are two ways to create a working directory tree initially:

1. Initialize the repository with GIT-related commands, generate a ". Git" directory, and the parent directory of the ". Git" directory becomes the working directory tree.

2. Cloning an existing repository also creates the corresponding working directory tree.

code modification and file synchronization manipulating files and staying in sync

Each commitoperation will cause a new version (Revision) to be added to the repository.

In addition to recording the changes themselves, the repository also records the changed log message (log message) or the submission message (Commit message).

When using a distributed version control system like Git, in addition to committing changes to the local repository, there is a way to share the changes so that other programmers can get them. To do this, you need to pushthe changes into the upstream repository (upstream repository), which is the public repository.

The push-in is half the code synchronization, and the other half is the need to get the work done by others from the public repository to the local repository.

　　Specifically, it takes two steps to get the changes from the remote repository to the local repository:

1. Take the changes (fetch) and take the changes from the remote repository to the local repository.

2. Merge the contents of the fetch and the local changes (merge).

In Git, you can do both of these things with a singlecommand: Pull.

using tags to track milestones Tracking milestones with tags

　　Tags mark a particular point in the repository history with a simple name (that is, the sign signature).

In essence, a tag is a name that is easy to understand and easy to remember for the user, and is used to identify a hard-to-read build number in the repository to help users track historical versions.

using branches to track parallel evolution Creating Alternate histories with Branches

Create a starting point for the branch in the repository. Since then, the road has developed in parallel.

Each branch records changes that occur on this branch and is isolated from the other branches.

The main branch (master Branch) is the main line of research and development, and some version control tools also call the main branch trunk.

Branches can exist for a long time, or they can exist for only a few hours. A branch can be merged into another branch, but not all branches must be merged.

Merging merging

The merge operation merges two or more two branches together.

git automatically handles branch merging in the same way that programmers do manually: Git compares the changes on each branch to determine where the change takes place-where the file is located.

Git can merge automatically when different changes occur in different parts of the file. But

The situation is not always ideal, and when git does not merge automatically, it will prompt for conflicts (conflict).

lock mechanism Locking Options

Strict lock (strict locking): one moment, only one person can occupy resources.

Optimistic lock (optimistic locking): Allows multiple people to modify the same file at the same time. Optimistic locking is based on the assumption that, most of the time, this concurrent modification does not cause a conflict.

Some conventions

　　The GIT first letter capitalization indicates the Git tool itself.

　　git represents a command in the command line.

　　Prompt> represents the command that needs to be entered.

Basic Commands

　　Set user name and mailbox:

prompt> git config--global user.name "Xxxname"

prompt> git config–global user.email "[email protected]"

Use the following command to check whether the above settings are successful:

prompt> git config--global--list

　　To start the graphical interface:

Prompt> Git-gui

Start GITK:

Under the working directory tree prompt> GITK

Show the history in the repository:

Prompt> Gitk–all

　　Get git built-in Help information:

Prompt> git Help

prompt> git help <command>

Where you want to know the specific command name instead of <command>

The page of the corresponding command in the document will be displayed in the browser.

Version control system