preface

When managing team code with Git, there are always issues of how to manage branches and how to release versions. If a uniform set of rules can be established, the development process and efficiency of the team can be effectively guaranteed. The following process mainly refers to A design made from A successful Git Shoot model. Ensures proper use of branches and release management. In addition, the process described below does not cover Pull Request operations in order to quickly merge each developed code into the main branch. If you want to add a Pull Request process, you can add it in the functional branch merge to development branch.

process



Detailed see:

English:Introduces a successful Git branch model

English:A successful Git branching model

Main branch (long term branch)

  • Master executable version record branch, where each node is a version published online, the exact version number determined by the tag
  • Develop the code development branch

Auxiliary branch (short term branch)

  • Each feature branch should be as small as possible (preferably within one day) and moved to the warehouse as soon as possible after development
  • Release the test version releases the branch and receives the bugfix for that version until it stabilizes and then releases it to Master and merges it into Develop.
  • Hotfix emergency bug branch, directly from the master version, with the minimum version number increased by 1. Once the fix is complete, release a new version and merge it into Develop.

Release branch: Master

The executable version record branch, where each node is a version published online, the exact version number determined by the tag

Naming conventions

Master is a long-lived branch with only the name master.

commit note

  1. Branch ‘release/v1.0.1’
  2. Bump Version to V1.1.1

Github nodes do not see the tag, so they can only be identified by a commit note. The second method can clearly express the change of the published book, rather than the first git operation.

Pay attention to

Git merge –no-ff <branch-name>

  1. This will make the nodes of the branch clearer, and there will be no extraneous Commit nodes in the branch, which is especially important for the master branch.
  2. It makes it easy to review the code so that you can see exactly what changes this feature makes
  3. You only need to roll back one node interface to complete the code rollback
  4. In the event of a code conflict, Git will create a node for us, which is the same node we see in the Merge information. But if the merged code is ahead of the target branch, Git merges all the nodes into the target branch instead of creating a new node and merging. This is a disaster for the Master branch because the Release or hotfix branch is necessarily ahead of the Master branch.

Tag

operation

Each tag represents a version, which means a tag is required to merge a branch into the master.

Git tag v1.2.3 # You can omit the description of this tagGit tag -a v1.2.3 -m"This is comment" [<commit-id>]
git push origin v1.2.3
Copy the code

[Reference] Liao Xuefeng official website – create tags Liao Xuefeng official website – operate tags

Semantic version

Version format: Major version number. The second version number. The increment rule is as follows:

  1. Major version number: When you make incompatible API changes,
  2. Minor version number: When you make a backward-compatible feature addition,
  3. Revision number: When you make a backward-compatible problem fix, include fixbugs.

The prior version number and version build information can be added to the major version number. Second version number. Revision number “is followed as an extension. Tag names written above must follow this rule, and 1.2.3 in V1.2.3 corresponds to the major version number. Second version. Revision number. See semantic version 2.0.0 for more details.

Semantic version 2.0.0

Release

Every time you push a tag to Github, even if it’s not on the Master branch, Github generates a release and packs the source code. However, in order to better record the released content, we need to go to the Github release page and click the [Draft A New Release] button, or go to the [Tags] TAB page and edit the tag information to improve the version information.

Log format

The purpose of logging is to make it clear to interested parties what changes have been made between releases, so that they can better collaborate and provide services to third parties.

Here’s a template to fill in when publishing on Github:

Describe this Release: (Optionally add the following different sections of the title, if not omitted)

