基于LTS支持分支的Git flow发布与热修复操作咨询

Great question! Git-flow works smoothly for standard active development, but LTS branches (like your 1.x line) do require some adjustments to the default workflow. Let’s walk through your questions one by one:

Can I create a release based on the LTS branch that only merges back to itself? #

Absolutely. Git-flow’s default release flow is tied to develop and master, but you can override the base branch when starting a release. Here’s how to do it:

1. Start the release branch from your LTS branch:

   git flow release start 1.2.0 1.x
   

   This creates a new release branch (release/1.2.0) based on your 1.x LTS branch, instead of the default develop.

2. Make your changes (bug fixes, minor features):
   Commit any necessary updates directly to this release branch, just like you would with a standard git-flow release.

3. Finish the release without merging to master/develop:
   By default, git flow release finish will merge the release branch to both master and develop, then tag the release. Since you only want this to apply to your LTS branch, use the -n (no merge) flag to skip the automatic merges:

   git flow release finish -n 1.2.0
   

   Then manually merge the release branch back to your 1.x branch:

   git checkout 1.x
   git merge release/1.2.0
   

   Finally, delete the release branch and tag the LTS release:

   git branch -d release/1.2.0
   git tag -a 1.2.0 -m "LTS release 1.2.0"
   

This way, your release is entirely contained within the 1.x LTS line.

Can I create a hotfix and apply it to the LTS branch? #

Yes, and you have two common approaches here depending on where the hotfix originates:

Option 1: Start the hotfix directly from the LTS branch #

If the issue is specific to the LTS line, start the hotfix branch from 1.x instead of the default master:

git flow hotfix start 1.1.1-hotfix 1.x

Fix the issue, commit your changes, then finish the hotfix with the -n flag to avoid merging to master/develop:

git flow hotfix finish -n 1.1.1-hotfix

Merge the hotfix branch back to 1.x, tag it, and clean up:

git checkout 1.x
git merge hotfix/1.1.1-hotfix
git branch -d hotfix/1.1.1-hotfix
git tag -a 1.1.1 -m "LTS hotfix 1.1.1"

Option 2: Cherry-pick a hotfix from master to LTS #

If the hotfix was first applied to the main master branch (for the latest version), you can cherry-pick the fix commits to your 1.x branch. Since you mentioned code differences, this will likely require resolving conflicts, so be sure to test thoroughly after cherry-picking:

git checkout 1.x
git cherry-pick <hotfix-commit-hash>
# Resolve conflicts if needed, then commit
git tag -a 1.1.1 -m "LTS hotfix 1.1.1 (cherry-picked from master)"

Is this the correct approach for maintaining an LTS branch? #

Yes, this adjusted git-flow workflow is a standard and recommended way to manage LTS branches. To make this process smoother, here are a few best practices:

• Document the LTS workflow: Make sure your team knows to specify the 1.x branch when starting releases/hotfixes for the LTS line, to avoid accidentally merging to master/develop.
• Keep LTS changes minimal: Stick to critical bug fixes and security patches only (you mentioned new features are rare, which is ideal for LTS). Avoid merging large features from the main development branch, as they can introduce instability or compatibility issues.
• Track cherry-picked commits: Maintain a log or annotation for cherry-picked commits so you can trace which fixes were applied to the LTS line and why.
• Test rigorously: LTS branches are meant for stability, so any release or hotfix should go through the same testing process as your main releases to ensure you don’t break existing functionality.

内容的提问来源于stack exchange，提问作者EsseTi