[. NET object-oriented programming advanced] (26) Team development tool (v) Distributed version control system git--graphical git client Tools Tortoisegit
Pre-Read Prerequisites:
Connect to the following article:
Distributed version control system git--using Gitstack+tortoisegit graphical interface to build git environment
Http://www.cnblogs.com/yubinfeng/p/5182271.html
This article guide:
The previous article introduced a Windows environment of the GIT Server tool gitstack, set up the simplest git server under Windows, need to remind again that Gitstack is a relatively stable native version of Git, like to use the command line of the classmate, does not affect you. Gitstack simply provides a set of interface operations and an HTTP service. This article provides an in-depth look at how to use the powerful client git tool tortoisegit for branch switching, merging, and so on.
1. Create a branch
Branching in git can be said to be very convenient and practical, first of all we need to create a branch?
There is a difference between git and svn on this point. The SVN branch is generally used as an administrator to allocate a branch in advance, and developers cannot create it at will. and git you want to build it, you know what branch is the line.
Each developer in git has a better branch. You can then create the branch as a stage backup, and as a test item, do whatever it takes. Finally, you merge your experiment results into your own branch. Then, if your branch is relatively stable, commit to the trunk.
Of course, Master does not accept all or part of your branch, which is the work of master. This way of free development, is not the heart of it, continue to watch it!
Not much to say, we go straight into the topic, below to see how to create a branch.
Right-click or open the main project file in the main project folder, right-click in the blank, select Tortoisegit, select Create Branch
Enter a branch name, "Yu_v1" represents my personal first version, the following switch to the new branch if selected, after creation, the work environment will switch to the new branch, if not selected, it can be very convenient to switch
After the branch was created, we added a new file, "My fourth file. txt"
After creating a new file, we right-clicked in the blank area and found the commit default to commit to YU_V1
Enter the submission, enter a comment, select the new file four, in this window you can see the name of the branch currently being submitted
2. Switch branches
At this point, if we want to go back to the trunk, then git branch switching is very convenient
Project directory blank right click,tortoisegit=> Toggle/Checkout
In the switch window, we can easily switch to any branch, if we switch to master
We will find that the fourth file in the branch yu_v1 is gone, right-click on the blank, and you will find the switch to master.
The fourth file will not be lost, and when we switch back to branch YU_V1 again, the fourth file will return.
This is where git is powerful, where he stores a vault (stored in metadata), stores a change repository for a version and branch change, and sends a request to the server each time we switch, and the service side changes the files in our project according to our request.
The entire process is fast transmission, the server does not store each branch of the file copy, which is the GIT service side repository will not be the main reason for the explosion.
(I will be in the process, slowly put git into the principle of work)
3. View Logs
Project directory blank right click,tortoisegit=> Display log
For example, in the Open Display Log window, we can see that if a branch is created, a branch name is displayed in the log information before the change information to make it easier for us to understand which branch was changed
We build a file again, create a new branch YU_V2, submit the new file to the branch, view the log again
You can see that red indicates the current branch, and green indicates other branch change information
4. View the Version branch chart
Project directory blank Right click,tortoisegit=> View Version Branch map
In the Open Branch Chart window, you can see the history of the version branch creation process
5. Merging branches
Project directory blank right click,tortoisegit=> Merge
In the pop-up merge window, we first select a branch and merge it into the current branch (it is important to note that the merge relationship, if you want to eventually merge into that branch, first switch to that branch, then select a merge target)
Tip merge complete, is not very simple.
6. Delete Branch and branch renaming
Project directory blank right click,tortoisegit=> Toggle/Checkout
In the toggle interface, the branch selection button opens, such as the right window, to update and delete a branch, note that the current branch cannot be deleted, and if you want to delete the current branch, switch to another branch
7. Push
Project directory blank right click,tortoisegit=> push
In the push window, if you choose to push all branches, all branches in the local library are pushed to the server, and the current branch is pushed by default. We can choose to push to other branches, and commits can only be committed to the corresponding branch or new branch of the remote.
We can view our project submissions at any time in the server-side Gitstack
Open Gitstack, locate the repository "Mygitobject" We created, and click on the "Browse" button on the right, as
On the server side, we can easily view the files and branch information pushed to the servers.
8. Update the Repository
We are already familiar with the cloning of a repository from a remote server to local and local push to git, how do we get updates on other branches in a timely manner while the project is advancing, and we'll cover this later.
about updating the local library, there are two operations, if you are the Chinese version of the Tortoisegit is easy to mistake, this is the language difference.
The Chinese version is pull and get the corresponding English version for pulling (pull) and fetch (GET)
What is the difference between the two directives that are introduced here?
Pull will take the latest version from the Remote and merge (merge) to the local library
Fetch takes the latest version from the remote and does not merge (merge) to the local library
Can say pull = Fetch (FETCH) + combine (merge)
Fetch is more secure from a security point of view because we can fetch the new version first and then compare the differences and then selectively Merge. It is also recommended that you fetch to a local replica branch and then compare that replica branch to the local version, and then merge and commit to the remote host.
The Get and pull operation is simple
Project directory blank right-click,tortoisegit=> Pull
Project directory blank Right click,tortoisegit=> Get (Fetch)
9. Comparison of differences
9.1 Comparing Branch version differences
How do we see the difference between Branch 1 and branch 2? Tortoisegit provides us with a very convenient function.
Project directory blank right click,tortoisegit=> View Log
9.2 Comparing the current version of the same branch with the previous version difference
Project directory blank Right click,tortoisegit=> Compare to Previous version difference
9.3 Comparison of two file differences
Select two files in the project right-click,tortoisegit=> Compare differences
Open the File Diff diff window, as follows
You can also right-click on a file and select "With Previous version diff" To see what changes have been made to a file
10. Restore
If we regret an operation, you can use restore to revert to the state before the last commit.
Project directory blank right-click,tortoisegit=> Restore
Note: Restore can only revert to the state of the last commit, the version of the previous commit how to restore it, there is a way, as follows:
Project directory blank right click,tortoisegit=> View Log
Select a historical version, right click, click "Reset to this version" will roll back the version to the previous version.
Resolve conflicts in one-to-one git
Using Git, a non-locking version of the control system, many beginners have to resolve conflict phobia, distributed development for us to facilitate the same time, the conflict is also normal. The so-called prevention is better than relief, we can avoid, how to avoid it?
(1) First, the team in the development process needs to have a clear specification;
(2) Developers need to obtain a new version in time;
(3) After the amendment, must be submitted in time;
Even if the above three points, there will still exist conflict, conflict resolution is not scary, through the above introduction, we can see that git provides us with a number of ancillary functions, such as file differences comparison, version difference comparison. We need to make full use of these conveniences to solve problems.
There are three kinds of general conflicts: logical conflict, tree conflict, content conflict
How do these three conflicts respond?
(1) Logical conflict
Cause: For example, a method functions to return a random number from 0-5 to 1, but the colleague, without changing the method name, changed the method to return 6-9 random number 1. If you pull back to the repository that your colleague submitted, you will get a program logic error when you apply the method.
Workaround: First we use to get a copy of the support way better, to avoid this problem, if the conflict, we can obtain the version, use the recovery function, or modify the conflict before committing. Communication is very important, generally this bug is not communicated well beforehand.
(2) Tree clash
Cause: Two people modify a file name at the same time
Workaround: One of them gets the new version and then deletes the file of his changed name, and the two parties negotiate what name to use, then one of them changes, and the other gets the new version.
(3) Content conflict
Cause: Two people change the same location content of the same file at the same time
WORKAROUND: When submitting a file that creates this conflict, we use the file diff comparison to view the location of the two file content conflicts manually and then push to the server.
12. Branch Management Policy
Git has made it easier for us to create and merge branches, while the version is blooming and branching everywhere, making it easy for first-time users to find their way around the trunk. This requires us to learn about workflow, git workflow online There are many great gods, this article can not be listed. But Vincent Driessen's branch management strategy has been supported by many supporters. Let's share his results.
His strategy allows the repository to evolve with simplicity, backbone clarity, and branching.
(1) Master Branch (main branch)
First, the code base should have one, and only one main branch. All the official versions available to the user are published on this main branch. The name of the GIT Main branch, which is called Master by default. It is built automatically, and after the repository is initialized, the default is to develop in the main branch. We can tag each repository on the main branch for better management.
(2) Development Branch Develop
The main branch is used only to distribute major versions, and daily development should be done on another branch. The branch we use for development is called develop.
If you want to formally release, on the master branch, the develop branch is "merged" (merge).
(3) Temporary branch
The previous two main branches of the repository: master and develop. The former is for official release,
The latter is used to open daily
Hair In fact, the permanent branch only needs these two, it is enough, do not need the other. However, in addition to the permanent branch, there are some temporary branches that are used for some specific purposes of version development. There are three main types of temporary branches: * Function (feature) branch
* Pre-release (release) branch
* Patch Bug (fixbug) Branch
These three kinds of branches are temporary needs, after use, should be deleted, so that the code base of the permanent branch is always only master and develop.
Function Branch
The first is the functional branch, which is designed to develop a particular function that is separated from the develop branch. After the development is completed, it is to be merged into develop.
Pre-release Branch
The second is the pre-release branch, which refers to before the release of the official version (that is, before merging to the Master branch), we may need to have a pre-release version to test.
The pre-release branch is separated from the develop branch and must be merged into the develop and master branches after the pre-release is finished. Its name can be used in the form of release-*.
Patch Bug Branch
The last one is to patch the bug branch. After the official release of the software, there will inevitably be bugs. You will need to create a branch to fix the bug. The patch bug branch is separated from the master branch. After patching is complete, merge into master and develop branches. Its name can be used in the form of fixbug-*.
After the merge is complete, the patch bug branch is removed.
For the branch management policy, I recommend an article, you can refer to: http://www.cnblogs.com/cnblogsfans/p/5075073.html
13. The main points of this article
This article mainly introduces Git branch, merge, branch switch, difference comparison, conflict resolution, and so on, using Tortoisegit interface client Tools, let us in the use of the process more simple, first understand the Git workflow and use method, then slowly understand the command line, is also good. In fact, the interface of the tool each step of the nature of the command line. While writing this article, I also refer to a lot of blogs, here to express my thanks. Tortoisegit There are many features not introduced, I believe that the foundation of this article, the start is not difficult. Next I'll continue to show you how to use Git for version control in Visual Studio 2015/2013, so stay tuned.
==============================================================================================
Back to Catalog
< If it is helpful to you, please remember to click on the recommendation Oh, if there is There is no understanding or error , please exchange >
< for those who have difficulty reading this series of articles, please read the basics of. NET object-oriented programmingfirst >
< REPRINT statement: Technology needs to share the spirit, welcome to reprint the article in this blog, but please specify copyright and url>
. NET Technology Exchange Group: 467189533
==============================================================================================
[. NET object-oriented programming advanced] (26) Team development tool (v) Distributed version control system git--graphical git client Tools Tortoisegit