本文详细介绍了HelloKitty团队的Git规范，包括创建个人开发分支、commit规范、push问题处理、本地rebase解决冲突以及pull request流程，强调了分支命名、commit message和分支粒度的重要性。
完整开发流程的Git规范
1. 创建个人开发分支
1.1 明确分支对应的issues
issues在coding平台中对应【项目协同】中的需求/任务/缺陷，以下简称 issues。
建分支之前先浏览【项目协同】中有没有这个分支要解决的问题的issues：
- 如果存在并且无人认领，请将此issues的负责人标记给自己，代表认领此任务并占有此ID纳入分支名，避免分支名重复带来的拉取冲突隐患；
- 否则请创建新任务，并分配给自己作为标识，将任务ID加入分支名中。
1.2 分支名规范
-
分支名应当按顺序包含以下信息，使用符号
-连接：-
分支类型，选择
feat|fix|docs|style|refactor|test|chore|ci其一 -
个人名字缩写
-
issues【即项目协同中的需求/任务/缺陷ID】的标号。
注：如果分支对应多个issues，在pr的merge message中逐一关联即可，详见【4. pull request 规范】。分支名只需包含一个issuesID.
-
【可选】如果有必要或者你喜欢，可以追加基本信息描述；否则在pr的merge message中具体描述分支解决的问题即可，详见【4. pull request 规范】
-
-
其中前三项为必需信息，合理的分支名如：
# 功能分支，对应issues #6 feat-lzh-6 # 修复分支，对应issues#18 fix-lzh-18-hotfix-fatal-error -
错了也没关系不用remake，下次注意即可。
-
发现其他成员分支名不合规范请及时友善提醒，帮ta避免分支名重复可能带来的git冲突隐患
1.3 分支拉取指令
git checkout dev
git pull origin dev # 同步最新的远程dev分支
git checkout -b standard_branch_name origin/dev
【注意】请务必注意建立新分支前，保证本地dev分支已经同步最新的远程dev分支
- 如果忘记基于最新的dev分支拉取并且已经开发了一段时间了，按照【4. 本地rebase解决冲突】流程及时rebase就行
【说明】：
-
本项目已经将dev分支设置为default分支，默认创建分支
git branch -b new_branch及发送pr的目标分支，都是基于default分支。 -
如果想基于
非default的分支创建分支，请使用git branch -b new_branch origin/non-default_branch。建议养成这个好习惯，基于default分支创建新分支时也用origin/dev来指明拉取分支
1.4 分支粒度控制
-
【重要】请保证一个基于dev检出的分支，当pr成功并入dev分支后，此分支后就删除。
-
【禁止】在一个已经被并入dev的分支上，二次开发并发起pr。
-
请注意：当pr完成后，分支默认在远端随pr删除，本地及时同步此变动
-
【规定】：请尽量将分支的功能变动最小化，尤其是feature的新增部分，便于未来bug的定位与修复。
2. 开发中的 commit 规范
2.1 commit message规范
^(feat|fix|docs|style|refactor|test|chore|ci|pr)((.+))?: .{1,100}
以上基本采用了
Angular的commit规范，基于此增加一项pr，用于和并请求时自动为merge创建带有pr标志的commit message.
- 【必选】除
pr外的前八项功能标签，选择其一 - 【可选项】，但建议当代码变更直接使得客户端软件的界面及功能行为变化时，例如 XX功能/XX界面 来标识，方便未来测试产生bug时的回溯定位。
- 【！注意！】请注意是英文冒号，以及冒号后必须有一个空格
- 其后的信息尽量使用中文描述（其中的文件名及函数名等除外）
2.2 commit 粒度规范
-
【反对】一次commit新增从0到功能非常齐全的.vue文件
-
【尽量避免】两次commit之间仅为微小修改/无明显变化的无意义commit，如果需要对上一个commit进行追加补充但不像作为一次单独的commit在历史中留存，请按如下操作：
-
上一个commit历史在本地，未推送远端；并且，目前本地有修改，希望合并进上次commit历史，简单使用以下命令即可
git add . && git commit --amend --no-edit #这种直接把目前的修改合并到位于本地的上个commit里，不修改上个commit信息 git add . && git commit --amend -m "这里填写提交的注释" #或者这种把修改合并到位于本地的上个commit，并修改上个commit信息 # 上个commit在本地还没推送，当然也可以参照下面的rebase -i系列指令修复，就是稍微麻烦点 -
上一个commit历史已经被推送到远程，或者希望合并多个commit历史（有的commit在本地，或有的已经push远程均可适用）, 请使用
git rebase -i 系列指令实现，具体指令流程参照连接的【fixup/squash】部分操作，然后使用git push --force-with-lease进行远程push即可：https://blog.youkuaiyun.com/the_power/article/details/104651772/
【PM注：链接里很步骤很细致，有时间我再仔细补充这部分，有rebase -i的需求可以随时联系我】
-
-
【不合理】的commit粒度及其message描述：
feat: 完成xx页面包括问题：一次引入太多变动；应当将
页面较为模糊的词细化到例如UI，xx功能等具体部分 -
改进的描述：
feat(xx页面): 初始化xx页面 feat(xx页面): 完成xx页面UI feat(xx页面): xx页面实现xx，yy功能 #随功能引入的UI变动可忽略 feat(xx页面): 局部重构xx页面UI并增加zz功能 #引入zz功能导致UI较大变动时请提及
3. push 可能出现的问题
-
如果你向dev分支push失败，是正常的，所有开发者都不具有直接push到dev的权限。请注意【步骤2：创建个人开发分支】与【步骤5：pull request 规范】
-
如果你向自己的远程开发分支push失败，请检查你的commit历史，其中应该存在不符合commit信息规范格式的历史。请使用
git rebase -i 系列指令修复，具体指令流程参照连接的【reword】部分，然后使用git push --force-with-lease进行远程push即可：https://blog.youkuaiyun.com/the_power/article/details/104651772/
【注：连接里面有的地方把reword笔误成record了，不影响使用】
【PM注：链接里很步骤很细致，有时间我再仔细补充这部分，有rebase -i的需求可以随时联系我】
4. 本地rebase解决冲突
4.1 rebase时机
-
只在本地开发分支rebase，在远程合并pr请求时不使用rebase，使用merge保留更多信息。具体参照【pull request 规范】，此规范由@ljh 提出。
-
本地开发中的如下情况，都需要走一遍【4.2 rebase解决冲突流程】：
- 开发了一段时间，距离发pr还得开发个2h，准备先放下工作去吃饭的时候：发现dev更新了
- 吃完饭回来准备在自己的分支上继续开发的时候：发现dev更新了
- 要发送pr前：发现dev更新了
上述三种情况总结为：开发前、开发暂停前、发pr前，都请注意dev分支是否有更新，及时rebase并解决可能有的冲突，也利于及早熟悉队友对其他模块的变更代码
-
【告知别人】当你准备在非个人专属修改文件范围内，进行大幅度的已有内容修改或删除时，请友善地在群里提前知会队友，让他们有心理预期，并尽早结合你的说明来进行rebase
4.2 本地rebase解决冲突流程
- 开发初期检出时，dev分支处于较早的版本
git checkout standard_branch_name origin/dev
- 完成本地修改
git add .
git commit -m "[feat](XX页面): 增加xxx功能"
- 更新本地dev分支为最新版本
git checkout dev
git pull origin dev # 同步dev分支
- 将本地新建分支rebase为最新的dev分支
git checkout standard_branch_name
git rebase origin/dev # 将检出分支rebase到dev分支
# 处理冲突
## 此时会进入一个用于处理冲突的分支
git rebase --continue # 首先查看当前待解决的冲突文件
## 逐一手动合并冲突文件
git add . # 提交修改
git rebase --continue # 当所有冲突文件解决完毕后，使用此指令会进入commit message编辑
# 保存并退出commit message编辑，冲突解决完毕，回到原分支
5. pull request 规范
5.1 合并请求声明
-
任何pr都禁止在coding界面上选择squash
-
默认设置了pr合并时删除分支，没有特殊情况请不要保留。（后续有需求可以在pr界面恢复）
-
为了避免冲突，也为了分支的最小性，请及时发起pr
-
严格反对并禁止在自己负责的页面目录下使用一个分支一口气开发完所有功能页面再发pr，不要因为不会冲突就不发多个pr。
5.2 pull request 流程
-
【重要！！】：执行一遍【4.2 本地rebase解决冲突流程】
-
在coding界面创建合并请求：
- 【标题】请使用
commit message规范来描述 - 【描述】按点列出分支的各项改变
- 【关联资源】引用你的分支标题出现的issues及其他你解决了的issues
- 【标题】请使用
-
基于仓库已经预先配置了一系列规范，默认大家的分支都符合规范，自已作为管理员，点击【允许合并请求】即可
-
点击【合并请求】即可，严禁下拉选择
squash合并。由于在仓库预先配置了了禁止fast-forward推送模式，相当于禁止了github上的rebase and merge功能，默认的【合并请求】相当于【rebase and merge】模式。
具体为@ljh 在代码管理博客作业中提出的更为合理的管理模式，即：
- 本地rebase解决冲突
- 远程merge进行分支合并
好处是分支图非线性，分支图保留了完整的branch记录，多人协作开发时便于管理。同时本地使用rebase解决冲突，也不存在多余commit内容。
-
点击【合并请求】后，下方弹出一个标题和一个文本框编辑区，代表此次merge的commit message和更为详细的信息。其中要求：
-
第一行commit message，按模板自动填充为
pr: Merge Request ${id} - ${title}，自动将你的pr标题填充到此处，并在开头使用pr:来满足规范 -
下方为分支合并的详细信息，模板如下。需要你完成的部分：在
分支变更内容：下方，请将你在【创建pr】时填写的【变更描述部分】复制过来pr: Merge Request ${id} - ${title} Merge Request ${id} : (${source_branch} -> ${target_branch}) 创建者：${creator} pr链接：${url} 分支变更内容： -
其他按默认配置即可：默认勾选
删除源分支；禁止勾选Fast-Forward 模式合并。
-
-
在项目协同将你在此次pr完成的issues标记为【已完成】，并注明花费时间。
-
如果你认为此pr后有后续相关的待开发的需求，请在项目协同中创建，视情况关联此pr的ID。
-
远程已自动删除被合并的分支，本地执行以下命令同步并删除分支：
git checkout dev
git pull origin dev #远程合并完pr及时同步本地dev分支
git remote prune origin
git branch -d branch_name
扫一扫
552
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
