I first learned about Git through exposure to the well-known open source community Github, but never learned it systematically. This time, I am determined to learn it systematically from beginning to end, and I will also record the learning process here for your criticism. This post starts with a brief look at Git in the following ways.

• An introduction to Git and how Git relates to GitHub
• Git download and initialization information configuration
• Git's basic commands and what they mean

I. Introduction to Git and the relationship between Git and GitHub First of all, Git was created by Linus Torvalds, the creator of Linux. When the great man opened Linux in the spirit of open source, it was necessary to manage the code of thousands of contributors, initially all the code was sent to Linus by email, and then he would integrate it manually. But as Linux gets bigger and bigger, the amount of code gets bigger and bigger, and it can no longer be managed entirely by people. Linus then chose to manage the code using a commercial system, BitKeeper, a full-fledged version control system, until the two partnerships ended in 2005. So the Linus gods spent two weeks writing out a version control system in C, the now unbeatable Git. (That's what cows look like! ), want to learn more about the history of Git, you can check the information yourself, here is a brief interception of part of the time to stimulate interest in git.

A version control system is a type of system used to manage our project progress points, giving a record of each change and allowing for immediate rollback in case of errors. Think about the changes we usually make to files, once the changes are made, the previous content will be lost, that is, you want to go back to some unmodified state in the past, it is impossible to do so. And we use a version control system to track our project files, and every change is recorded and can go back at any time. Here we won't discuss the difference between centralized and distributed version control systems, we'll just tell you about Git's distributed nature, and you'll understand the various advantages of distributed when you're done learning.

We are probably more familiar with GitHub than Git. It is an open source community and a platform. Many great projects are open sourced on it for programmers around the world to learn and refine. For example: apache/tomcat, eclipse/jetty, jquery/jquery, etc. We say that Git can record every change we make to our work files so that we can quickly restore them, but in order for multiple people to work together, we need to share the same project source code, so we usually put the project source code on a server, and each developer downloads the latest project from the server and works on it, and pushes the changes they made to the server after they finish working on it, so that everyone is developing (modifying) every feature of the project all the time, and of course the project located on the server will record every commit change made by everyone all the time. (The culprit can be found quickly if something goes wrong). And with GitHub as an open source community platform, it can act as that server. However, since it is open source, it is also generally not recommended to use GitHub as a public server for internal company projects. You will usually build your own server configured as a Git server and use it in the intranet.

2、 Git download and initialization information configuration Of the three platforms, I'll introduce Git installation from the windows platform that I use myself, as for the installation on Linux and MacOS you can check the information yourself. Installation of Git on the windows platform is simple, just go to https://git-for-windows.github.io downloadingmsysgit and install it with a single click. msysgit is integrated with Git and Cygwin, Cygwin is a tool to simulate Linux/Unix environment in windows, because Git is required to use some tools of Linux/Unix, so someone integrated both to make it possible to use Git in windows platform. Here we briefly talk about the configuration of the initialization information for Git. First after the installation is complete， The right mouse button will add theGit Bash here options， that isGit The command line mode of the， We click to display the command line window。 The first thing we have to do is tellGit， Identity of this machine。 Because later on, when we're working with multiple people， each timeGit The current submitter will be signed at the time of submission， but (not)Git How the information about the submitter was learned？ That's what we tell it when we initialize the message。

$ git config --global user.name "Your name"
$ git config --global user.email "Your email"

Generally we can configure the above two information, as for other information configuration, such as: the default editor, etc., you need to use when you can check the information simply configure it. At this point, a brief introduction to Git is basically complete, so let's look at a few of the longest used Git commands and their meanings in everyday projects.

III. Basic Git commands This subsection is the core of this post and deals with initializing the repository, adding trace files, staging files, committing to the local database, restoring to a previous state, etc. These basically cover the most common operations in everyday projects, but they are not enough to get a more flexible grasp of Git to make the most of its great role in project management. Here we look at the first command, initialize the repository.

1、git init This is a command used to initialize the repository. Executing it will create a .git folder in the current directory, which is used to manage changes to all files in the current directory. For example, I create a folder single in the F drive of my computer, cd to that directory in the git command line, and then execute git init , which results in the following.

When you open the current directory, you see a folder .git, which is the result of the init command execution, and it is the core of the entire version control. As for the structure of the content inside we cover it in a subsequent post.

From then on, the f:/single directory is a workspace, and files in this directory are trackable by git.

2、git add filename We said that after initialization, files in the workspace can be tracked, but git will only explicitly track that file if you tell it which files need to be tracked, otherwise git will always tell you what other files the workspace uses to be in Untracked status when you commit. And our add command is used to explicitly tell git which files to start tracking from this point on. For example, we create a file test.txt in the workspace above, and then track any changes to that file using the following command.

git add test.txt

Of course the command can be used multiple times to add tracking to multiple files. Sometimes, we add a trace of all files for convenience using the following command.

git add .

Of course the first function of this add command is to add tracking to untracked files, and the second function is to save changes to a file in the workspace. For example, we created a file test and tracked it with the add command, so let's enter something for the file (you can just enter something random if you've made changes to the file). We then submit the current status of.

