Git time, advanced usage of version control tools

Now you should be completely unfamiliar with git, through the previous two sections of the study, you have mastered the git a lot of common commands, such as the submission of the code of the simple operation is sure to be difficult to fail you.

Then open Git Bash and go to the root of the project Baidumaptest, and then perform the commit operation:

Git initgit Add. Git commit-m "first commit."

Now that you're done with your preparation, let's start with a high-level usage of Git.

1. Usage of branches

Branching is a relatively advanced and important concept in version control Tools , and its main purpose is to create a fork in the existing code so that the code can be used on the main and branch lines They are developed at the same time and do not affect each other . The branch works as shown in 11.16.

Figure 11.16

        you may be wondering why it is necessary to establish a branch, only on the main line of development is not very good? Yes, in general, there's no problem with developing only on the main line, but once it comes to the version, you're going to have a very bad headache if you don't set up a branch. For example, let's say your company has developed a nice piece of software that has just recently been completed and has been released in 1.0. But , , so you put into the 1.1 version of the development work. After a few weeks, the 1.1 version of the function has been completed half, but this time and user feedback, the previous online version of the 1.0 found a number of major bugs, seriously affecting the normal use of the software. The leadership also attaches great importance to this issue and requires you to fix these bugs right away. Since the 1.1 version is now half-developed, if the bug is fixed on the basis of the existing code, then the updated version 1.0 will have the feature of half the 1.1 version!

It's a dilemma, isn't it? But if you use a branch, there's no such thing as a headache at all . you only need to create a branch when you release version 1.0 , and then continue to develop the 1.1 feature on the main trunk line. When any bugs are found on version 1.0, make changes on the branch, then release the new version 1.0 and remember to merge the modified code onto the main trunk . In this way, not only can easily solve the 1.0 version of the bug, but also to ensure that the code on the main line has fixed these bugs, when the 1.1 release will not have the same bug exists.

Having said so much, I believe you have realized the importance of branching, so let's learn how to operate the branch in Git right away.

The English name of the branch is branch, and if you want to see what branches are in the current repository, you can use git branch-a This command, as shown in result 11.17.

Figure 11.17

Since no branches have been created in the Baidumaptest project at this time, only one master branch exists, which is the trunk line as previously mentioned. Next we try to create a branch with the following command:

Git branch version1.0

This creates a branch named version1.0, and we re-enter the git branch-a command to check it out, as shown in result 11.18.

Figure 11.18

As you can see, there is indeed a branch called version1.0. You will find that the Master branch has a * number in front of it, indicating that our code is still on the master branch, so how can I switch to the version1.0 branch? It is also very simple, just need to use the checkout command, as shown below:

git checkout version1.0

Enter Git branch-a again to check, as shown in result 11.19.

Figure 11.19

As you can see, we have successfully switched the code to the version1.0 branch.

It is important to note that the code that is modified and committed on the version1.0 branch will not affect the master branch. Similarly, the code that is modified and submitted on the master branch does not affect the version1.0 branch. So, if we fix a bug on the version1.0 branch, the bug still exists on the master branch. It is obviously not a smart idea to copy the modified line of code one line to the master branch, and the best way is to use the merge command to complete the merge operation, as follows:

git checkout mastergit merge version1.0

With just this simple two-line command, you can merge the content that was modified and committed on the version1.0 branch onto the master branch. Of course, there is the possibility of code conflicts when merging branches , so you need to calm down and slowly find and resolve these conflicts, and Git won't be able to help you here .

Finally, when we no longer need to version1.0 this branch, we can use the following command to remove the branch:

Git branch-d version1.0

2. Collaborating with the remote repository

It can be said that if you are a person in development, then using the version Control tool is far from being able to play its truly powerful functions. Yes, one of the most important of all version control tools is the ability to use it for team development . Each person's computer will have a code, when a member of the team on their own computer to write a feature, the code submitted to the server, the other members only need to synchronize the server's code to the local, to ensure that the entire team owner's code is the same. In this way, each team member can work together to complete a larger project.

So how do you use Git to collaborate on team development? This requires a remote repository where each member of the team gets the most original code from the repository, and then develops it separately, and each subsequent commit of the code is synchronized to the remote repository. In addition, each member of the team is best to develop the habit of getting the latest code from the repository frequently, otherwise the code is likely to conflict frequently.

For example, now that you have a remote repository with a Git address of https://github.com/example/test.git, you can download the code locally using the following command:

git clone https://github.com/example/test.git

After you have made some modifications and submissions based on this code, how can you synchronize locally modified content to the remote repository? This needs to be done with the push command, as shown here:

Git push Origin Master

Where the Origin section specifies the Git address of the remote repository , theMaster section specifies which branch to synchronize to , The above command completes the ability to synchronize the local code to the master branch of the Https://github.com/example/test.git repository.

Now that you know how to synchronize local changes to the remote repository, let's look at How to synchronize the changes on the remote repository locally . Git provides two two gates to do this, namely fetch and pull, and fetch syntax rules and push are similar, as follows:

Git fetch Origin Master

After executing this command, the code on the remote repository is synchronized to local, but the synchronized code is not merged into any branch, but instead is stored on a origin/master branch where we can see exactly what was modified on the remote repository via the diff command:

git diff origin/master

Then call the merge command to merge the modifications on the Origin/master branch onto the main branch, as follows:

git merge Origin/master

The pull command, which is equivalent to executing both the fetch and merge commands , can fetch the latest code from the remote repository and merge it locally, using the following example:

Git pull Origin Master

Perhaps you are now using the remote version of the library will feel more abstract, it's OK, because for the moment we just understand the use of the command, has not been practiced, you will have a deeper understanding of the usage of the remote repository.

Excerpt from the first line of code

Git time, advanced usage of version control tools