Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

What is the method of Git branch management specification

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.

Share To

Internet Technology

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report