Windows Git+tortoisegit Easy-to-use tutorials

Reprinted from http://blog.csdn.net/jarelzhou/article/details/8256139

Official tutorial: http://tortoisegit.org/docs/tortoisegit/(English version)

Why Choose git efficiency

A lot of people have a habit of it, what software should be up-to-date, the best. In fact, software is tools, productivity tools, to improve our productivity. If the existing tools are already able to meet productivity requirements, there is no need to change them. The level of productivity should be the first of the selection tools.

History

The open source World version control system, has undergone so many generations:

The first generation, CVS, pioneering products, so far many of the old projects are still in use, but there are many design flaws.

The second generation, SVN, improved significantly on CVS, quickly replaced the CVS status, the number of projects is still very large, and the SVN flaw is not much, many commercial projects do not seem to migrate to the next Generation version control system. For example, Chrome is using SVN.

Third generation, Hg and Git. Speaking of these two, there is a kind of both born to yoga, Sheng sense feet. The two projects were almost simultaneously launched, with the goal of providing a reliable, open source distributed version control system for Linux kernel, just as good, except that Git was Linus personally, so Git became the Linux choice. In addition, eclipse from the original SVN transferred to Git, and Firefox and Python use Hg, the domestic Kingsoft software also use HG, and cocos2d is git, which is good or bad, not to say.

In general, the first two generations due to centralized management defects, now will certainly be less, but the old project is often not easy to change. Git wins in powerful, branch-perfect, defeated in the design complex, difficult to understand. HG wins in a clear and understandable, functional, defeated in the adverse from the SVN migration, the corresponding community activity is not as good as GitHub.

We'll use Git for the time being, and maybe we'll try another one later.

What is TORTOISEXXX?

Maybe you've seen the three projects of TortoiseSVN, Tortoisegit and TORTOISEHG, and you might want to know what these three things are. In fact, SVN, Git, and HG are all command-line programs, and for most people, especially under the Windows platform, it's hard to get started and the threshold is large, and these three projects solve this problem. Tortoisexxx will add most of the versioning features under the Windows right-click menu, eliminating the hassle of the command line. But to tell the truth, the efficiency of the right-click menu and the efficiency of the command line which is high, not to say, but tortoisexxx still lowered the threshold, for beginners have a great help, after all, not everyone can memorize so many orders.

Ready to work Software installation

I mean under Windows. Since git never had the official Windows edition (understandably, Linus), there were two unofficial uses under Windows, one Cygwin and the other msysgit. Cygwin more ferocious, directly to the GNU Toolset transferred to Windows, but not recommended, Cygwin this thing, if not to do embedded, do not need to cross-compile, not so ferocious, msysgit is enough, and more simple. The current is 1.8.0.

Tortoisegit also supports two ways to use Git. It's just a shell, the actual call or Git itself. There is nothing to say about the two software installations, except for the installation path, all of which are OK by default.

Tortoisegit after installation, please set your name and mailbox, which will be recorded in the version information. Start menu to find Tortoisegit's settings, do not elaborate?

Secret key

Git's authentication is not a password, but a key. Usually we have a git server, and our computer is the work machine, and we need an RSA key to confirm the identity. The key is divided into two: private and public, in fact, the public store on the server, and the private in your hands, check the time through a series of complex algorithms can be matched. The private key must never be seen by others, which is an identification of the identity of each person in a project.

A key can be generated from the command line. But we have tortoisegit, look at Tortoisegit's Start menu, is there a thing called Puttygen? Key this thing has a lot of tools can be generated, Puttygen is a graphical tool. Use is very simple, as long as run Puttygen, the lower right corner of the value to 4096 (this is the longest) and then click "Generate" on it. When clicked, it will ask you to move the mouse randomly until the progress bar is full.

After the build? Never close this window! If the hand is off, then ... Let's do it again. You have to enter the password in passphrase and the confirmation box below, this password you write it yourself, but remember oh. After writing, click Save Private key to keep it.

Public key is populated on the server, we take GitHub for example, if it is another code hosting site, or you build it, the principle is the same. Open your GitHub account, Edit yourprofile, then ssh to keys, then add, and then paste the public key generated by Putty into the line.

That little thing about GitHub.

