Git Version Management tool (i)

Source: Internet
Author: User
Tags hosting mercurial using git version control system

Git is a distributed version Control tool, and its author, Linus Torvalds, introduces us to git--the stupid content tracker (a fool-like tracker)

1. Git background

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

Git and common version control tools, such as CVS, Subversion, it uses a distributed version of the library, without server-side software support, so that the release and exchange of source code is extremely convenient.

Git is fast, and it's naturally important for big projects like Linux kernel, and the best thing about Git is its combined tracking (merge tracing) capabilities.

In fact, when the kernel development team decided to start developing and using Git as a kernel-developed version-control system, the world's open source community had a lot of objections, and the biggest reason was that git was too difficult to understand, and that was true of Git's internal working mechanism. But with the development in-depth, Git's normal use is done by some friendly script commands, which makes git very useful, and even for managing our own development projects, Git is a friendly and powerful tool. Now, more and more famous projects use Git to manage project development, for example: wine, hiphop-php, etc.

Git, as an open source free fundamentalism project, does not have any permission restrictions on repository browsing and modification, but can also achieve limited permissions control through other tools, such as Gitosis, Codebeamer MR. The original git use range is only applicable to the Linux/unix platform, but gradually and matured in the use of Windows platform, mainly due to Cygwin and msysgit environment and tortoisegit such easy-to-do GUI tools. In fact, Git's source code has been added to the Cygwin and MinGW build environment support and gradually improved, for Windows users is a boon.

2. Why Choose Git

The popular software version of open source management software, with CVS, SVN, git version management tools, the advantages of git?

Git Getting Started tutorial, please check my Baidu Space blog:blog

Git and CVS, SVN, is a distributed source control tool, it is very strong, and soon, the Linux kernel code is git-managed, it brings us the direct benefits are:

1. Initialize, git init, git commit-a, it's done. For anyone who writes two lines of code to a Code management tool, it's a good fit. You can also take git as a backup system, or synchronize the documentation for both machines.

2. Most operations are done locally, without interacting with a centralized code management Server, and can finally be bold to check in code anytime, anywhere. Only the final completed version needs to be submitted to a centralized code Management Server in a central.

3. Each commit will create a unique commit ID for all code. Unlike CVS, there are changes to individual files that are versioned separately. So you can check out all the code before a commit at a time without having to think about submitting those files. (In fact, SVN can do this)

4. Branch management is much easier, whether it is to create a new branch, or to switch between the branch a command to complete, do not need to create a redundant directory.

5. When you merge between branch, it is important not only that the code will merge, but also that check in history will be preserved.

The main advantages of Git are:

1. More Convenient Merge

Distributed management inevitably leads to a large number of Branch and Merge operations. Therefore, distributed version control systems pay particular attention to this aspect. Creating Branch and Merge in traditional CVS is a nightmare, and Subversion is a system for replacing CVS that specifically improves Branch operations. However, it seems that people have not noticed that Branch is easy, but Merge? If it is not easy to Merge back, doing Branch is still a nightmare. As a matter of fact, I've been in the development team and I've covered a lot of my code in the Merge because of the wrong team-mates. It was the subversion that was used. Although the source code is still in the history, it is really a memorable thing to go and find the overwritten file and recover it.

2. More Convenient management

Traditional version control systems use central warehouses, and some warehouse-related management can only be carried out on warehouses. It is very bad to give the management authority of each person's central warehouse in the development team. But sometimes it's really inconvenient.

3. More robust systems

A distributed system is always more robust than a single-server system, because once the server has hung up the entire system will not be able to run. However, distributed systems are usually not affected by one or two of nodes.

4. Less dependence on the network

Although the network is very popular now, it does not have high-speed network anytime and anywhere, even when there is no network to access. Low-speed networks can make people cranky, and sometimes stare at the commit progress on the screen, and nothing can be done. And no network connection is more deadly: you can't commit! This means you have to be careful before you make any changes, or you may never find some code that you have written.

5, less "warehouse pollution"

Sometimes you have to do a module, it is not too big, so there is no need to create a new branch for it, but it is not so small, it is not possible to do a single commit. You will then submit some incomplete code to the repository, which can sometimes cause the entire program to run out of control and seriously affect the development of others on the team. Most of the solutions in this case are written and then submitted. But as a person accustomed to versioning, it is often the case that a large, reckless modification is a common thing, and it is too late to regret that the previous code has not been submitted. In the case of a distributed system, there would be no such problem, since modifications to the local repository would not affect other people's warehouses. When you're done and tested, you can say in the mailing list: I've got this module ready. Then the interested person can pull your results from you.

While there is no end to the beauty of Git's reputation on the web, git and subversion are compared as objectively as possible on Git's main station (Gitsvncomparsion). In addition, subversion currently through the SVK has also provided a certain degree of source code library distributed management capabilities, can realize the source of offline submission and other functions.

3, Git, CVS, svn comparison

Project source code version management tools, the more commonly used are: CVS, SVN, Git and Mercurial (which, about SVN, see my previous blog: SVN common command and SVN server configuration)

