This is the 13th day of my participation in the August More Text Challenge. For details, see:August is more challenging

If you’ve ever written an article in Word, you’ve had this experience. I think a certain paragraph or a certain sentence is not well written, but after deleting it, I may regret deleting it, and then I want to get the deleted paragraph back. At this time, you think of a good way to save every revision as a version of the article, which can solve your problem. However, as you make more and more changes, you will find that there are more than one copy of Word on your desktop, and you can no longer tell when each copy corresponds to the change. So you think, what if I had a program that would not only automatically keep track of every change I made to a file, but also let my colleagues collaborate on editing it, so I don’t have to manage a bunch of similar files myself, and I don’t have to pass them around. Wouldn’t it be convenient to just glance at a change in the software if you wanted to see it? With that in mind, you should learn about Git. What is Git? Git is the most advanced distributed version control system in the world. Since it is the most advanced, we must certainly learn it well and master it well. So, starting with this blog post, I’ll be documenting a series of Git tutorials and making them available as learning materials.

Let’s start with a story. As many of you know, Linus founded the open source Linux system in 1991. Since then, Linux has grown to become the largest server system software. Linus may have created Linux, but Linux has grown because of volunteers around the world. So many people are writing code for Linux all over the world. How is Linux code managed?

In fact, before 2002, volunteers around the world sent source code files to Linus via Diff, and Linus himself merged the code by hand!

You might be wondering why Linus doesn’t put Linux code in version control. Aren’t there free version control systems like CVS and SVN? Because Linus is staunchly opposed to CVS and SVN, these centralized version control systems are slow and require networking. There are some commercial version control systems that are better than CVS or SVN, but they are paid for, which is not in keeping with the open source spirit of Linux.

By 2002, however, the Linux system was a decade old, the code base was too large for Linus to continue to manage manually, and members of the community were angry about it. Linus chose BitKeeper, a commercial version control system. BitKeeper’s owner, BitMover, has granted the Linux community free access to its version control system as a humanitarian effort.

The good situation of stability and unity was broken in 2005, because of the Linux community’s great people gathered together, inevitably tainted by some liangshan heroes. Andrew, the Samba developer, tried to break BitKeeper’s protocol (he wasn’t the only one), and BitMover caught him (nice monitoring!). BitMover is furious and wants to take back its free rights to the Linux community.

Linus could apologize to BitMover and promise to keep the boys in line. Well, that’s not going to happen. Here’s what happened:

Linus spent two weeks writing his own distributed version control system in C, called Git! Within a month, the source code of the Linux system was managed by Git!

Git quickly became the most popular distributed version control system, especially in 2008, when GitHub launched, which made Git storage free for open source projects, and countless open source projects started migrating to GitHub, including jQuery, PHP, Ruby, and more.

By accident, if BitMover hadn’t threatened the Linux community, we wouldn’t have Git for free and super useful.

This is the history of Git.

So first let’s talk about installation. Git is available on Linux, Mac, and Windows. I’m going to use the Windows environment as an example because most of you are using Windows. On Windows, you can download git by simply going to the Git-for-windows.github. When the installation is complete, click on the Start menu, find Git, and open it. This indicates that git has been installed successfully. Before you use Git, you should first report your name, otherwise your code can’t be submitted.

$git config --global user.email $git config --global user.emailCopy the code

Since I have submitted my user name and email, I print my information here. From this we know that the command for setting the username and email is also the command for viewing the message. So let’s take a look at a commit and see that there’s really nothing to git. It’s important to remember the git instructions and what each one means. Let’s switch to the desktop

cd Desktop
Copy the code

Then create a new folder on the desktop. This folder will be our working directory

mkdir rrd
Copy the code

Then switch to the working directory

cd rrd
Copy the code

We initialize a code repository in the working directory

git init
Copy the code

With the repository in place, we can work from the working directory. Create an index. TXT file in the directory and write the Hello Git content.

cat >> index.txt
Copy the code

Enter cat to create a file, press Enter, wait for you to enter the contents of the file, enter CTRL + D to save and exit. We enter

hello git
Copy the code

Then, let’s take a look at the status

git status
Copy the code

The red box means that nothing was added at the time of the commit except the untracked file (use “Git Add” for tracking). Note Our index.txt file is not tracked by git. We use git add to track the file.

git add index.txt
Copy the code

This directive can trace index.txt, but if the file is very large, this is obviously very tedious to write, so we can use

git add .
Copy the code

Track all files in the current directory. We then commit the file to the repository.

Git commit -mCopy the code

-m means “comment”. Please put your comments on this submission in quotation marks. At this point, we have completed a version management. Note that in the git with the concept of a staging area, can you don’t know what is the staging area, first you only need to know, after we add the file, the file will be first on the staging area, this file has not been submitted, so you can withdraw your file into the staging area, at any time when you commit, the file will be from the staging area code has been submitted to the warehouse.

We now modify the file

vi index.txt
Copy the code

You can enter vim’s editing mode by typing I, o, or a. Once in editing mode, make some simple changes to the contents of the file. Then press Esc to exit editing mode and enter command mode. You can exit the editor without saving the changes. Enter :wq to save the changes and exit

git status
Copy the code

Git will tell you that your workspace has been changed, so you type in

Git add. Git commit -mCopy the code

Our changes are then synchronized to our repository.

Let’s demonstrate deletion. Let’s create a file again and submit it to the repository, but I’m sure you can’t beat that, so I’ll just post all the steps.

Cat >> demo.txt git add. Git commit -mCopy the code

At this point, type git Status to check the status.

The workspace is empty, indicating that our workspace and the repository have been synchronized. Then, we delete the file we just created.

git rm demo.txt
Copy the code

Enter git status again to check the status.

Git will notice that you have deleted the file. Notice that if you want to synchronize your workspace with your repository, you don’t need to add

Git commit -mCopy the code

In this way, the repository demo.txt file will be deleted. If you delete files manually, you need to add them, but if you use git rm to delete files, Git will help you put them directly into the staging area, so you can commit your delete directly.