团队中git多人协作最佳实践

https://mp.weixin.qq.com/s/gOH8BF_J-eBWxY3NUNlyRw

使用git rebase -i合并提交
https://blog.csdn.net/w57685321/article/details/86597808

`rebase`为变基
`git rebase -i `命令可以压缩合并多次提交
格式：`git rebase -i [startpoint] [endpoint]`

其中-i的意思是`–interactive`，即弹出交互式的界面让用户编辑完成合并操作，[startpoint] `[endpoint]`则指定了一个编辑区间，如果不指定`[endpoint]`，则该区间的终点默认是当前分支`HEAD`所指向的`commit`(注：该区间指定的是一个前开后闭的区间)。

在查看git的log后，可以使用如下命令

// 合并从当前head到15f745b(commit id)
`git rebase -i 15f745b`
或:
// 合并最近的两次提交
`git rebase -i HEAD~2`

使用git pull --rebase避免提交树上出现太多的merge操作

https://blog.csdn.net/qq_15037231/article/details/79723518

https://www.jianshu.com/p/dc367c8dca8e

rebase详解：
https://www.cnblogs.com/chenny7/p/7644318.html

执行git pull --rebase时，若出现了与本地冲突，此时HEAD会指向一个commit id来解决冲突，解决后执行git add，不要执行git commit，执行完git add后，使用命令git rebase --continue来完成rebase。

有个很成熟的叫「Git Flow」的分支模型，它能够应对 99% 的场景，剩下的那 1% 留给几乎不存在的极度变态的场景。

需要注意的是，它只是一个模型，而不是一个工具；你可以用工具去应用这个模型，也可以用最朴实的命令行。所以，重要的是理解概念，不要执着于实行的手段。

简单说来，Git Flow 就是给原本普普通通的分支赋予了不同的「职责」：

master——最为稳定功能最为完整的随时可发布的代码；

hotfix——修复线上代码的 bug；

develop——永远是功能最新最全的分支；

feature——某个功能点正在开发阶段；

release——发布定期要上线的功能。

看到上面的「master」和「develop」加粗了吧？代表它们是「主要分支」，其他的分支是基于它们派生出来的。主要分支每种类型只能有一个，派生分支每个类型可以同时存在多个。各类型分支之间的关系用一张图来体现就是：