## Features Added
- add an new API `GET /projects/{projectId}/images` to get images [#<issue-id>] (link for the issue) @GuanrongYang
## Features Changed
- save frame annotation in the API `PUT /projects/{projectId}/images/{imageId}/annotation` when saving damage annotation @GuanrongYang
## Features Deprecated
## Features Removed
## Refactored
## Bugs Fixed
## Dependencies Added
## Dependencies Changed
## Dependencies Upgraded
Copy the code
  • Features Added: Added functions
  • Features Changed: Modified the business logic of the implemented functionality
  • Features Deprecated: Deprecated Features that will be removed in a future release
  • Removed: A feature that has been Removed
  • Refactored: Performance or structure optimized, but for changing the functional business logic
  • Bugs Fixed: Indicates that Bugs have been Fixed
  • Dependencies Added: Package to which Dependencies are Added
  • Dependencies Changed: Packages that change Dependencies, such as json instead of gson
  • Dependencies Upgrade: Version update of a dependency package

Keep a changelog release of spring-boot

Log file

Each entry in the log should include the name of the person responsible for the development, and be sure to use the github account name. Also, if each record has a corresponding issue, be sure to add the issue number in the format #

.

Changelog-unrelease. md records the content to be released this time. The content format is the same as Describe this release in Log Format. After a Release, the contents of this file will be distributed as the contents of a Release Note. Keep all headings so that developers can fill them in.

[Unreleased] :https://github.com/guanrongYang/gitflow/compare/v1.0.2... develop

## Features Added
- add an new API `GET /projects/{projectId}/images` to get images [#<issue-id>] (link for the issue) @GuanrongYang

## Features Changed

## Features Deprecated

## Features Removed

## Refactored

## Bugs Fixed

## Dependencies Added

## Dependencies Changed

## Dependencies Upgraded

Copy the code

Changelog. md If necessary, you can add a Changelog. md file to record all version logs. The file is the same as the readme. md file. The format is as follows:

# Changelog
All notable changes to this project will be documented in this file.

## [Unreleased]
### Features Added
- make download image more efficiently [# 13870] (https://github.com/spring-projects/spring-boot/pull/13870) @GuanrongYang

# # [1.0.2] - 2017-06-20
### Features Added
- New visual identity by @tylerfortune8

### Features Changed
- Start using "changelog" over "change log" since it's the common usage
- Rewrite "What makes unicorns cry?" section

### Features Removed
- Section about "changelog" vs "CHANGELOG" @Aboy @Bgirl

## [1.0.1] - 2015-12-03
### Features Added
- RU translation from @aishek
- pt-BR translation from @tallesl
- es-ES translation from @ZeliosAriex


# # [1.0.0] - 2015-06-01
### Features Added
- ini the project @GuanrongYang

[Unreleased] :https://github.com/guanrongYang/gitflow/compare/v1.0.2... develop
[1.0.2] :https://github.com/guanrongYang/gitflow/compare/v1.0.1... v1.0.2
[1.0.1] :https://github.com/guanrongYang/gitflow/compare/v1.0.0... v1.0.1
[1.0.2] :https://github.com/guanrongYang/gitflow/compare/v1.0.0... master
Copy the code

Master branch permission

To prevent the branch from being pulled or pushed, you need to set special permissions for the master. I haven’t found a way yet.

Development branch: Develop

Develop is a long-running branch, just named Develop.

Because Develop is isolated from master and release, any code can be pushed directly to the Develop branch. However, to avoid bugs, it is expected that the code incorporated into Develop is tested (either by the developers themselves or by the test engineers) and is problem-free.

The code comes from the feature, release, and Hotfix branches.

Because the Develop Branch is the newest Branch of code in the development process and is used to receive merge requests from the developer’s feature Branch (Default is pull Request to master), set the Develop Branch to Default Branch. This can be set in the Branch page in Setting of the project page. By default, the Github project page displays the Develop branch’s content and uses the Develop branch to receive Pull requests.

[Note] Git merge –no-ff For this reason, see the note in the master commit note above.

The pre-release branch: Release

Release is an auxiliary branch named in the release/vx.y.z format, where X.Y.Z indicates the version number, that is, the version of this release.

The branch is published to a real simulated online environment for testing, and if there are no problems it is published to master, otherwise it is fixbugged under the branch until it can be released unknown. If you need to fix bugs by adding a new branch based on the release branch, name the branch release/vx.y.z/< subbranchName >.

As an additional point, since bugs may be found in a release that will affect future development, it should be allowed to merge the Release branch back into Develop early, but release remains normal for testing and release, and must be merged back into Develop after merging into the Master branch.

Online emergency fix branch: Hotfix

Hotfix is a secondary branch that fixes urgent bugs on the line and is named /vx.y.z (X.Y.Z indicates the version number).

Since hotfix is a branch that fixes a version that has already been released on the master node, all versions of the hotfix branch continue the version number of the original master node. The revision number is added by 1 to the revision number of the master node.

[note]

  1. After the Hotfix branch is published to Master, be sure to incorporate the Hotfix branch into developop.
  2. If the Hotfix branch has a release branch when it releases a version to Master, merge the Hotfix branch into the Release branch instead of the Develop branch. This fix is later merged back into Develop via the Release branch.

Function development branch: Feature

Feature /#issue-featurename is an auxiliary branch of Develop that is used to develop new features or fix bugs in develop.

Unless it’s a commit problem, be sure to use a separate branch. Separate branches make it easier to switch between tasks during development, keep the Develop branch clean, and roll back errors.

instruction

The Git command

Create a repository
mkdir gitflow
cd gitflow
git init

touch README.md
#... Edit the README. Md
git add README.md
git commit -m "add README.md"

Create a long branch of develop
git checkout -b develop
The Develop branch must first be pushed to the remote repository with the feature branch
git push origin develop
Get the remote repository develop branch to the local Develop branch
# git fetch origin develop:develop

Create a branch of functionality based on Develop
git checkout -b feature/baseinfo develop
#... Develop feature/baseinfo
git push origin feature/baseinfo
Merge features /baseinfo that have been developed and passed tests into Develop
git checkout develop
git merge --no-ff feature/baseinfo

Remove feature/baseinfo from feature/baseinfo
git branch -d feature/baseinfo
Delete the functional branch of the remote repository
git push origin :feature/baseinfo

#... Continue to develop and merge other branches

# pre-releaseGit checkout -b release/v0.1.0 develop git commit"Initial version v0.1.0"
#... Fix bugs on release/v0.1.0

# Release the online versionGit checkout master Git merge --no release/v0.1.0# commit note: initial version v0.1.1Git tag v0.1.0 git push Origin master git push Origin v0.1.0Incorporate the changes made in Release into DevelopGit Checkout develop Git merge --no release/v0.1.0Delete unnecessary release branches
# delete the local release branchGit branch - d release/v0.1.0# delete the remote Release branchGit push origin: release/v0.1.0# A Bug has been found online and needs to be fixed urgently. Generally speaking, V0 is not available yetGit Checkout -b hotfix/v0.1.0 master#... Fix bugs
# Release a new version with the revision number plus 1Git checkout master Git merge --no-ff hotfix/v0.1.0# commit note: bump version to v0.1.1Git tag v0.1.1 master git push Origin v0.1.1Merge the Hotfix branch into Develop or, if there are unreleased release branches at this point, into the Release branchGit checkout /v0.1.0Delete the hotfix branchGit branch -d git push origin :hotfix/v0.1.0Copy the code

If the branch does not need to be shared with others, you can choose not to push it into a remote repository.

After the above process, we can get the following historical record line graph:

In the above operation, we released two versions 0.1.0 and 0.1.1, which can be changed in release.

Git – flow instructions

For the first time, you can read the output and use the Git branch directive to see what branches look like.

Initialize the

Create a GitFlow project

Create a Git project and create the Master and Develop branches
git flow init
The branch naming convention is the same as above
Initialized empty Git repository in /home/ygr/codes/github/gitflow2/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: [master] 
Branch name for "next release" development: [develop] 

How to name your supporting branch prefixes?
Feature branches? [feature/] 
Bugfix branches? [bugfix/] 
Release branches? [release/] 
Hotfix branches? [hotfix/] 
Support branches? [support/] 
Version tag prefix? [] 
Hooks and filters directory? [/home/ygr/codes/github/gitflow2/.git/hooks] 
Copy the code

Development capabilities

Create a branch feature/ Baseinfo based on Develop and switch to it
git flow feature start baseinfo
# ========= the above instruction is equivalent to ===========
# git checkout -b feature/baseinfo develop
# = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

#... Develop feature/baseinfo
# Feature /baseinfo development completed
git flow feature finish baseinfo
# ========= the above instruction is equivalent to ===========
# git checkout develop
# git merge --no-ff feature/baseinfo
# git branch -d feature/baseinfo
If the remote repository has feature/ baseInfo, the remote branch will be removed
# git push origin :feature/baseinfo
# = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
git push origin develop

If you need to send the feature branch to the remote repository, you can use the following command
git flow feature publish baseinfo
# ========= the above instruction is equivalent to ===========
# git checkout feature/baseinfo
# git push origin feature/baseinfo
# = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Copy the code

Release Release

# Release v0.1.0, where the version number specification remains the same as aboveGit flow release start v0.1.0# ========= the above instruction is equivalent to ===========
Git checkout -b release/v0.1.0 develop
# = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =Git flow release publish v0.1.0# ========= the above instruction is equivalent to ===========
# git checkout release/v0.1.0
Git push Origin release/v0.1.0
# = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

#... Fix all bugs

# Post onlineGit flow release Finish v0.1.0# ========= the above instruction is equivalent to ===========
# git checkout master
Git release/v0.1.0
# git tag v0.1.0
# git checkout develop
Git release/v0.1.0
Git branch -d release/v0.1.0
Git push Origin :release/v0.1.0
# = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =Git checkout Master Git push Origin master git push origin v0.1.0Copy the code

Emergency repair

Git flow hotfix start v0.1.1# = = = = = = = = = the above instruction is equivalent to the = = = = = = = = = = = # git checkout - b hotfix/v0.1.1 master# = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = git push origin Hotfix /v0.1.1git flow hotfix finish v0.1.1# ========= V0.1.1 # git branch -d hotfix/v0.1.1# git branch Push origin: hotfix/v0.1.1 # = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = git checkout mastergit push origin mastergit push origin V0.1.1 Git checkout developgit push Origin develop
Copy the code

After some operation, you can get the following effect diagram:

Comparing the two operations, we can know that using gitFlow tool is more simple and convenient, and the possibility of error is less.

Reference []

  • Gitflow is a supporting tool developed by the author of the concept of GITflow
  • Installation:Gitflow InstallationUbuntu users can go directly throughsudo apt-get install git-flowTo install
  • Git-flow cheat sheet illustrates the basic development process and common instructions of Gitflow
  • Gitflow source code for all instructions and their parameters
  • Gitflow Command Guide Basic gitflow commands and configurations
  • Gitflow Work explains Gitflow and provides some basic instructions

Matters needing attention

  1. Restrict hotfix and Develop branches to be created on the Master branch
  2. Direction of code push
    • Can be merged into master branches: hotfix, release
    • This can be incorporated into develop’s branches: feature, Release, hotfix
    • You can merge into the release branch: hotfix, the branch on hotfix itself, as inrelease/vx.y.z/<subbranchname>
    • Branches that can be merged into the feature: branches of the feature itself, such asfeature/<featurename>/<subbranchname>
    • Branches that can be merged into hotfix: branches of the hotfix itself, such ashotfix/vx.y.z/<subbranchname>

      Disallow the export of the Develop branch
  3. Do not pull/push the wrong branch. Set using Git hooks. www.jianshu.com/p/527e34f53…