In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-14 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Internet Technology >
Share
Shulou(Shulou.com)06/01 Report--
This article mainly introduces "what is the method of Git branch management specification". In daily operation, I believe many people have doubts about what is the method of Git branch management specification. Xiaobian consulted various materials and sorted out simple and easy operation methods. I hope to help you answer the doubts of "what is the method of Git branch management specification"! Next, please follow the small series to learn together!
1: Branch Introduction
master: main branch, developers are not allowed to push code, only one
develop: development branch, there is only one
feature: new function branch, created on the develop branch, used to develop new functions. If there are multiple new features that can be developed in parallel, the development director can create multiple feature branches (feature branches). Naming specification:feature-branch creation date-new feature keyword, for example:feature-20200911-i18n
release: The release branch in preparation for releasing a new version. After development, create release branch (release branch), naming rule:release-branch creation date-version number to be released. For example:release-20200911-v1.0.0
hotfix: hot fix branch, used to fix bugs online, created from master branch. Naming convention:hotfix-branch creation date-version number to be released, for example:hotfix-20200911-v1.0.1
branch purpose master branch (main branch) stable version develop branch (development branch) latest version release branch (release branch) release new version hotfix branch (hot fix branch) fix online Bugfeature branch (feature branch) implement new features
II: Developing new functions
Developers implement new features on the develop branch, including: new features and Bug fixes for new features
Command example:
#Switch to develop branch: git checkout develop#Commit local changes:git add -Agit commit -m "commit log"#Push develop branch:git push origin develop 2.1 feature branch--There are multiple new features or multiple features developed in parallel
If there are multiple new features that can be developed in parallel, the development manager can create one or more feature branches (feature branches), naming conventions:feature-branch creation date-new feature keyword, for example:feature-20200911-i18n.
When a new feature is developed, the development lead merges the feature branch into the develop branch, and finally deletes the feature branch.
#Create feature branch from develop branch:git checkout -b feature-20200911-i18n develop#Merge feature branch to develop branch: git checkout develop git merge --no-ff feature#Delete local feature branch:git branch -d feature-20200911-i18n #Delete remote feature branch:git push origin :feature-20200911-i18n2.1.1 feature branch Usage scenario
Develop a standalone new feature (merged into the develop branch when complete)
Technical research and attempts (if unsuccessful, delete the feature branch at any time)
Early implementation of features that need to be developed in the next release (but not in this iteration)
Feature branches are recommended, but the lifecycle of feature branches cannot span one iteration.
III: Prepare for release of new version
Prerequisites for releasing new versions:
Verify that the functionality on the develop branch is fully developed
If development is complete, create release branch (release branch), naming rule:release-branch creation date-version number to be released, for example:release-20200911-v1.0.0
First upgrade the Maven version number in the release branch, for example:1.0.0-SNAPSHOT, then modify the version.ini file (so that you can see the current version number at deployment time), and finally make a commit on the release branch
Notification tests test release branches
#Create release branch from develop branch:git checkout -b release-20200911-v1.0.0 development 3.1 fix bugs in releases to be released
Developers fix bugs submitted to them by testers on the release branch
#Switch to release branch:git checkout release-20200911-v1.0.0#Commit local changes:git add .git commit -m "commit log"#Push release branch:git push origin release-20200911-v1.0.0IV: Release new version
Step 1: Integration Testing
The test requires the following tasks:
Check out all the code from the release branch and build the integration test environment
Arrange testers to perform integration testing on the release branch
Notify the development lead that the current version has been integrated and tested
Step 2: Smoke Test
The Development Manager is required to complete the following tasks:
Merge the release branch into both master and develop branches
Notify the test supervisor to smoke test the master branch
Step 3: Release a new version
The Development Manager is required to complete the following tasks:
Change the snapshot version of Maven on the master branch to the release version (remove SNAPSHOT suffix)
Add Release Log (RELEASE.md)
Create tags on the master branch, naming rules: tag-date-version, for example:tag-20200911-v1.0.0
Remove release branch
Pack and Upload Maven Private Server
#Merge release branch into master branch:git checkout mastergit merge --no-ff release-20200911-v1.0.0#Merge release branch into develop branch:git checkout developgit merge --no-ff release-20200911-v1.0.0#Create tag on master branch:git tag tag-20200911-v1.0.0#Delete local release branch:git branch -d release-20200911-v1.0.0#Delete remote release branch:git push origin :release-20200911-v1.0.0 Five: Online fix bug5.1 Create hotfix branch
Step 1: Create a hotfix branch The development lead completes the following tasks:
Create a hotfix branch (hotfix branch) from a tag in the master branch, naming convention:hotfix-branch creation date-version number to be released, for example:hotfix-20200911-v1.0.1
First upgrade the Maven version number in the hotfix branch (e.g.:1.0.1-SNAPSHOT), then modify the version.ini file, and finally make a commit on the hotfix branch
Guide developers through Bug fixes
Notification tests test hotfix branch
#Create a hotfix branch from a tag:git branch hotfix-20200911-v1.0.1 tag-20190919-v1.0.05.2 Create a tag and publish a new version
Bug fixes after test pass:
Merge hotfix branches into master and develop branches at the same time
Notification test, smoke test.
5.3 release a new version
Change the snapshot version of Maven on the master branch to the release version (remove SNAPSHOT suffix)
Add Release Log (RELEASE.md)
Create a label on the master branch
Remove hotfix branch
Pack and Upload Maven Private Server
#merge hotfix branch into master branch:git checkout mastergit merge --no-ff hotfix-20200911-v1.0.1#merge hotfix branch into develop branch:git checkout developgit merge --no-ff hotfix-20200911-v1.0.1#Create a label on the master branch:git checkout mastergit tag-20200911-v1.0.1#Delete local hotfix Branch:git branch -d hotfix-20200911-v1.0.1#Delete Remote hotfix Branch:git push origin :hotfix-20200911-v1.0.15.4 How do I publish if I can't merge hotfix branches into master and develop branches?
For example: Now master branch has released version 2.0.0 (code structure has changed a lot), but found a Bug in version 1.0.0 online, when the Bug is modified, it can no longer be merged into master and develop branches, the development needs to complete the following tasks:
Create tags directly on hotfix branches
Delete hotfix branch (branch deleted, as long as the label is still there, the version can be found back)
Manually modify code in the develop branch (merged into the master branch in subsequent releases)
VI: Customized projects
When a project needs to be customized, a new Git repository can be forked from the Git repository of the source project:
After fork, any changes made to repo1 will not affect repo2.
Bug fixed in repo2, submitted to repo1 via Merge Request
Submissions in repo1 can be pulled at any time in repo2, but repo1 cannot pull submissions in repo2
At this point, the study of "what is the method of Git branch management specification" is over, hoping to solve everyone's doubts. Theory and practice can better match to help everyone learn, go and try it! If you want to continue learning more relevant knowledge, please continue to pay attention to the website, Xiaobian will continue to strive to bring more practical articles for everyone!
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.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
The book recommended by the teacher when listening to acp's preaching.
© 2024 shulou.com SLNews company. All rights reserved.