[SCM] source code management-Git

From: http://roclinux.cn /? P = 2129 + http://roclinux.cn /? P = 2115

 

Reference: http://www.nvie.com/posts/a-successful-git-branching-model/

 

A description of git data migration is very clear and helpful for understanding git commands. the forwarding and sharing are here:

 

1Git is definitely a non-central distributed version control system at the technical level, but at the management level, I suggest you keep a central version library.

 

2I suggest that a central version Library (called its origin) should contain at least two branches, namely "master" and "Development Branch )"

 

3Make sure that all the members of the team obtained from the master branch are in the publishing status.CodeAnd from the Development Branch (develop) should always be able to get the latest development progress code.

 

4In a team's development collaboration, I suggest that you have the concept of "auxiliary branch.

 

5"Auxiliary branch" generally includes the following categories: branch of "management function development", branch of "helping to build codes that can be published", branch of "can easily fix key bugs of released versions", etc.

 

6The biggest feature of "auxiliary branch" is "very limited life cycle", which can be cleared after the mission is completed.

 

7I suggest setting at least three types of "secondary branches", which we call "feature branches", "release branches", and "hotfix branches ".

At this point, we have formed the following most important organizational group, including two master/develop branches and three sub-body word branches (feature/release/hotfixes ).

 

8"Feature branches" originated from the develop branch and will eventually be attributed to the develop branch.

 

9"Feature branches" is often used to develop an independent new function, and there must be only two final results. One is to merge it into the "develop" branch, and the other is to be discarded. The most typical "fearture branches" must exist in team developers rather than the "central version library.

 

10"Feature branches" originated from the "develop" branch. The implementation method is GIT checkout-B myfeature develop.

11"Feature branches" is also attributed to the "develop" branch. The implementation method is as follows:

