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

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

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

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

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

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

说明

Git 分支管理流程

大的原则：

定制化需求，使用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提交信息规范化

扫描二维码关注公众号，回复： 4373390 查看本文章

分支	说明
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>