大型项目 feature 开发 git 流程

经历了好几个公司和开发团队，git 的使用流程依旧不清晰，这里重点是开发实战流程

开发流程

克隆远端服务器上 repo 到本地 git clone；
本地创建并切换到 feature 分支 git checkout -b my-feature；
feature 分支遵循一定的命名规则 feature/${issue-key}-${issue-summary}
例如：feature/MyProject-101-add-new-user
类似，如果是 bug 分支：fix/${issue-key}-${issue-summary}
如果是多人同时在一个 feature 上工作，可以在分支名后加上开发人员名字或者其它附加信息，但原则是保持分枝名尽量简洁
例如：feature/MyProject-101-add-new-user-alan
疯狂写代码；
确认自己所做的改动 git diff；
把改动加入到 git 的缓冲区 git add .；

commit 所有的改动 git commit -a -m；
遵循一定的规则来编写 commit 信息，例如 Angular 所使用的：

JIRA-1234 feat: support for async execution
^-------^ ^--^: ^-------------------------^| 
|       | |     |  
|       | |     +--> Summary in present tense.  
|       | +--> 改动类型: feat, fix, docs, style, refactor, perf, test or chore.  
|  
+--> Jira ticket number  
      
改动类型属于下面的一种:   
    build：表示构建，发布版本可用这个  
       ci：更新 CI/CD 等自动化配置  
    chore：杂项，其他更改  
     docs：更新文档  
     feat：常用，表示新增功能  
      fix：常用：表示修复 bug  
     perf：性能优化  
 refactor：重构  
   revert：代码回滚  
    style：样式更改  
     test：单元测试更改

把 feature 分支提交到远端服务器；
合并到开发分支之前，需要确认有没有其它开发人员的提交的改动并且和自己提交的改动没有冲突，所以本地需要切换回开发分支并且和远端服务器同步 git checkout -b develop & git pull origin develop；
切换到 feature 分支 git checkout my-feature；
根据开发分支做 rebase git rebase develop，这时如果有任何的 rebase 冲突需要手动解决；
rebase 成功后 develop 分支的改动也进入到 feature 分支，再次把 feature 分支提交到远端服务器，这次是强制/force 提交 git pull -f origin my-feature；
提交 PR（Pull Request）；
主管收到 PR 后做 code review，同意后做 squash 合并 git merge --squash，feature 分支上的改动合并到开发分支上，并且删除 feature 分支，通常合并后触发 dev build
💡：有的公司的规则是，主管同意后没有马上合并，而是触发 merge build，目的是检测 feature 分支上的改动合并到 develop 分支后是否会导致build 失败，若是，PR 失败
至此，feature 开发成功，本地切换去 develop 分支 git checkout develop，和远端服务器同步 git pull origin develop，并且删除掉 feature 分支 git branch -d my-feature；

分支策略说明

分支策略可简单，可复杂（trunk-based，git flow，github flow 等等），因为和项目管理策略，测试策略，发布策略，等等相关，如生产环境需要支持多版本，多客户。策略没有绝对好坏，原则是维护尽量少的分支。策略和执行好坏有关，如网上有人建议或膜拜 Google 的 trunk-based 策略，而忘了自己软件项目的特点。每个人都有盲区，老大也未必靠谱：

branch-comment

主分支/master 主分支 ➡ 生产环境
主分支对应生产环境，一般不允许直接在主分支上做修改
开发分支/develop 开发分支 ➡ 开发集成测试环境
开发分支用于集成测试，以及用户测试，有条件的可以细化不同的测试环境，如 release，staging
feature 分支 feature分支 ➡ feature测试环境
从开发分支上 fork 出 feature 分支：
所有的开发工作都在本地 feature 分支上进行由于是团队协作，例如 Raj 也在开发同一 feature：
发布分支/release 开发分支 ➡ 测试环境
经过一定阶段，从开发分支产生发布分支，测试成功可以 merge 回主分支：
hotfix 分支 hotfix分支 ➡ hotfix测试环境
可以考虑 hotfix 分支来修改生产环境出现的 bug：
1. 从主分支产生 hotfix 分支；
2. 开发
3. 测试（hotfix 测试环境）
4. merge 回 master 以及开发分支

hotfix 分支用来支持对多版本生产环境，但使环境和开发流程变得复杂，如果不是多版本，可以使用 feature 分支来修改 bug

Git 加强工具

changelog

> npm install -g commitizen cz-conventional-changelog

git hook

git hook 分为客户端 hook 和服务端 hook。

客户端 hook 主要有四个：

pre-commit：提交信息前运行，可检查暂存区的代码
prepare-commit-msg：不常用
commit-msg：非常重要，检查提交信息就用这个钩子
post-commit：提交完成后运行

服务端 hook 包括：

pre-receive：非常重要，推送前的各种检查都在这
post-receive：不常用
update：不常用

大多数团队是在客户端做校验，所以可以用 commit-msg 钩子在客户端对 commit 信息做校验，社区有成熟的方案：husky + commitlint。

git flow 动画视频

👍 图形化一步一步讲解 branching，merge，rebase 的区别，直至 git flow 不同的分支 master、develop、feature、release、hotfix 之间是如何切换和合作的：

https://www.youtube.com/playlist?list=PLqTmkYd8_EoJM77eZDFHAS-2Z2rxEmyOP