GitHub is currently the most active project hosting site in the open source community, with similar sites and Sourceforge,bitbucket,google code, and each site supports a different version control system, mainly SVN, git and hg,github only support git. Other protocols require cumbersome plug-ins to be extended and are rarely used.

Although Git itself is distributed, we usually still need a central server as a standard to facilitate collaborative development. GitHub has played this role.

Typically we do this collaboratively: the project has several members, the creator creates the project on GitHub, and adds others to the project. Project team members can submit code directly to the Central Library, and others who want to participate will need to use fork to create a branch copy of the project, then submit a merge request to the original project, and the submission of non-project team members requires approval to be merged. This is also the usual development pattern for open source software: The core member-led direction, all developers can participate in.

Of course, non-open source projects are not that troublesome, as long as project members submit code to the central repository.

Git work Flow

Don't worry, we need to have a clear understanding of Git's basic workflow before we can use it formally.

Start with a single branch of the local library

Git is distributed, so the libraries on the server are the same as your local libraries, and the libraries on both sides have complete historical version information. In fact, if there is no server, then the members can also be directly synchronized with the code, but this will be very confusing. This is very different from a centralized system such as SVN and CVS.

Let's look at the local single branch library first.

File status

The two basic states of a file: Being traced, and not being traced.

The reason is simple, there are code files in the project that we need to control, and temporary files that are not needed. If we add a new file, it is not tracked by default and you need to take the initiative to add it to the trace file (add action).

For tracked files, there are three states, modified (modified), staged (staged), committed (commit).

Modified: You have modified a file in the original library, and Git will detect that you have modified it because the checksum of the file has changed. At this point we need to do a staged operation.

Staged: After the modification, you can temporarily write the changes to the buffer, after accumulating a few changes enough to make up a commit, and then commit (commit) to the local library once. In fact, the above-mentioned "add" operation, the complete should say what? It should be "add files to Stage".

Submitted: Note that this commit is submitted to the local library because there is also a complete code base locally.

The staging history is not recorded and only information from the commit to the library is recorded in the repository and can be rolled back at any time.

Maybe sometimes you think that the staging area in the middle is going to do it? A lot more than that. The small project certainly doesn't matter at all, but if the project is big, the historical information of the version will be very complicated. This time, unnecessary version too much, also not good. Staging area is used to prevent unnecessary commits.

Role of the Branch

Branching is one of the most prominent places in Git.

In fact, the concept is very simple, look at the name will know, but why branch?

For example, a project, now to develop a function and B function, how to deal with?

It is also very simple, such as having a central library, then you clone to the local, make some changes, commit to version A, and I, commit to version B, then? Merge it? What is the result of merging, after merging, if there is no problem with the code, if A and B two functions we do not need to backtrack, then nothing is the problem. But often in reality, what happens if a suddenly has a problem.

The branch is going to be used: We have a trunk branch, then separate a branch and B branch, you do yours, I do mine, and then confirm the error after merging into the trunk. So, if there is a problem, is it easier than the original to solve more? Otherwise you don't know where the problem is.

Process

In real development, there are often at least two long-term branches (develop,master), with the latest progress in develop, while Master is a stable and reliable version that can be released at any time. Of course, the code in develop is also a complete code that can be run, and cannot have torn code. There are a number of temporary branches in development that will be used to develop new features, merge into develop after confirming no problems, and then delete the temporary branch. The code in develop is not necessarily a suitable release, it may be experimental, in the develop of a version to a relatively mature time, to merge with Master.

What if there is a bug in master? Then open a new Bugfix branch, solve the master bug, and then merge with Master and develop (develop will usually have the same bug), and then delete the temporary branch.

Before we start working, we pull the latest version from the server, then develop it, and then merge our version into the server.

Officially started to build a github warehouse

The operation of establishing a warehouse needs to be done on the website. We usually build the repository on the server (repository) and clone it locally. If you want to build the repository directly locally (init), it's usually a local single-person code base, or a library shared inside the LAN, or you're the administrator of the code server.

It's easy to set up a warehouse on GitHub, open the site, and the third right-hand corner of the top right is the button (see picture). You only need to enter the name of the project and create a ". Gitignore" file. This file is actually a file that we explicitly indicate that we do not need a version tracking, as mentioned above. This file is usually written by ourselves, but GitHub has provided a ready-made template for all of our common projects and is more convenient.

