Collaborative development using git Branch

Original, article link: http://blog.csdn.net/u012150179/article/details/37966741

 

In large-scale software project development, the use of multiple branches can not only develop multi-module tasks in parallel, but also avoid introducing new function code During bug fixes or accidentally deleting the bug code to fix and reproduce the problem, clearer development of 'Organizational 'projects.

The new branches generally fall into the following three categories:Release Branch (bugfix Branch), feature branch, and seller branch.

I. Release Branch

The release branch is mainly used to correct bugs in the Code submitted before, so that the correction process and main line function development can be carried out in parallel.

Ii. Feature branches

Feature branches are mainly used to separate a function module from the Development Main Line, and are suitable for developing function modules with specific features such as long development cycles and experimental features.

Iii. Seller Branch

The so-called seller branch is to create a branch that is synchronized with the upstream in the version library. Once the upstream code is published, it is collected into the seller branch.

 

No matter what the branch is, its operation process is nothing moreProcedure:

1. Create a branch (1) You can use

Git branch <newbranch>

Switch to the new branch:

Git checkout newbranch

(2) or directly

Git checkout-D newbranch

 

By default, it is directed from the latest commit, that is, Head, to submit the creation of Branch. This method is generally used as a temporary branch. It accepts the changes and is finally deleted after the master branch is merge.

However, in bug modification or new module development, branch needs to be submitted from history, and the commit ID or corresponding tag must be added after the preceding statement.

 

2. Develop on the new branch

Here, you can use git rev-Parse to check whether the points of different branches are the same.

The GIT cherry command can be used to view the current submission ahead of origin.

 

After the development task on the new branch (the development task can be bug fixing or new module development) is completed, you need to merge the submission on the new branch to the master branch, in general, there are three situations:

(1) Use merge

First, create a new branch and complete the work commit. then switch to the master of the master branch and "merge" the branches created in the master branch. As follows:

Figure 1

Note that you must specify the name of the merged branch after merge.

 

(2) Use cherry-pick

Figure 6

Switch to the master branch, and then select the newbranch history submission that needs to be merged to the master branch.

This method differs from method (1) in that you can choose to merge newbranch commit instead of all merge.

 

(3) Use rebase

Change the base. By using the change base operation, the branch merging can be clearer and the review is more convenient. Operation:

Here, I made two empty commits to simulate changes to the master branch, and then switched to newbranch to execute rebase. The rebase operation here is equivalent:

I) force reset to master branch commit

Ii) extract the commit on newbranch to the reset branch.

Figure 7

After rebase, the master branch of the remote repository is updated using the newbranch branch. You can use rev-Parse to view whether the two are already submitted.

 

Others: (1) multi-user collaborative branch cooperation

When using a branch, a branch created by a user may be used by other users. For example, if a bug fix branch has many people who need to work on the branch, after the new branch is created, you need to push this branch to the remote version library so that other users can use it locally.

Figure 2

 

In addition, when other Members pull branch pull to the local machine, they cannot directly checkout this branch, but create a new branch based on this branch, such:

Figure 3

 

Now, after the modification is executed, submit and find the problem:

Figure 4

 

The problem is that you originally wanted to work with other members on the same branch, but now you have created a branch that is inconsistent with the same branch, the Branch does not exist in the remote version Library (if any, it cannot achieve the same branch collaboration goal). The solution is as follows: first, change the local branch to the name of the Cooperative Branch and then submit:

Figure 5

 

(2) backup Branch

If you need to back up the local branch, you can push the branch to the remote version library.

Git push origin <newbranch>

 

(3) Delete Branch

Directly use

Git branch-D <newbranch>

Delete. If you want to delete a remote branch that has been pushed, use the following method:

Git push origin: <newbranch>

 

Original, article link: http://blog.csdn.net/u012150179/article/details/37966741

 

Collaborative development using git Branch