You see, git tells us that the file test has been modified, but you didn't do a save, all this time no changes added to commit, there's nothing to commit. And when we add save the file after the changes.

This time, git tells us that this commit has been successfully added to the master branch, with one file change compared to the last commit status.

2、git commit Before we introduce commit commits, let's take a brief look at the general structure of git. A deeper understanding of its structure will be learned in a subsequent article, here is to make it easier to understand the differences in the objects of several commands. First, git has three blocks, a workspace, a staging area, and a branch.

The workspace is what we can see, the so-called "current directory". There are a lot of files in that directory, and these are the files that we keep track of for version control. The staging area, also known as stage or index, holds a single modification of the workspace, as above we used the add command to save the changes to a file, recording the current snapshot of the file. Then we commit to the branch with the commit command, and each point located on the branch is left behind by one commit. And of course we roll back to the specified point as needed when we roll back.

One may wonder why there is a staging area, wouldn't it be better to just work the area against the branch? In fact, this is more efficient. In general, each commit on a branch represents an important feature completion, and we can't say that we commit every bit of code we write, which would result in too many commits, and it's not easy to quickly find the point you want to roll back in the future. So git uses a staging area to save every little change, and when all the changes are done, the commit command will update the staging changes to the branch to complete a commit.

It's easier to understand our commit command below, which commits all the contents of the staging area to the branch to form a single commit. We generally only commit once after completing a complete module or feature, and smaller changes are generally saved in the staging area first.

3、git clone When we come across a good open source project and want to participate in it, we need to get all the code of someone else's project, and that's when our clone command comes into play. We create a repository on the remote server, create a new file index.txt, and then we use the clone command to complete the action of copying the remote repository.

Then we open the directory under f://1testgit to see a complete copy of the repository test, and inside the test directory is our complete project plus the version control files. One note here, we can specify the name of the copied repository after the command, if not explicitly specified it will be the same as the remote by default. For example.

git clone https://github.com/Programer-yang/test.git myResptory

This way the name of the local repository is no longer the same as the remote one, it is explicitly changed to myResptory. In short, to use the clone command, you first need to know the address of the repository that will be cloned, either based on the http protocol or the git protocol, and then we need to go to the specified directory and optionally specify the local name of the repository being cloned down.

4、git status This command can be a bit confusing with the diff command we'll cover next, but the difference is also obvious if you grasp their essence. The first thing we need to know is that the status command is used to view the status of the current workspace, meaning it will compare the status of all files in the current workspace with the most recent commit on our local branch and list all the changes made. For example, we create a file test in the current directory and type something simple, commit to the master branch (at this point the workspace and staging area and local branch are clean and the same), and we execute the status command to also get the following output.

It tells us that the contents of the workspace and the branch are exactly the same, and that there are no extra changes. But when we execute the status command after modifying the contents of the index file, we get the following result.