Google code currently supports SVN, git, mercurial three ways, such as: I upload the Linux-kernel-source (git mode), Sdk-java (SVN mode), then what is the difference between them?

The difference between git and CVS

    • Branching is faster and easier.
    • Support offline work; Local commits can be submitted to the server later.
    • Git commits are atomic, and are scoped to the entire project, rather than to each file as in CVS.
    • Each work tree in Git contains a warehouse with a complete project history.
    • No Git repository is inherently more important than other warehouses.

The difference between git and svn

Git is not just a version control system, it is also a content management system (CMS), work management system and so on. If you've ever been a person who has used an SVN background, you can easily change the mindset to accommodate some of the concepts and features that Git offers. The main purpose of this article is to help you get to know git better by comparing what git can do and how it differs from svn in depth.

  1. Git is distributed, and 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, then you are already half-done. There is a need to make a statement that Git is not the first or only distributed version control system. Some systems, such as Bitkeeper, Mercurial, and so on, are also running in distributed mode, but Git does better and has more powerful features.

    Git has its own centralized repository or server like SVN. But Git is more inclined to be used in distributed mode, where each developer Chect out code from the server on the central repository and clones its own repository on its own machine. It can be said that if you are trapped in a place where you can't connect to a network, like on a plane, basement, elevator, etc., you can still submit files, view historical version records, create project branches, and so on. For some people, this doesn't seem like much use, but when you suddenly encounter a network-free environment, this will solve your big problem.

    Similarly, this distributed mode of operation is a huge boon for the development of the open-source software community, and you don't have to make patch packs like you did before, send them by email, you just need to create a branch and send a push request to the project team. This will keep your code up-to-date and will not be lost during the transfer, one such good case:

    There are rumors that the future version of Subversion will also be based on distributed mode. But at least not yet.

  2. Git stores content as metadata, and SVN is file-based

    All resource control systems hide the meta-information of a file in a folder similar to. svn,. CVS, and so on. If you compare the size of the. git directory with the. SVN, you will find that they are very different. Because the. Git directory is a cloned version of the repository on your machine that has everything on the central repository, such as tags, branches, release notes, and so on.

  3. Git Branch differs from SVN's branch

    The branch is not special in SVN, it is another directory in the repository. If you want to know if a branch has been merged, you need to manually run a command like this, svn propget svn:mergeinfo, to verify that the code is merged. Therefore, there are often cases where some branches are missing.

    However, the branch that handles git is quite simple and fun, and you can quickly switch between several branches from the same working directory. You can easily find the branches that have not been merged, and you will be able to merge these files easily and quickly.

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

    So far this is the biggest feature that git lacks in comparison with SVN. As you know, the SVN version number is actually a snapshot of the source code at any given time, and it is the biggest breakthrough in the evolution from CVS to SVN. Git can use SHA-1 to uniquely identify a code snapshot, but this does not completely replace the easy-to-read digital version number in SVN.

  5. Git has better content integrity than SVN

    Git's Content store uses the SHA-1 hashing algorithm. This ensures the integrity of the content of the code and ensures that the repository is compromised when disk failure and network problems are encountered. This has a good discussion about the integrity of git content. (English original reference: diff)

Comprehensive comparison of Cvs-svn-git

First of all, the article introduces several versions of control software comparison of the important basis:

(1) repository model (Repository models): Describes the relationship between multiple copies of the source repository, with both client/server and distributed modes. In client/server mode, each user accesses the main repository of the server through the client, and each client only needs to save a copy of the file it is interested in, and changes to the current working copy (working copy) will only be visible to other users after committing to the server. In distributed mode, these source repository replicas are peer entities, and the user's machine has a history of the local repository, out of which to save their working copy.

(2) concurrency mode (Concurrency model): Describes how to manage this conflict when making changes or edits to the same working copy/file to avoid generating meaningless data, with exclusive lock and merge mode. In exclusive lock mode, only the user who makes the request and obtains the current file exclusive lock can make changes to the file. In merge mode, users can edit or change files at will, but they may be notified at any time that there is a conflict (two or more users editing the same file at the same time), and the version Control tool or user needs to merge the changes to resolve the conflict. As a result, almost all distributed version control software uses a combined approach to resolve concurrency conflicts.

(3) Historical model: Describes how to store the change information of a file in a repository, with snapshots and a change set of two modes. In snapshot mode, the repository stores the working copy before and after the change, and in the change set mode, the repository saves only the changes that have occurred since the change occurred, in addition to saving the working copy of the change.

(4) Scope of change: Describes whether the version number is for a single file or the entire directory tree.

(5) Networking Protocol (Network Protocols): Describes the network protocol used to synchronize multiple versions of libraries.

(6) Atomic commit (Atomic Commit): Describes whether all changes are guaranteed to be committed or merged, or no changes will occur, when a change is committed.

(7) partial clone (partial checkout/clone): Supports copying only specific subdirectories in the repository.


Version Library model

