Git version management tool

Git version management tool

Git is a distributed version control tool. Its Author Linus Torvalds is introducing Git-The stupid content tracker (silly content tracker)

1. Git background

Git was originally written by Linus Torvalds and used as a version control tool for Linux kernel development.

Git is different from common version control tools such as CVS and Subversion. It uses a distributed version library without the support of server software, making it extremely convenient to publish and exchange source code.

Git is very fast, which is naturally important for large projects such as Linux kernel. The most outstanding thing about Git is its merge tracing capability.

In fact, when the kernel development team decided to start developing and using Git as the version control system for kernel development, there were a lot of objections from the open-source community in the world. The biggest reason is that Git is too difficult to understand, from the perspective of Git's internal working mechanism, this is indeed true. However, with the development in depth, normal use of Git is executed by some friendly script commands, making Git very easy to use, even if it is used to manage our own development projects, git is a friendly and powerful tool. Now, more and more famous projects use Git to manage project development, such as wine and hiphop-php.

Git, as an open-source and free-thinking project, does not impose any permission restrictions on the browsing and modification of version libraries. However, it can achieve limited permission control through other tools, such: gitosis, CodeBeamer MR. Originally, Git is only applicable to Linux/Unix platforms, but is gradually mature in the use of Windows platforms, mainly thanks to the easy-to-use GUI tools such as Cygwin and msysgit environments and TortoiseGit. In fact, the source code of Git has added support for Cygwin and MinGW compiling environments and has been gradually improved. It is a good news for Windows users.

2. Why Git?

Popular open-source software version management software, including CVS, SVN, and GIT version management tools. What are the advantages of Git?

For more information about how to get started with Git, see

Unlike CVS and SVN, Git is a distributed source code management tool. It is very powerful and fast. the Linux kernel code is managed by Git, which brings us the direct benefits:

1. initialization, git init, git commit-a, is complete. For anyone who writes two lines of code to the code management tool, it is not suitable. You can also use git as a backup system or synchronize the documents of the two machines.

2. Most of the operations are done locally, without interacting with the code management server in the cluster, and finally you can boldly check in code anytime and anywhere. Only the final version must be submitted to a centralized code management server.

3. Each commit creates a unique commit id for all codes. Unlike CVS, the version of a single file is changed separately. Therefore, you can check all the code before a certain submission at a time without considering the files submitted. (SVN can also do this)

4. branch management is much easier. No redundant directories need to be created, either by creating a new branch or by switching between branch.

5. When branch is merge, not only will the code be merge together, but the check in history will be retained, which is very important.

Linux git command parameters and Usage Details

Fedora downloads Git through Http Proxy

Install Git on Ubuntu Server

Create a Git repository on the server (Ubuntu)

Git simple tutorial in Linux (taking Android as an example)

Git authoritative guide PDF

Git has the following advantages:

1. More convenient Merge

Distributed Management will inevitably lead to a large number of Branch and Merge operations. Therefore, the distributed version control system pays special attention to this aspect. Creating Branch and Merge in traditional CVS is a nightmare. As a system used to replace CVS, Subversion improves Branch operations. However, it seems that Branch is easy, but what about Merge? If Merge cannot return easily, Branch is still a nightmare. As a matter of fact, I 've experienced a lot of code overwrites in Merge due to incorrect operations on my teammates in the development team. The subversion was used at that time. Although the source code is still in the history, it is really unforgettable to find the overwritten files one by one and restore them.

2. More convenient management

The traditional version control system uses a central warehouse, and some warehouse-related management can only be performed on the warehouse. It is very difficult to assign the management permissions of each person in the development team to the central warehouse. But sometimes it is inconvenient.

3. More robust systems

Distributed systems are generally more robust than single-server systems, because the entire system cannot run once the server fails. However, distributed systems are generally not affected by one or two nodes.

4. Less network-dependent

Although the network is very popular today, it does not have high-speed networks anytime, anywhere, or even sometimes there is no network to access. Low-speed networks can make people feel annoyed. Sometimes they just stare at the commit progress on the screen and cannot do anything. No network connection is even more fatal: you cannot commit! This means you must be careful before making any changes, or you may no longer find some code you have written.

5. Less "warehouse pollution"

