Today, Git is in the middle of nowhere, and I don't understand git, I am embarrassed to tell people that he is a program ape. Have you already been eager to try it out, but just suffer from no excuses? Well, the opportunity is today. Give me 20 minutes, yes, as long as 20 minutes, let you quickly use git.
We don't talk much nonsense, come directly to dry goods.
We will introduce the following:
First, what is git
Second, the general development process using git
Third, quickly install new projects. holloworld.
One, what is git.
The prerequisite for reading this article is that you know or have used at least one source code management tool, such as SVN, CVS or TFS. You must know what is source code management. If these are not satisfied. Please skip this article.
The best way to understand strange things is to compare them with known things. ---Confucius
Let's take svn as an example. We all know that traditional source code management is server-centric:
Each developer is directly connected to the intermediate server, modified locally, and then committed to the svn server.
This approach seems perfect, but it has fatal flaws:
1. Developers cannot track code versions locally. All information is on the server. You changed the local code a lot, but you can't submit it. Normally, only one version can be cached locally. It doesn't matter for small projects, but once the project is complicated, it will be troublesome if you have more people. Usually your local code is all red. I don't know what was changed today, and what changes should really be submitted to svn.
2. Because of the first point, once you leave the server, the program will not work properly. Because the code version cannot be tracked locally. Your (almost) any operation must be connected to the server. For example, show log, blame, show history, etc.
3. The central server is under excessive pressure. Because everyone must submit the code to the server and do daily build.
4. For large projects, svn is hardly available. For example, the Linux kernel project, more than tens of thousands of developers? If you submit it directly to the svn server, it is not a mess.
5. For personal private projects (or for small company projects), of course not using version control, but it is a bit reluctant to set up an svn server specifically for version control.
Is there anything that can solve the above problems? Well, the answer is yes.
The author of the Linux kernel also encountered these problems, so he decided to change the world again and rewrite an svn that can be used locally.
Yes, this is git. Distributed code version management system. (Speak people: svn without server)
Let's look at the structure of git:
git does not have a central server. After you install the git software, you can specify a local folder for version control. You can unplug the network cable, and then modify, commit, revert (rollback), branch, restore, show log, blame, history, etc. locally, all the operations you can use in svn before. Simply put, you are perfect.
You may realize a problem. The world is in chaos.
Everyone develops on their own, how do they collaborate? Well, usually git has two more operations than svn, namely pull and push.
We look at a more complicated diagram:
Developers use pull and push operations to pull over others' modifications or push their own modifications to others.
Well, you may still think there is a problem. Whose code is the final version in our production environment?
This problem is really tricky because, from a purely technical perspective, each developer's machine is equivalent. No major or minor.
We still have a way:
We can solve the problems that cannot be solved technically. ---- Mencius
From a distributed environment we simulated a center:
We introduce the role of Leader. His machine is the final version. Every developer must push the final modified version to the leader. The leader will review and submit. He is the final version.
Well, we seem to have missed a big question, saying that git, why did you miss github. What is github.
We know that if everyone changes it locally, it may not be safe locally (the hard disk is broken and the laptop is stolen ...)
We may need a secure server to store / back up the code. For open source projects, you may need a place to share your code. You cannot open your laptop 24 hours a day and let others pull the code from you.
As a result, so-called source code hosting websites on the Internet came up. github is like this.
Looking at this picture, I have only modified one of them, that is, replaced the leader machine. Online account from github.com.
Therefore, git and github are not necessarily related.
Here are a few commonly used online hosting addresses, interested to see for yourself:
1. github.com, famous. Free, only open source projects are supported, private projects are not supported.
2. bitbucket.com is also famous. Free, supports open source and private projects. Free users up to 5. Projects are unlimited.
3. git.oschina.net, the top hosting platform in China, this is what I am using. Supports open source and private projects. Unlimited members, 1,000 projects. Alibaba Cloud server is used, which is extremely fast. I recommend 5 stars.
Second, the general process of git development.
The above has actually covered the general structure of using git. So how does git apply in a production environment?
The models I know are as follows:
Each developer submits code to his own project server (leader), and the leader submits to the company server. Of course this leader is optional. If the project is small, developers can submit directly to the company server. The company's server is the final version. Generally companies also have continuous integration CI servers. We can set up a git hook on the company's source server. Automatically trigger CI server work. This is an afterthought, not much to say.
Third, once the previous concepts are clear, it is much easier to get started. We are helloworld.
1. This is git's official website: http://git-scm.com/ to download the windows client.
If it is linux, sudo apt-get install gitcore
2. Note that the clients on the official website are all command line. The command line is high-level usage. I won't say it here. Our next gui.
I use TortoiseGit. http://code.google.com/p/tortoisegit/ , I am afraid everyone is familiar with turtle crawling in the svn era. Get started quickly. The following operations are all on gui.
Not to mention the installation process. All the way next. We skip. Go straight to the end. Suppose you have installed it now.
For example, I already have a project, helloworld:
This is the internal structure of the project file:
Now we want to let helloworld use git. Right click on the project root directory.
Choose Create repository.
Do not check this option. We will explain what Bare is later.
Then it's done.
There is an extra .git directory inside. The current directory (and all its subdirectories) is already under git monitoring. But the current code has not been added to git's tracking database. Simply put, git has not stored any version information. We need to make the first submission:
By default, git will have a master branch master.
We write some comments and tick the files we want to add to git. (If there is a subdirectory, it will be displayed here.)
After submitting, close. This push button will be mentioned later.
OK, this time we are back in the folder and see what has changed:
These files are now added to git.
The rest you can do whatever you want. Like svn, try a few commands yourself: modify, difference, commit, revert,
At this point you have started.
Finally, we introduce two important concepts.
1. The "git directory" refers to the ".git" folder generated in the project root directory in the figure above. Students who have used svn know that svn has a '.svn' folder. Their role is similar. This saves git's local database information. That's all version information. What is different from svn is that in git, this directory exists only in the root directory and not in all subdirectories, that is, there is only one .git directory for each project.
2. The "git working directory" is actually your project directory, such as the project root directory in the picture above: H: \ mycode \ helloworld \. Why is there this working directory? That is, you work in this directory, you can modify the files in the editor, and finally submit the changes to the git directory. Another amazing thing about this co-working directory is that you can create different branches (you work under master by default). When you switch between different branches, all files in your working directory (project directory) will become File corresponding to the current branch. This does not expand.
Finally, the two questions left above are explained:
1. "Bare" Creating Bare means: You only want git's database (that is, the ".git" folder in the picture above), and you don't want the current file. This is usually used on a company's central server. It doesn't need the actual code of the current project, it just needs to keep the git database information.
2. The meaning of push in the dialog after commit. As explained earlier. The consciousness of push is to push your changes to others (or to a public server). Commit means just commit to the local .git database. Not updated to others. So after submitting, the turtle gave us a push button. Through it you can quickly push the changes you just made to others, or to the server.
In summary, this is not a complete git manual, but at least it will help you get rid of git phobias and get started quickly.
Here is the Chinese version of gitbook: http://gitbook.liuhui998.com/ He is really big and comprehensive. Why did you say it in the end? Because it is like a great Oxford dictionary, comprehensive and authoritative. But for kindergarten children learning English, you can't memorize it as soon as you come up. Follow others first, it's important to get started. After that, there is nothing wrong, and then go to the dictionary.