concurrency mode

Historical mode

Scope of Change

Network protocol

Atomic Commit

Partial cloning











3-way Merge, Recursive

Merge, Octopus merge

Changeset and Snapshot


Custom (SVN), custom (SVN) over SSH,






Merge or lock



Custom, custom over SSH, rsync,

Http/https, email, bundles



Trunk, Branches, Tags differences:

Trunk: The main line in the software development process, the directory where the development version is stored, that is, the code in the development phase is submitted to the directory, and the information from the repository to the current is saved.

Branches: A branch of the software development process, a directory where the release version is stored, that is, a stable version of a project released at the time of the launch is stored in the directory, saving the current information from a specific point in the repository (not necessarily when the repository is built).

Branches are primarily used for exploratory or experimental development of new features without affecting other users of the trunk, and it can be incorporated into trunks when new features are perfected.

(In the original, please refer to my blog in the Baidu Space: Git command parameters and usage of detailed)

4. Use of Git on Windows

Git was built for Linux, and its original creator was the founder of Linux--linus Torvalds

In Linux, there is no difference between using git and any of the command-line tools in Linux, and there is a clear advantage even in the number of keystrokes.

There are only two ways to use git in a Windows environment:

1. Using Cygwin(a Linux environment running on windows)

2. Using msysgit(graphical interface and command line available under Windows)

Cygwin and Msysgit use a similar approach, Cygwin has a lot of Linux features, if you just want to use GIT functionality, Msysgit is the simplest and fastest way.

In order to have the ability to collaborate with others through the Internet, a public source code hosting service is required for the project. Fortunately, there are already a lot of options available to us, especially githost, is a Chinese source code hosting service provider. For the time being, the number of projects settled on Githost seems to be a newly-born service provider. If the project has a high level of stability in service delivery, it is better to choose an older git source-code hosting service. If you're working in a local area network, it's easier to use Git for source control, install your own git, and specify that someone is responsible for managing the Git repository.

(1) About GitHub

GitHub is developed using Ruby and has a refreshing interface.

GitHub offers free source code library hosting, as well as a paid hosting service. Financial support for the ongoing operation of the free section is supported through paid private library hosting services.

GitHub offers a unique set of code-base management interface features and the ability to provide project wikis.

GitHub offers a range of guides, official website: GitHub

(2) Installing Git on Windows system

First, download and install the Msysgit program: Download

Next, install the downloaded Git-1.7.10-preview20120409.exe, you can choose the latest version of Git, to achieve better use effect.

The installation process is simple, and you can basically use the default settings. Just be careful when setting the path, to avoid surprises with Windows paths, or use Git Bash-only for security.

Msysgit There are two ways to use the command line and graphical UI, depending on your preference, the graphical UI may not be able to do all the work, so in some cases (such as creating SSH keys), the command line is essential. Msysgit's bash command line has a bad support for Chinese, and all of the characters are displayed as "? ”。 Therefore, in order to avoid trouble, it is best to avoid the use of Chinese file name, directory name and user name, etc.

The Msysgit graphical interface is as follows:

(In the original, please refer to my blog in the Baidu Space: Git interface GUI and command line commands two ways of operation)

(3) Set GitHub

To use GitHub, you first need to create an SSH key,ssh that will be used to encrypt the communication between the native and the remote server, and also to identify the changes you have made to the code.

SSH key can be generated using the GIT command line, and if you already have an SSH key, you can use it directly here.

To use Git to create an SSH Key, you first need to open the git Bash command line and enter the command:

Ssh-keygen-c "[Email protected]"-t RSA

Note: [email protected] need to be replaced by your own email address

The program will ask some questions, accept the file default location, when asked to enter the pass phrase, if the local security is not a problem, you can not enter. Locate the file in the file storage location that was developed at the time, which is the SSH public key file that needs to be used when requesting an account on GitHub.

In the register to select the free account, in the subsequent interface in accordance with the requirements of the corresponding content can be completed registration, very simple.

5. Git Service Related

1. Establish a git remote server:

There seems to be no git server on Windows yet, which is a powerful advantage of Linux in the open source community! ^_^

Hosting Git repositories, the easy (and Secure) way:gitosis

2. Git-based source code hosting


Gitorious is another free hosting site with a custom Web interface, supporting multiple repositories per project, Local in Stallations and with Open source is the oldest hosting site, accommodating many hundreds of projects, with open-sourced infrastructure and aimed At open source software. IT provides full push features as well as simple mirroring mode and Gitweb interface with various enhancements.

GitHub provides both free hosting for smaller projects and paid options for private hosting and large-sized projects. It uses a custom web interface including a wiki hosting and puts emphasis on social networking of project developers

3. Useful links to Git:

Git-scm:go URL

Git reference:go URL

GIT-SVN Crash course:go URL

Everyday GIT with Commands Or so:go URL

Git User ' s Manual (for version 1.5.3 or newer): Go URL

Getting Started with Git and GitHub on Windows:go URL

Git Version Management tool (i)

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.