The output clearly tells us that the workspace has made changes to the file index compared to the most recent commit in the local branch, and has not yet been saved to the staging area. This is an additional feature of this command. If it is in red font it means that you have not only modified the workspace but also not saved it to the staging area, if it is in green font it means that you have modified the workspace and saved it to the staging area. WATCH.

Above we briefly introduced the basic use of the command status, and below we introduce the diff command.

5、git diff The diff command is also used to view the current status, only it differs from status in that it compares the difference between the workspace and the staging area. For example, for a clean workspace, we modify the index file and then execute the diff command. The output is as follows.

As we can see from the output, the diff command gives us a detailed list of the differences between the current workspace and staging area file states. For example, the diagram above tells us that the staging area file (red font represents all the contents of the staging area file) has only one line of information in index hello world, while the current workspace (green font represents the contents of the workspace file) has two lines of information in index. If you are multiple files that have changed, then this command will list all the contents before and after all the modified files for the programmer to see.

Of course the diff command we described above is unparticipated, so it compares the difference between the workspace and the staging area, and we can also use parameters to specify a comparison between the workspace, the staging area, and the local branch. For example.

 git diff --cached: compares the difference between the staging area and the local branch

 git difff HEAD: compares the differences between the workspace and the local branch

So it seems that for viewing the differences between the states of the three different zones in git we can all do it with the diff command. Obviously, the diff command is more detailed than the status command, but the status command has its own use cases.

6、git log This is a command that helps us view historical commit information, e.g.

We can see that the output is mainly the id corresponding to the successive commits and the committer's information time, as well as the description information of the commit. Of course the most important thing is this SHA-1 value consisting of 40 hex digits, so that each commit corresponds to a unique id and also makes it easy for us to roll back the historical version. The following is a brief description of some of the options parameters for this command. Using the log command with parameters or options can provide us with more intuitive information to quickly get to what we need.

Direct usegit log command will output a history of all commits， Sometimes we just need to see the submission information a few times into， Then you can use-<n> option to explicitly specify the output of thecommit number of times。 for example：

We can also use the -pretty=xxx parameter to specify the simplicity of the output commit message, there are some parameter values to choose from, oneline, short, full and fuller. For example.

You can try to practice the output of other parameters by yourself.

Another option is -p, we often have descriptions for a commit, but sometimes these descriptions are not very accurate and we want to be sure of the changes made in this commit, so we can use the -p option to output the changes made in this commit. For example.

The output tells us that the command lists all the changes the current commit has made to the files in it. Same output as our diff command.

7、git reset One of the most important things we use git for is to be able to roll back historical versions at any time, and our reset command does that. For example, we create a file index in the git workspace then do a commit (description message one), then we type something for the index file and commit it again (description message two), so we build two commits, the latest one being two, and we can fall back to one using reset.

We see that the two latest commits before the fallback are two and one, but when we fallback to the previous version, the original latest commit is discarded and the head pointer points to one. A point of clarification here is that the head^ symbol indicates the id of the previous commit, and we can fall back using the unique identifier of a particular commit in addition to falling back that way, e.g.

As you can see, we successfully fall back to the version described as "the forth commit". Obviously, we are using the unique identifier of the commit to fall back, so for any one commit, we can fall back directly based on its identifier. However, it is important to note that the execution of the reset command will directly result in the workspace, staging area, and local branch being identical, i.e., the working tree is clean, so it is important to carefully check if any content has not been saved before backing out, otherwise it will result in a total loss.

So far, this article has briefly introduced a few common commands of git and their simple applications. Of course git has many commands, we just listed a few common ones, as for some other commands part will appear in subsequent articles, we will also introduce the very core content of git: branching, which is also a key point for git to be able to collaborate with multiple people. The series of articles refer to a number of books and web tutorials, and I hope you will point out where the summary is not.

Recommended>>
1、The data in the blockchain is not necessarily real
2、Technical parameters of industrial robots
3、python multithreaded get subthreaded task return value
4、JavaScript Basic Learning 03 Image Flip
5、The secret to achieving 10 million concurrency

已发送

发送中