git 实践

git rebase

可以直接理解为改变基底。feature 分支是基于 master 分支的 B 拉出来的分支，feature 的基底是 B。而 master 在 B 之后有新的提交，就相当于此时要用 master 上新的提交来作为 feature 分支的新基底。
实际操作为把 B 之后 feature 的提交存下来，然后删掉原来这些提交，再找到 master 的最新提交位置，把存下来的提交再接上去（新节点新 commit id）
如此 feature 分支的基底就相当于变成了 M 而不是原来的 B 了。
注意，如果 master 上在 B 以后没有新提交，那么就还是用原来的 B 作为基，rebase 操作相当于无效，此时和 git merge 就基本没区别了，差异只在于 git merge 会多一条记录 Merge 操作的提交记录
大部分公司其实会禁用 rebase，不管是拉代码还是 push 代码统一都使用 merge，虽然会多出无意义的一条提交记录“Merge … to …”，但至少能清楚地知道主线上谁合了的代码以及他们合代码的时间先后顺序

简单记录工作中使用 gitflow 模型管理代码版本、保证代码安全的方法。

参考：

gitflow 现在被认为过于复杂，可能不适用于现代软件开发：

只有一条
主开发分支，基于 master 分支克隆
包含所有要发布到下一个 release 的代码
只读，只能从 feature 或 release 合并进来
feature 功能分支完成开发后，合并到 develop，合并到 develop 前，提交合并申请，与 develop 分支进行比较做代码审查，审查通过则允许合并
从 develop 拉取 release 分支，提测
release 或 hotfix 分支上线完毕，合并回 develop。

初始化项目，创建 master 分支，然后从 master 拉取 develop 分支
根据需求划分功能，从 develop 拉取 feature 分支进行编码开发，如/feature/20200712-新增用户、/feature/20200801-登陆注册
feature 分支完成后，合并到 develop 前，提交合并申请，与 develop 比较，进行代码审查，合并完成可以选择删除当前 feature
需要发布时，从 develop 拉取 release 分支进行测试，例如/release/20200712-第一版，测试过程中在该条 release 分支上修改 BUG，测试通过后将该条 release 分支发布
回归：任一 release 分支通过测试上线后，合并该 release 分支到 develop 与 master，master 分支打 tag，当前 release 不可修改，线上有问题须从 master 拉取 hotfix 分支进行修改
通知所有进行中的 feature、release 把 master 合进来一次
上线之后若发现 bug，从 master 拉取 hotfix 进行 bug 修改，如/hotfix/20200713-修复新增用户失败bug
hotfix 通过测试上线后，合并 hotfix 分支到 develop 与 master，master 分支打 tag
版本回退：如果需进行版本回退，则选择上一版本号的 release 分支进行发布

分支命名使用 YYYYMMDD-功能名称 格式，gui 工具或命令行打印时自动排序，找分支找比较方便