Front-end glitches – Integrate gitFlow and standard-version usage

Take a look at the previous front end tangle – contract submission and automatic changelog generation

git flowWorkflow comparison

Git Workflow Guide

Git flow is introduced

Shoot git flow from this article A -successful- Git-Shoot -model!! .

Git Flow: Git Flow, git Flow, Git Flow, Git Flow

How to use Git Flow correctly

Git-flow cheat sheet

Git — branching model as shown in figure

git flowCommon branches

How to use Git Flow blogs and gitflow-examples correctly

• develop: This branch is our main development branch, which contains all the code to be released to the next Release. This branch is mainly merged with other branches, such as the Feature branch
• release/*When you need to Release a new Release, we create a Release branch based on the Develop branch. Once the Release is complete, we merge the Master and Develop branches
• masterThis branch can only be merged from other branches and cannot be modified directly in this branch
• hotfix/*When we find a new Bug in production, we need to create a Hotfix. Once the Hotfix is done, we merge back into the Master and Develop branches, so the Hotfix changes go to the next Release
• Feature /* : This branch is used to Develop a new feature, and once it’s done, we merge back into the Develop branch for the next Release

How does Git Flow work

All commits on the Master branch should be tagged

featurebranch

Branch name feature / *

After the Feature branch is merged, you must merge it back into the Develop branch

releasebranch

Branch name release / *

The Release branch is based on the Develop branch. After the Release, you can test on the Release branch, fix bugs, and so on. In the meantime, other developers can Develop new features based on them (remember: do not merge new changes from the Develop branch to the Release branch once the Release branch is opened).

When releasing the Release branch, merge the Release to Master and Develop, Tag the Master branch to remember the Release version number, and then delete the Release branch.

Minor version Release

Major release

hotfixbranch

Branch name hotfix / *

The hotfix branch is created from the Master branch and then merged back into the Master and Develop branches with a tag attached to the Master branch

Hotfix fixes branches

supportbranch

GitFlow does not really cover the Support branch, which is essential if you need to maintain multiple major releases at the same time. You can also use the Support branch to support minor versions. If you only support major, name support/

. X and the minor version support/

.

.x

Hotfixes with multiple versions

Multiple releases

Multiple versions of Git Flow simply replace the master with a branch that needs to be maintained.

git flowTool use

You are advised to use the Sourcetree client for Windows and MAC. Git Flow is embedded in the client. For details about how to use git flow, search by yourself.

Git for Windows also includes gitflow-scripts. See git-flow-completion for details

If you are using Linux and have Gitflow-scripts built in, it would be irresponsible to recommend using the updated version of Gitflow-avh.

How to use Git Flow correctly

Above is the Git Flow menu in Sourcetree

git flowandstandard-versionCollocation is used

Be sure to integrate standard version with Git Flow based on your familiarity with git flow, because improper use of the two tools may cause conflicts.

git flowIn the processstandard-versionuse

Standard-version is used to generate changelog updates to the version field in package.json and package.lock.json. So it uses git flow-constrained flows in Git Flow. My experience so far is that it can only be used in the release/* and hotfix/* branches of Git flow. Because only these two branches are involved in the release process, changelog is generated only at release time.

git flowandstandard-versionConflicting tag functionality

Git Flow and Standard-version both have the function of automatically tagging, but both support skipping the tag phase. Therefore, this is the conflict between the two tools. You are advised to choose one of them.

The standard version automatic tag function is strongly recommended. Git Flow tag function is not recommended

usegit flowAutomatic tag must be in the tag formatstandard-versionBe able to recognize,standard-versionusegit-semver-tagsParse the tag, referenceGit-semver-tags Supported format

If the standard-version tag is missing, the generated Changelog content is repeated. The default tag prefix for standard-version is V

• Standard-version skips the tag method

  // Method 1: package.json add configuration
  {
      "standard-version": {
          "skip": {
              "tag": true}}}Copy the code

  Add parameters to the command line
  standard-version -r minor --skip.tag
  Copy the code

• Git flow skips tags

  # Skip the tag, and you can customize the Commit message(in order to make the commit message conform to the convention submission format)Git flow release Finish v0.2.0 -n-m"Chore (release) : 0.2.0." 
  Copy the code

standard-versionRun time

1. Run in the Release branch process

Git flow merges the Release /* branch to master and Develop during the Release Finish phase, so standard-version runs to generate Changelog before finish.

# 1. Simulate a release processGit flow release start v0.2.0# 2. Make some changes or commit
git commit -m 'Fix (SRC): Fix the problem'

# 3. (Optional) If you need to build changelog in beta on the Release /* branch
npx standard-version -p beta

# 4. Before release Finish
Git flow allows you to use git flow tagsNPX standard version - r v0.2.0# 5. Customize the Commit Message to conform to the contracted commit formatGit flow release Finish v0.2.0 -m"Chore (release) : 0.2.0."

Git Flow should skip tags if you use standard-version tags
# git flow release Finish v0.2.0 -n-m "chore(Release): 0.2.0"
Copy the code

2. Run in the Hotfix branch process

The Hotfix Finish phase and release phase are very much like merging the Hotfix /* branch into master and Develop, but it is a matter of discretion (with the risk of conflict) to build Changelog on the Hotfix branch.

# 1. Simulate a Hotfix processGit flow hotfix start v0.2.1# 2. Make some changes or commit
git commit -m 'Fix (SRC): Fix the problem'

# 3
Git flow allows you to use git flow tagsNPX standard version - r v0.2.1The patch version number can be replaced by patch
# npx standard-version -r patch

Customize the commit Message to conform to the contractual commit formatGit flow hotfix Finish v0.2.1 -m"Chore (release) : 0.2.1."

Git Flow should skip tags if you use standard-version tags
# git flow hotfix Finish v0.2.0 -n-m "chore(Release): 0.2.1"
Copy the code

standard-versioningit flowAttention issues at different stages of the process

1. Note in the release process of standard-version:

   • A beta version of Changelog is generated in release

     Prerequisites:

     • Release is created before hotfix
     • Changelog is generated in hotfix
     • A beta version of Changelog is generated in release

     The timing of the release branch is important; releases are created after hotfixes in git flow

     If hotfixes appear and fix after the release branch is created and hotfixes generate Changelog, release Finish after hotfix Finish will cause a conflict between release merging into Master and Develop.

     Solution:

     The Release branch contains the hotfix content (the release branch is created after the hotfix, or the hotfix is extracted into a patch and applied on the Release branch).

     • Let me know if there is a better way ~):

2. Note the following in the hotfix process:

   • Changelog is generated in hotfix

     • The release branch inhotfix finish Before establishingThe same problem occurs in the Release branch

   • The Hotfix branch does not generate Changelog

     • The Release branch is in hotfix FinishBefore establishing, can causehotfixThe repaired logs cannot appear in Changelog

   Solutions:

   The Release branch contains hotfix content (the Release branch is created after the hotfix, or the hotfix is extracted into patches and applied on the Release branch)

3. Standard-version is used without parameters

   If directly on the branch, use
   standard-version
   Copy the code

   If you run the standard-version command without specifying the parameter, the standard-version command automatically analyzes the commit message type. If the patch type is included, the patch type is added. If the feat type is included, the minor type is added. If break change is configured, the major version is automatically generated, which is risky. You are advised to specify a parameter.

advice

Tools and process models are flexible and flexible according to usage scenarios, so it is important to practice your own process model instead of just tools and process models.

reference

a-successful-git-branching-model

The original Git flow scripts are not recommended

The original git – flow – completion

Upgrade gitflow – avh

Upgrade to git – flow – completion

Contract submission specification

Git-flow cheat sheet

git-flow-standard-version

git-flow-conventional-commits

How to use Git Flow correctly

Git rebase keeps code trees clean

Centralized workflow

Functional branch workflow

Gitflow workflow

Forking workflow

comparing-workflows gitflow-examples