Git checkout devleop
Git merge -- no-FF myfeature
(-- No-ff, that is, not fast forward, which requires git merge to generate a new merge commit even in the Fast Forward condition)
(Here, we need to use the -- no-FF Method for Branch merge. The purpose is to maintain the integrity of the entire commit chain of the original "feature branches)
Git branch-D myfeature
Git push origin develop

 

12"Release branch" originated from the develop branch and is ultimately attributed to the "develop" or "master" branch. We recommend that you name this type of branch "release -*"

 

13"Relase branch" is generally responsible for "preparations before short-term release", "minor bug fixing", and "Preparation of metadata such as version numbers ". At the same time, the "develop" branch can undertake the development of the next new function.

 

14The best time for "Release branch" to generate a new commit is that the "develop" branch has basically reached the expected state. At least you want the new features to be fully merged from "feature branches" to "develop" branch.

 

15Create "Release branches":

Git checkout-B release-1.2 Develop
./Bump-version.sh 1.2 (this script is used to unify all of the Code's versioning information to 1.2, and also requires the user to write the appropriate bump-version.sh based on their own project)
Git commit-a-m "Bumped version number to 1.2"

16In a short period of time, on "Release branches", we can continue to fix bugs. In this phase, the integration of new functions is strictly prohibited. New functions should be merged into the "develop" branch.

 

17After several bugs are fixed, the Code on "Release branches" has reached the publishable State. At this time, three actions need to be completed: the first is to merge "Release branches" into the "master" branch, and the second is to tag the new commit on the master (record milestone ), the third is to merge "Release branches" back to the "develop" branch.

Git checkout master
Git merge -- no-FF release-1.2
Git tag-A 1.2 (use the-U/-S/-a parameter to create a tag object, rather than a soft tag)
Git checkout develop
Git merge -- no-FF release-1.2
Git branch-D release-1.2

18"Hotfix branches" is derived from "master" and is classified as "develop" or "master". It is usually named "hotfix -*"

 

19"Hotfix branches" is similar to "release branch", but generating this branch is always an unexpected critical bug.

 

20We recommend that you set up "hotfix branches" because you want to avoid the issue where the development of new features of the "develop branch" must make way for bug fixes.

 

21Create "hotfix branches":

Git checkout-B hotfix-1.2.1 master
./Bump-version.sh 1.2.1
Git commit-a-m "bumpt version to 1.2.1" (then you can start fixing the problem)
Git commit-M "fixed severe production problem" (perform the second commit after the problem is fixed)

22After the bug is fixed, you need to merge "hotfix branches" back to the "master" branch, and also need to merge back to the "develop" branch:

Git checkout master
Git merge -- no-FF hotfix-1.2.1
Git tag-A 1.2.1
Git checkout develop
Git merge -- no-FF hotfix-1.2.1
Git branch-D hotfix-1.2.1

 

Complete!

 

From: http://roclinux.cn /? P = 2129 + http://roclinux.cn /? P = 2115

 

Reference: http://www.nvie.com/posts/a-successful-git-branching-model/

 

A description of git data migration is very clear and helpful for understanding git commands. the forwarding and sharing are here:

 

1Git is definitely a non-central distributed version control system at the technical level, but at the management level, I suggest you keep a central version library.

 

2I suggest that a central version Library (called its origin) should contain at least two branches, namely "master" and "Development Branch )"

 

3Make sure that all the code that the team members obtain from the master Branch is in the publishable status, and the code that the Development Branch should always be able to get the latest development progress.

 

4In a team's development collaboration, I suggest that you have the concept of "auxiliary branch.

 

5"Auxiliary branch" generally includes the following categories: branch of "management function development", branch of "helping to build codes that can be published", branch of "can easily fix key bugs of released versions", etc.

 

6The biggest feature of "auxiliary branch" is "very limited life cycle", which can be cleared after the mission is completed.

 

7I suggest setting at least three types of "secondary branches", which we call "feature branches", "release branches", and "hotfix branches ".

At this point, we have formed the following most important organizational group, including two master/develop branches and three sub-body word branches (feature/release/hotfixes ).

 

8"Feature branches" originated from the develop branch and will eventually be attributed to the develop branch.

 

9"Feature branches" is often used to develop an independent new function, and there must be only two final results. One is to merge it into the "develop" branch, and the other is to be discarded. The most typical "fearture branches" must exist in team developers rather than the "central version library.

 

10"Feature branches" originated from the "develop" branch. The implementation method is GIT checkout-B myfeature develop.

11"Feature branches" is also attributed to the "develop" branch. The implementation method is as follows:

Git checkout devleop
Git merge -- no-FF myfeature
(-- No-ff, that is, not fast forward, which requires git merge to generate a new merge commit even in the Fast Forward condition)
(Here, we need to use the -- no-FF Method for Branch merge. The purpose is to maintain the integrity of the entire commit chain of the original "feature branches)
Git branch-D myfeature
Git push origin develop

 

12"Release branch" originated from the develop branch and is ultimately attributed to the "develop" or "master" branch. We recommend that you name this type of branch "release -*"

 

13"Relase branch" is generally responsible for "preparations before short-term release", "minor bug fixing", and "Preparation of metadata such as version numbers ". At the same time, the "develop" branch can undertake the development of the next new function.

 

14The best time for "Release branch" to generate a new commit is that the "develop" branch has basically reached the expected state. At least you want the new features to be fully merged from "feature branches" to "develop" branch.

 

15Create "Release branches":

Git checkout-B release-1.2 Develop
./Bump-version.sh 1.2 (this script is used to unify all of the Code's versioning information to 1.2, and also requires the user to write the appropriate bump-version.sh based on their own project)
Git commit-a-m "Bumped version number to 1.2"

16In a short period of time, on "Release branches", we can continue to fix bugs. In this phase, the integration of new functions is strictly prohibited. New functions should be merged into the "develop" branch.

 

17After several bugs are fixed, the Code on "Release branches" has reached the publishable State. At this time, three actions need to be completed: the first is to merge "Release branches" into the "master" branch, and the second is to tag the new commit on the master (record milestone ), the third is to merge "Release branches" back to the "develop" branch.

Git checkout master
Git merge -- no-FF release-1.2
Git tag-A 1.2 (use the-U/-S/-a parameter to create a tag object, rather than a soft tag)
Git checkout develop
Git merge -- no-FF release-1.2
Git branch-D release-1.2

18"Hotfix branches" is derived from "master" and is classified as "develop" or "master". It is usually named "hotfix -*"

 

19"Hotfix branches" is similar to "release branch", but generating this branch is always an unexpected critical bug.

 

20We recommend that you set up "hotfix branches" because you want to avoid the issue where the development of new features of the "develop branch" must make way for bug fixes.

 

21Create "hotfix branches":

Git checkout-B hotfix-1.2.1 master
./Bump-version.sh 1.2.1
Git commit-a-m "bumpt version to 1.2.1" (then you can start fixing the problem)
Git commit-M "fixed severe production problem" (perform the second commit after the problem is fixed)

22After the bug is fixed, you need to merge "hotfix branches" back to the "master" branch, and also need to merge back to the "develop" branch:

Git checkout master
Git merge -- no-FF hotfix-1.2.1
Git tag-A 1.2.1
Git checkout develop
Git merge -- no-FF hotfix-1.2.1
Git branch-D hotfix-1.2.1

 

Complete!