GitLab分支版本信息处理：合并时保留父分支版本值方案咨询

一、直接解决当前合并冲突的方法 #

1. 合并时手动指定保留development版本 #

当执行合并命令触发version.cs冲突时：

• 执行git merge feat/Product-123后，若提示冲突，直接用development分支的版本覆盖：

  git checkout HEAD -- version.cs
  

• 接着执行git add version.cs和git commit完成合并，就能完全保留dev分支的版本信息。
• 也可以用git merge --no-ff feat/Product-123强制生成合并节点，在合并工具中直接选择dev分支的版本文件。

2. 修改现有脚本，避免版本变更提交到特性分支 #

当前脚本在创建特性分支时修改的version.cs属于构建临时变更，不需要提交到Git仓库：

• 把version.cs设置为Git临时忽略追踪的文件：

  git update-index --assume-unchanged version.cs
  

• 这样脚本修改version.cs后，Git不会将其识别为变更，特性分支的提交里就不会包含版本号修改，合并回dev时自然不会有冲突，dev的版本信息会被保留。
• 后续如果需要正式修改版本号并提交，执行git update-index --no-assume-unchanged version.cs取消临时忽略即可。

二、Git/GitLab版本管理的通用最佳实践 #

1. 动态生成版本号，避免硬编码 #

不要在代码库中维护固定的version.cs文件，而是在构建阶段动态生成：

• 在GitLab CI/CD流水线中，利用内置变量（如CI_COMMIT_BRANCH、CI_COMMIT_TAG、CI_COMMIT_SHORT_SHA）编写脚本，自动生成包含分支/标签/提交信息的AssemblyInformationalVersion。
• 比如dev分支构建时，版本号可以设为15.0.0.0 development-${CI_COMMIT_SHORT_SHA}；特性分支构建时设为15.0.0.0 feat-Product-123-${CI_COMMIT_SHORT_SHA}，构建完成后生成的版本信息只存在于构建产物中，不会污染代码仓库。

2. 用Git标签管理正式版本 #

• 发布正式版本时，给对应的commit打语义化标签（如v15.0.0.3），构建时读取标签作为正式版本号。
• 开发分支和特性分支的版本号自动包含分支名和提交哈希，方便区分构建产物的来源，不需要手动修改代码中的版本文件。

3. 配合分支策略自动化版本管理 #

• 遵循Git Flow或Trunk-Based Development时，版本号的生成逻辑与分支类型绑定：
  • dev分支：自动使用开发版本号+分支标识；
  • release分支：准备发布时生成正式版本号，打标签后合并回dev和主分支；
  • 特性分支：构建时自动注入分支名作为版本后缀，无需修改代码。

4. 使用专业工具简化版本管理 #

• 用GitVersion这类工具，它能根据Git历史、分支名称、标签自动计算符合语义化的版本号，自动生成对应的AssemblyInfo文件，完全替代手动或脚本修改version.cs的操作，从根源上避免版本文件的合并冲突。

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