Git (2) version control, development history, initial configuration, aliases

Taking this a step further, many of these systems can be designed to interact with several different remote code repositories. This allows us to collaborate with people from different working groups on the same project.

When a distributed version control system manages a project, it does not store the differences between project versions. It stores indexes (the disk space required is very small, so each client Can put down the entire project history).

1.3 Comparison of two version control systems

Centralized (svn)

Advantages:

• The code is stored on a single server to facilitate project management.

Disadvantages:

• Since file differences are stored, the rollback speed will be very slow;
• The server is down and the code written by employees cannot be protected;
• You cannot create a new branch locally, and you need to create a new branch on the server every time;
• The server disk is corrupted and every project’s history is lost.

Distributed (git)

Advantages:

• Since the index is stored, the rollback speed is extremely fast;
• Distributed storage, no need to worry about server downtime or damage;
• Supports new local branches and is easy to operate.

Disadvantages:

• There are more operating commands than svn, and there is a learning cost.

2. Development history

Like many great things in life, Git was born in a very creative era.

The Linux kernel open source project has a large number of participants. Between 1991 and 2002, the vast majority of Linux kernel maintenance work was spent on the tedious task of submitting patches and saving archives. By 2002, the entire project team began to use the distributed version control system BitKeeper to manage and maintain code.

By 2005, the partnership between the commercial company that developed BitKepper and the Linux kernel open source community ended. This forces the Linux open source community (especially Linux Torvalds/Linus Torvalds, the creator of Linux) to stir things up. Only by developing a version control system of its own can the problem be avoided. Repeat the same mistakes. They set several goals for the new system:

• Fast branch switching, small capacity (compression), simple design, fully distributed
• Strong support for non-linear development models (allowing thousands of parallel development branches)
• Ability to manage extremely large-scale projects like the Linux kernel (speed and data volume)

Since its birth in 2005, Git has matured and matured day by day. While being highly easy to use, it still retains the goals set in the early days. It is very fast and is extremely suitable for managing large projects. It also has an incredible non-linear branch management system that can cope with various complex project development needs.

3. Initialization configuration

Generally on new systems, we need to configure our own Git working environment first. The configuration only needs to be done once, and the current configuration will be used during future upgrades. Of course, if necessary, we can always modify the existing configuration with the same command.

3.1 Configuration File

Git provides a git config command to configure or read the corresponding working environment variables, and it is these environment variables that determine the specific working methods and behaviors of Git in each link. These variables can be stored in three different places:

• /etc/gitconfig file: A configuration that is universally applicable to all users in the system. If you use git config --system, this file is read and written.
• ~/.gitconfig file: The configuration file in the user directory is only applicable to this user. If you use git config --global, this file is read and written.
• .git/config file: the configuration file in the Git directory of the current project (that is, the .git/config file in the working directory). The configuration here is only valid for the current project .

Note: Each level of configuration will overwrite the same configuration of the upper level.

3.2 Configuration content

The main things you need to configure are your personal username and email address. These two configurations are very important. Each time Git commits, these two pieces of information will be referenced to explain who submitted the update and how to contact them. Therefore, they will be permanently included in the history along with the update content.

--Configure username
git config --global user.name "ACGkaka"
-- Configure email address
git config --global user.email [email protected]
-- View configuration information
git config --list
-- Delete configuration information
git config --global --unset user.email

4. Aliases

Git doesn’t automatically infer the command you want when you type part of it. If you don’t want to type the full Git command every time, you can easily set an alias for each command through the git config file.

For example:

git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status

When you want to enter git commit, you only need to enter git ci.

Finished, finishing with flowers~

Reference address:

1. [Silicon Valley] Deeply understand the underlying principles of Git丨A mastering git version control system, https://www.bilibili.com/video/BV1Yi4y137eF/