Git：修订旧版本并同步至master分支及版本号规划疑问

一、提交结构实现（修正你的操作步骤） #

你的期望提交结构完全可行，但原步骤存在两处关键错误，调整后的正确操作如下：

• 基于提交B创建to_publish分支：

  # 先通过git log获取B的提交哈希，若B有对应v0.x.y标签，直接用标签名即可
  git checkout -b to_publish <B的哈希值或标签名>
  

• 在to_publish分支上完成README修订，提交得到G：

  git add README.md
  git commit -m "Update README for first public release"
  

• 给to_publish分支的G提交打v1.0.0标签并推送到远程：

  git tag -a v1.0.0 -m "First public official release"
  git push origin to_publish v1.0.0
  

• 将G的修订同步到master分支：
  不要直接合并to_publish到master（会反向引入B到C的变更，导致历史混乱），改用cherry-pick单独提取G的改动：

  git checkout master
  git cherry-pick <G的提交哈希>
  

  操作完成后，master会在E的基础上新增一个与G内容一致的提交G'，既同步了README修改，又保留了master原有的C/D/E变更。
• 合并feature到master并打后续标签：

  git merge feature
  # 后续版本延续v1.x.y序列，比如合并feature后打v1.0.1
  git tag -a v1.0.1 -m "Merge feature branch, update to v1.0.1"
  git push master v1.0.1
  

二、版本号问题的解决 #

1. v1.0.0标签的合理性
   标签本质只是提交哈希的别名，不会打乱GitHub的历史记录——历史记录由提交的父子关系决定，与标签顺序无关。你完全可以给G提交打v1.0.0标签，只要在公开时明确说明：v1.0.0是项目首个公开稳定版本，此前的v0.x.y为内部私有测试版本，即可消除用户困惑。

2. 避免“v0.9.0比v1.0.0新”的尴尬
   停止使用v0.x.y版本序列，后续master上的所有新版本都延续v1.x.y编号（比如功能迭代打v1.1.0，bug修复打v1.0.2等）。若私有仓库中还有未推送的v0.x.y标签，不要推送到公开仓库；如果已经推送，在项目README的版本说明里明确标注这些旧标签为内部版本、不建议用户使用即可。

三、最终提交结构验证 #

完成上述操作后，你的提交树会与期望完全一致：

A---B---C---D---E---G'  master
     \           \  
      \           F    feature
       \
        G            to_publish (tag: v1.0.0)

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