我们使用Git做代码管理时，经常会出现这种情况：项目需要稳步迭代升级（暂且叫做标品）的同时，定制化的需求接憧而至。然而定制化内容（不属于正常迭代升级的范围），我们该如何处理？下述如我想到的几种方式：

方式一：做逻辑分支
优点：代码无需单独管理，省事省力
缺点：定制内容一旦过多，对代码的整洁性会有很大的冲击

方式二：定制化项目，单独创建新的工程
优点：对标品迭代升级的项目没有任何干预和影响
缺点：定制化项目一旦需要标品最新的内容做升级，得手动同步

方式三：迭代升级使用分支管理，定制化使用fork项目方式管理
优点：对标品迭代升级的项目没有影响，且升级比较容易
缺点：fork的定制化项目依赖于标品某个时刻，如若强依赖标品的升级囫囵吞枣，选择性升级的灵活性不高

这里，我推荐的是方式三，从某些方面说，这种方式可以做到对代码最大的保护，<下述以gitlab为例>

说明

Git代码管理流程(分支、fork、tag)_Git fork

大的原则：

  • 定制化需求，使用fork<新项目>方式管理<需要强调的是，在做定制化服务前，需要明确和说明，我们只接受定制化项目合并更新标品代码，不接受标品合并更新定制化项目>
  • 标品正常迭代，使用分支方式管理
  • release版本发布后，要打相应的tag，便于回溯~

新项目处理 ​​<fork>​​

fork项目：

  • 第一步：在标品项目上进行fork操作，命名空间（namespace）选择新项目放置的空间
  • 第二步：fork完成后，进入新fork完成后的项目，在Settings -> General中分别修改
  • General project settings中的Project name为新名称
  • Archive project中的Rename repository中的path为新地址（同新名称）

更新项目：

  • 第一步：在新项目中，添加源项目（标品）地址信息 <如果已经添加，可以跳过>
# 添加标品地址
git remote add upstream git@<address>:<namespace>/<name>.git

# 查看是否添加成功
git remote -v
  • 第二步：更新项目
# 更新argus-fe项目内容
git fetch upstream

# 合并argus-fe的同步
git merge upstream/master

分支说明

master发布版本时，首先修改​​package.json​​​中version，命名方式用语义化的版本号semver进行控制，
即X.Y.Z （主版本号.次版本号.修订号）

  • 主版本号：当你做了不兼容的 API 修改，或大的功能需求
  • 次版本号：当你做了向下兼容的功能性新增
  • 修订号：当你做了向下兼容的问题修正

修改完后，运行​​npm run changelog​​，生成changelog一并提交！**补充，**关于changelog可查看：​​Git提交信息规范化​​

分支

说明

master

标本定版主分支

develop

开发稳定版本（测试，待上线）

hotfix-xx

指定bug修复版本（临时分支，处理完后可选择删除或保留）

feature-xx

功能开发分支（开发完成后可选择删除或保留）

  • master分支，只允许merge develop|hotfix分支代码
  • develop分支，只允许merge master|feature-xx分支代码
  • feature-xx分支，只允许merge develop分支代码
  • hotfix-xx分支，只允许merge master分支代码

tag说明

命令操作： 更多操作命令请查看​​Git 标签​​

# 列出所有tag
git tag -n
# 查看tag信息
git show <tag_name>

# 创建tag
git tag -a <tag_name> -m <tag_describe>
# 推送到远程
git push origin <tag_name>

# 删除tag
git tag -d <tag_name>
# 删除远程
git push origin --delete tag <tag_name>