Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to use the Git branch in the Linux system for collaborative development. The editor thinks it is very practical, so I share it with you as a reference. I hope you can get something after reading this article.

First, the release branch is mainly used for Bug correction of previously submitted code, so that the correction process and mainline function development can be carried out in parallel.

Second, the feature branch is mainly used to separate a functional module from the development main line, which is suitable for the development of functional modules with specific characteristics, such as long development cycle, experimental functions and so on.

Third, the so-called seller branch is to create a branch synchronized with the upstream in the version library, and once the upstream code is released, it will be picked up into the vendor branch.

No matter what branch it is, the operation process is nothing more than the following steps:

1. Branches (1) can be created through git branch

Then switch to the new branch:

Git checkout newbranch

(2) or git checkout-d newbranch

The default is to create a branch from the latest commit, that is, HEAD, which is generally used as a temporary branch, accepts changes, and is eventually deleted by the master branch after merge.

However, in the case of bug modification or new module development, you need to create a branch from a historical submission, and add commit id or the corresponding tag after the above statement.

two。 Developers on new branches check here through git rev-parse to see if different branches point to the same.

The git cherry command can be used to view submissions that are currently ahead of origin.

At the end of the development task on the new branch (the development task can be bug repair or new module development), you need to merge the commits on the new branch into the main branch, which can be roughly divided into three situations:

(1) use merge to first create a new branch and complete the work commit, then switch to the main branch master, and "merge" the created branches in the main branch. As follows:

Note that after merge, you should indicate the name of the branch that will be merged.

(2) use cherry-pick

First switch to the master branch, and then pick the newbranch history submissions that need to be merged into the main branch.

The difference between this approach and method (1) is that you can optionally merge newbranch submissions instead of all merge.

(3) use rebase to change the base. The use of base-changing operation can make the merging of branches clearer and the audit more convenient. Action:

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

I) forced reset to the submission of the master branch

Ii) selects the submissions on newbranch one by one to the reset branch.

The master branch of the remote version library is also updated with the newbranch branch after rebase. Through rev-parse, you can see that both are now on the same submission.

Other: (1) Multi-user cooperation branch cooperation in the use of a branch, a new branch of a user may be used by other users, such as bug repair branch, there may be many people need to work on this branch, then after the new branch, you need to Push the branch to the remote version database, so that other users can pull to the local use.

Also, you cannot directly checkout this branch when other members branch pull it locally, but create a new branch based on it, such as:

Now submit the problem found after making the change:

The problem is that your original purpose is to work with other members on the same branch, but now you have created a branch that is inconsistent with the collaborative branch, and there is no such branch in the remote version library (if any, it cannot achieve the purpose of cooperating on the same branch). The solution is to first change the local branch to the collaborative branch name and then submit:

(2) the backup branch sometimes needs to back up the local branch, then the branch can be pushed to the remote version library.

Git push origin

(3) delete branches. For branches that are not pushed to the remote version library, use the

Git branch-d

Delete. For those that have been pushed, if you need to delete the remote branch as well, use it after the above method:

Git push origin:

This is the end of this article on "how to use Git branch collaborative development in Linux system". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it out for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.