git 远程分支合并

转载：【IntelliJ IDEA】在idea上操作 git分支合并【如何将远程swagger分支 合并到 远程 master分支上】【如何切换 本地分支】 - Angel挤一挤 - 博客园

明确一点：

如果项目交给git管理了【如何将项目交给git管理：https://www.cnblogs.com/sxdcgaq8080/p/8058898.html】

1.若文件显示红色，表示文件未add到git进行管理

2.若文件显示绿色，表示文件已经交给git管理，但从未上传到远程仓库中

3.若文件显示蓝色，表示文件已经上传过远程仓库，且此时本地文件与远程仓库文件不一致

4.若文件显示白色，表示文件与远程仓库完全一致

============================================

目标：

将如何将【远程swagger分支 】合并到  【远程 master分支】上

大概流程

1.首先将 【本地swagger分支】上的更改 PUSH到 【 远程的 swagger分支】上

2.再切换当前分支，将【本地swagger分支】切换到【本地master分支】上

3.将【远程swagger分支】Merge合并到【本地master分支】上

4.在【本地master分支】分支上测试无误，将【本地master分支】PUSH到【远程mester分支】上

============================================

 1.查看当前 本地分支是【本地swagger分支】，本地做修改，并将本地修改提交【远程swagger分支】

从上图可以看出  ，【本地swagger分支】做了修改以后，提交的时候会提交到【远程swagger分支】上。

实际测试一下，修改本地文件

 接下来，就要提交本地修改到远程了【注意，提交到远程分支的代码一定是测试无误才可以提交，否则对于联合开发会有很恶心的影响】

注意点击按钮是 【commit and push】

点击Push  即可

2. 将【本地swagger分支】切换为【本地master分支】

切换本地分支的做法

点击Rebase

点击也可以看出来 当前分支已经切换为  本地master分支

3.将【远程swagger分支】的修改文件 Merge到【本地master分支】上

 

4.将【本地master分支】代码 Push到【远程master分支】上

最后一步，将代码在master分支上测试 无误，将本地master分支上的代码 Push到 远程master分支上

步骤同  第一步 将【本地swagger分支】上的代码 push到【远程swagger分支】上一个道理。

但是有一个情况 就是我将第三步合并到本地master分支的代码直接push到远程master分支上时，显示我 并没有任何更改。【这个问题没有找到原因】

5，Merge 合并分支

merge 这种方式应该是大家最熟悉的。merge 会创建一个新的合并提交，将两个分支的历史记录保留在一起。

它的好处是日志保留完整，不管你之前有多少提交历史，都会完整地合并到目标分支。

来看看代码示例：

git checkout maingit pull origin maingit merge dev# 解决冲突后git commit -m "Merge dev into main"git push origin main

使用 merge 的好处是非常直观，历史记录完整，看得清楚每次合并和每个提交。

但缺点也是显而易见的，提交历史会显得比较混乱，尤其是在一个团队项目中，各种合并提交一大堆，看着就头疼。

6，Rebase 合并分支

再来说说 rebase。rebase 会将分支上的更改重新应用在目标分支上，重写提交历史。它最大的特点就是提交历史变得线性，看起来非常干净。

来看一下代码示例：

git checkout devgit pull origin devgit rebase main# 解决冲突后git rebase --continuegit push origin dev --force

rebase 之后，你的提交历史看起来就像一条直线，清清爽爽，没有 merge 的那些冗余提交。

但使用 rebase 也有风险，比如说在 rebase 过程中需要处理很多冲突，操作不当还容易搞出大问题。

合并压缩

在 rebase 的时候，我们还可以用 squash 参数来压缩提交记录。

假设你在一个 feature 分支上有多个提交，可以通过 squash 将它们合并成一个提交记录。这样做的好处是进一步简化提交历史。

具体操作如下：

git checkout devgit rebase -i HEAD~3# 进入编辑模式后，将 `pick` 改为 `squash`# 保存并关闭编辑器，编辑新的提交信息并保存git push origin dev --force

什么时候用 merge，什么时候用 rebase？

到底该用哪种方式呢？这要看具体的场景和你的团队习惯。

使用 merge 的场景：

• 希望保留完整的提交历史

• 适用于多人合作的项目，保留每个人的工作记录

使用 rebase 的场景：

• 希望保持提交历史的简洁和线性

• 适用于希望干净历史的项目

有些公司规定只能用 rebase，因为它更适合单一版本的项目，比如说只有一个主分支一直向前推进。
而对于那些需要维护多个版本的项目，用 rebase 就不太合适了，因为每次 rebase 都会重写提交历史，这在多个分支并行的情况下容易造成混乱。

举个例子，我之前参与过一个 Vue 项目，就是用 rebase 来合并分支的。这个项目只有一个主分支，所有的开发都在这个分支上进行，用 rebase 可以保持提交历史的干净整洁。