GitHub

Git是一个修订控制系统，而GitHub（https://github.com/），是Git仓库的集中托管服务。

因为Git是一个分散的系统，所以GitHub存储了我们项目仓库的副本。通常，我们只是将GitHub仓库指定为项目的中央仓库，并且所有其他开发人员都会将更改推送到该仓库或从该仓库中提取更改。

Git merge & Git rebase

Git Merge - 拥有两个父系源，merge rebase可以保留完整的历史提交记录。

Git rebase - 线性, 单个父系源,  

      e.g  #从dev branch 加入到main branch, 然后 整合main 到dev

      (dev)#git rebase main       

      (dev)#git switch main

      (main)#git rebase dev 

Merge

Rebase

一般来说，我们在工作中的开发模式都是基于分支开发，基于主干发布的模式。什么意思呢？

就是仓库中有一份主干的代码，线上运行的就是这套代码，当我们有需求要开发的时候，不会直接在主干上开发，而是基于主干拉一个分支出来，在分支中进行开发，开发好之后，再把这个分支的代码通过发布的方式合并到主干中。

在业内有一个rebase黄金法则：不要对已经提交到共享仓库（如远程仓库）的提交执行 rebase。

为什么要遵守这个黄金法则呢？

rebase会将所有的Main分支上的提交移动到Feature分支的顶端，问题是这个操作只发生在你自己的本地仓库中，所有的其他开发者是完全不感知的，因为他们是使用旧的Main分支创建的分支。

这时候如果我们的Feature变更被推送到远程仓库后，其他人的Feature想要在提交的时候，就会产生大量的冲突。

所以，在多人协作中，应该遵循以下指导原则：

1. 在个人开发分支上进行 rebase：如果你在个人开发分支上进行 rebase，这不会对其他开发者产生影响，因为这个分支只属于你个人。

2. 在共享仓库的主分支上使用 merge：在共享仓库的主分支（如 master 或 main）上，推荐使用 merge 来将开发的功能或修复合并回主分支。这样可以保留每个开发者的提交历史，易于跟踪和回溯。

3. 协作时协商：如果有特殊情况需要在共享仓库的分支上进行 rebase，应该与其他开发者进行充分协商，并确保大家都知道并同意这个变更。