Sometimes you need to create a module. It is not too large, so there is no need to create a branch for it, but it is not that small. It is impossible to do it right after one commit. Therefore, some incomplete code will be submitted to the warehouse, and sometimes the entire program will not run, seriously affecting the development of other people in the team. In this case, most people Submit the solution after writing it. However, for those who are used to version control, it is often a matter of making major changes without any consequence. Later, they suddenly find that their previous Code has not been submitted, and then they regret it. If it is a distributed system, there will be no such problem, because the modification of the Local warehouse will not affect others' warehouses. After you complete the test, you can say in the mail list: I have completed this module. Then the people you are interested in will be able to pull your achievements from you.

Although the reputation of Git on the Internet never stops, on the Git website, Git and Subversion are compared as objectively as possible (GitSvnComparsion ). In addition, Subversion currently uses SVK to provide distributed management capabilities for source code libraries, enabling offline submission of source code.

3. Git, CVS, and SVN comparison

In the project source code version management tools, the main commonly used tools include CVS, SVN, Git, and Mercurial.

Currently, Google Code supports three methods: SVN, Git, and Mercurial. For example, I uploaded linux-kernel-source (Git mode) and sdk-java (SVN mode ), so what are their differences?

Differences between Git and CVS

• Branches are faster and easier.
• Supports offline work. Local submission can be submitted to the server later.
• Git commit is atomic and the entire project scope, unlike in CVS, it is for each file.
• Each work tree in Git contains a repository with a complete project history.
• No Git repository is inherently more important than other repositories.

Differences between Git and SVN

Git is not only a version control system, but also a Content Management System (CMS) and a work management system. If you were a person with a SVN background, you can easily switch ideas to adapt to some concepts and features provided by Git. The main purpose of this article is to introduce what Git can do and what is the difference between Git and SVN in depth. Through comparison, we can help you better understand Git.

1. Git is distributed, SVN is not

   This is the core difference between Git and other non-distributed version control systems (SVN, CVS. If you can understand this concept, you will be half done. You need to make a statement that Git is not currently the first or only distributed version control system. Some other systems, such as Bitkeeper and Mercurial, are also running in the distributed mode, but Git is doing better in this aspect and has more powerful features.

   Git and SVN have their own centralized version libraries or servers. However, Git is more inclined to be used in the distributed mode, that is, each developer will clone a version library on their own machine after chect out code on the server of the central version library. It can be said that if you are stuck in a location that cannot connect to the network, like on the plane, in the basement, in the elevator, you can still submit files and view historical version records, create a project branch. For some people, this seems to be of little use, but when you suddenly encounter an environment without a network, this will solve your major troubles.

   Similarly, this distributed operation mode is also a huge gift for the development of open-source software communities. You do not have to make a patch package as before and send it by email, you only need to create a branch and send a push request to the project team. This keeps your code up to date and won't be lost during transmission. An outstanding example is GitHub.com.

   It is rumored that the future version of subversion will also be based on the distributed mode. At least not yet.

2. Git stores the content in metadata mode, while SVN stores the content by file

   All resource control systems hide the object metadata in a folder such as. svn and. cvs. If you compare the size of the. git directory with that of. svn, you will find that they are quite different. Because the. git directory is a clone version library on your machine, it owns everything on the central version library, such as tags, branches, version records, and so on.

3. Git branch and SVN branch are different

   The Branch is not special in SVN, that is, another directory in the version library. If you want to know whether a branch is merged, You need to manually run a command like thisSvn propget svn: mergeinfoTo check whether the code is merged. Therefore, some branches are often missed.

   However, it is quite simple and interesting to process Git branches. You can quickly switch between several branches in the same working directory. You can easily find unmerged branches. You can easily and quickly merge these files.

4. Git does not have a global version number, while SVN does

   So far, this is the biggest feature missing from GIT compared with SVN. You also know that the SVN version number is actually a source code snapshot of any corresponding time. It is the biggest breakthrough from the evolution of CVS to SVN. Git can use SHA-1 to uniquely identify a code snapshot, but this does not completely replace the easy-to-read numeric version number in SVN.

5. The content integrity of Git is better than that of SVN

   Git uses the SHA-1 hash algorithm for content storage. This ensures the integrity of the Code content and reduces the damage to the version library in case of disk or network problems. This is a good discussion about the integrity of Git content. (For more information, see diff)

For more details, please continue to read the highlights on the next page:

1 2 3 Next Page