The last article is actually halfway through, because many operations cannot be demonstrated on the code warehouse I just created, and I have to make a bunch of branches or commits. This article first completes the operations that were not explained in the previous article.
2020-12-12
VS2019 16.8 has updated the team explorer, if you use the VS team explorer without the following Git function interface, please refer to this article VS2019 16.8 "disappeared" team explorer
Prepare
Originally, this article wanted to use the opencv warehouse as an example to demonstrate, but I cloned it and found that the speed was only tens of k. So I still want to solve the speed problem of this Github clone.
If after canceling Clone, VS has been canceling like this:
Then go to the task manager to end all Git for windows:
After the end, there will be the following prompts:
There is nothing wrong with this. It feels like VS is stuck in a deadlock. Any Git-related operation that causes VS to keep reading entries can be interrupted by this method.
Github acceleration plugin
I use this plugin:
Just search for Github acceleration in Chrome's online application. If it is not Chrome, search for the corresponding code repository at this URL: https://github.com.cnpmjs.org/search?q=opencv
After the installation is complete, an interface will be added to the Github page:
This kind belongs to mirror clone. The concept is that domestic access to Github server AWS cloud is very slow, and it regularly downloads data from Github server to a domestic server with faster access speed. The advantage is definitely fast, but there are also disadvantages. Here, there will be a time difference between the cloned warehouse and Github. For example, after you clone, someone submits a bug fix on Github, and you cannot get this submission in time at the current mirror address. The solution Also, let's first clone the Opencv warehouse, and then talk about how to solve this problem.
The download speed of this image is really very fast, about a few M per second:
Back to the above question, how to change the warehouse back to GitHub? After Clone is completed, we restore the address of the warehouse to the address of Github, and synchronize it:
Change the following two addresses to Github's Clone address:
This is the official address:
After changing, remember to synchronize once:
The content in the red box means that the synchronization is successful. At this time, your mirror warehouse has returned to the main line of Github. Note that this is synchronizing with Github, so the network speed will be very slow, but because the amount of data is much less, it is still acceptable.
Check to see if the synchronization is complete:
Git operation demonstration
View Commit History
As shown in the figure above, under the branch, you can right-click a branch and click to view the history:
Take a closer look at the history interface:
Since there are too few opencv branches, the benefits of the branch number label cannot be seen. If there are many branches developing at the same time like our company, they will eventually be merged into the main version. Here you can clearly see where the branch is submitted from coming code.
View the commit history of a file
First, under the solution explorer:
Right click on a file or folder:
Click View History to display commits related to the current file or folder:
This filter function is very useful.
Switch to a Tag
The Tag label is used by developers to release the version. When this version needs to be Released for public use, we will put a tag to record the current Commit Id. This is for the bug information that can be reported by customers after this release And find the corresponding code to debug.
At present, the latest version released by Opencv is 4.3.0, then we will switch to this version.
Switch within Tag
Find the corresponding Tag 4.3.0 under the tag:
Right click on this tag:
Checkout is generally used for branching, and I don’t think it is suitable for tags. I also reported an error when checking out here, and I still feel that 4.3.0 is just a tag and has no branches, so a null pointer error occurs when VS executes checkout.
General use to create a new local branch location:
The checkout branch here is OK, because VS first creates a branch 4.3.1 according to the tag of 4.3.0, and then checks out this branch. If this is not checked, you will still stay on the original branch after creating the branch , you need to manually switch to the branch interface by yourself.
toggle within history
The following is an operation demonstration:
First search for a commit that appears after 4.3.0. There is a green symbol 4.3.0 on the right side. This green mark is the symbol of Tag. It means that this commit corresponds to this version of 4.3.0. After finding this commit, there are two ways to switch In the past, one used reset like above:
These two options are easy to understand, that is, whether you want to keep your current modified code. After reset, reset the code to this commit on your current branch. This method is not recommended because it cannot be changed from a In the middle of the development of the branch, your submission content is likely to conflict with the submission that has not been updated later. You can check the history of the current branch and see how many submissions have not been updated locally:
This means that you currently have no updated commits:
Anything you submit in this state may conflict with the above commit. This method is suitable for cutting the code and compiling the corresponding version of the SDK without any development operations.
Another way is to create a new branch based on this commit, which is recommended:
This method is most suitable for you to fix bugs on this Tag, and then release a new fix sub-version. For example, 4.3.1.
Select Commit to the current branch
This operation is also called cherry-pick. According to the above scenario, Opencv4.3.0 was released, and the customer reported a bug, which happened to be fixed after the release. The version is out, and a large number of customers are using it, so we will only release it A small update version to fix some problems, instead of updating 4.3.0 to the latest commit of master. So this requirement is that my current branch only needs some commit content of other branches, and does not need to merge the two branches.
Suppose our current branch is my_4.3.0, and we found a commit we need on the master branch:
After finding this commit, right click on it and choose to pick:
This means that the selection is complete, and there may be conflicts:
Assuming there are no conflicts, you can see this commit in sync:
If there is a conflict, I am not good at demonstrating it here. It is probably a question of how to keep the code modified at the same time on both sides.
At this time, you can compile the current version for testing, and after confirming that the customer's bug is fixed, you can release a new version 4.3.1.
Note that this picking operation can be a commit of any branch, but it is better to be on the same branch, so that the possibility of conflicts will be less. The picked object can also be multiple commits.
Replenish
In fact, there is another important operation that has not been demonstrated, that is, PR (pull request), but I don’t know why this interface has always been like this in my place:
So I've been doing pull requests directly on GitHub as well.
In the lower right corner of VS there are several shortcut keys for Team Explorer:
The places marked above can be clicked to jump to a certain interface of the team explorer, and you can explore it yourself.
Because Github is often opened under VS like this:
So in the next article, I plan to introduce how to use Microsoft Azure for code management.
As for why Github is so difficult to access? It’s all because a group of garbage insists on making political opinions on technical websites, bah! There is no wall in the world, and there is a lot of garbage, so naturally it needs to be separated by a wall.