Generally there is no problem, you fill out after the "create repository" on the line, we will see this page:

This creates a success. As you can see, there is a master branch in the original library, and a commit is used as the initialization operation. You can also set up a local warehouse to view, in fact, the same. However, we usually do not build the warehouse locally, if you need to co-develop, because you can not let the server to clone the warehouse on your computer, can only be you to clone the server warehouse. Of course, if you're not going to use the server, that's a different story.

You can see the address of the three protocols above that have the project: Http,ssh, and the GIT protocol. Each of the three protocols has advantages and disadvantages, all pointing to the same project. You can also download a zip archive, or use GitHub's Windows Client for easy cloning. This client does a good job, but it can only be used on GitHub, the other code hosting platform can not be used, this is not good. We still use the msysgit+tortoisegit way, the command line familiar with the children's shoes can be considered directly on the command line. And tore it away again, and said no more.

Clone a warehouse to a local

Let's take the SSH protocol as an example. The warehouse address of SSH probably looks like this:

[email protected]: Jarelzhou/testproject.git

In the place where you want to put the local repository, right-click, git clone ...

It is said that the local warehouse is not recommended to be placed in Eclipse's workspace, for some reason. This may cause confusion among the projects.

Right after you see this interface, the URL is filled in before the SSH address provided by GitHub, Putty key Remember to select the private key we created before.

You will then be asked to enter passphrase, which is also previously set:

Created in:

Then is this warning window, this window will only appear once, later will not have, this is to check Sshkey, you can check:

If that's true, click Yes. After a little while, will come out to prompt success:

This will be turned off.

At this point the warehouse information already has the location of the original warehouse, no longer need additional settings.

Have you seen that the warehouse has been cloned? Version control of the directory will be green tick, if not, you can refresh to see, Windows icon Cache has a bug, and has not been resolved, refresh if not yet, may have to write off a bit.

Make some changes

Let's try to add a little something to this test project. For example, add a main.cpp:

When you save it, you see the directory become this way:

Found a ~ end of the archive file, should not be tracked. Right-click the file and select Ignore. After adding to the Ignore list, you can then refresh and see that the icon on the main.cpp~ file disappears.

And main.cpp This file is what we want to add to the control. Right-click tortoisegit-Add, which never tracks the status to the tracked state, and is added to the stage.

There is a saying that the. Gitignore itself should also be ignored, but it is possible that the files you add are inconsistent, so we are not ignoring them.

This time, let's commit and log to the local repository. Right-click Commit. Note that git requires that a description be entered for each commit.

Click OK to do it. All the files in the directory are now in the green tick state.

Push to server side

We have made changes locally and commit to the local library. Git does not allow direct commit to the remote library, only allows synchronization between two libraries, without commit modification, is not recorded in the warehouse. Now, let's push (push) to the server side.

Still powerful right-click ... tortoisegit put almost all of the operations into the right-click menu. Select push:

Just click OK. And then again a turtle somersault animation:

After the push is over, turn off the window.

Now let's go back to GitHub's website and refresh it to see if the file was pushed up.

In addition, the pull operation is pulling the latest repository from the server side, because the other members of the project team may have already made changes, and you need to synchronize other people's changes.

Branching operations

We now have only one branch, the more reasonable setting is two permanent branches, and then the temporary branch that appears on demand. The method of establishing the branch: Right-click, Create Branch, set the branch from which state is forked out, the default is the current state of work, you can also set to other. The switch work branch is checkout/switch.

When synchronizing, we usually synchronize each branch separately, you need to push what branch, choose which branch, do not push wrong. Pull, that's the same thing. Tortoisegit provides the option to pull/push all branches, but before you do this, you need to know what you are doing.

At last

Write here, the tortoisegit of Windows under the approximate operation is finished. As you can see, I don't really have much to describe how Tortoisegit works, I'm talking more about git design and a clearer workflow. This workflow is more than just tortoisegit, which is pretty much the same in your command-line git, and even other version control systems. Tools are not important, it is important to use tools to improve our efficiency.

Writing this article to the end, I also have the whole process of management, to git also have a deeper understanding. It's better to write it down.

Windows Git+tortoisegit Easy-to-use tutorials