【Git篇 二】idea中使用git合并分支（拉取分支）_idea合并分支git

前言

本文来说下idea中使用git合并分支

idea使用git合并分支

1) 将主分支（master）更新到自己的分支（dev）

将主分支（master）更新到自己的分支（dev）

• 方法1：右下角点击分支、checkout到自己分支下、点击自己的分支、选择 remote branches 中的 origin/master 分支，点击 “Pull into dev_KC240524（当前分支） Using Merge ”。

ps：使用Rebase或Merge都可以 ; 本文中自己新的分支未改动，故使用的Rebase

• 方法2：checkout到自己分支下、点击Git/Pull、选择 origin/master 分支、点击Pull。

以上两种方法都可。

示例： ps 我使用的是dev更新到dev_KC240524
原理等同我上面所述master更新到dev

① checkout到自己分支

② 目标分支（dev）更新到当前分支（dev_KC240524）

PS：往下更新时使用Rebase; 往上合并时使用Merge

③ 当前分支出现“绿色”箭头提示（push）

• 点击push 把代码提交到自己当前分支的远程仓库

2) 将自己的分支（dev）合并到主分支（master）

将自己的分支（dev）合并到主分支（master）

• checkout到主分支（master）、先Pull一下最新的代码、点击右下角主分支、在local
  branches里选择自己的分支点击"merge selected into current"、然后记得push下、推送至远程仓库。

延申内容： Merge和Rebase的对比以及使用建议

从以下举例说明：

1. merge和rebase的提交历史差异

我们可以直观看到，经过rebase更新操作提交历史变成了一条直线形式，而经过merge更新操作远程的提交历史为非直线形式，且因为更新（而不是合并）多了一次merge记录。但是rebase也有很多缺点：

1. rebase 之后 如果有冲突 解冲突时需把每次的commit都解一遍。

2. rebase之后没有保留merge记录，意味着没有保存这步的操作，而git的意义不就是保存记录吗？

但是如果我们换一种思路考虑，我们在本地分支中使用 rebase 来更新，是为了让我们的本地提交记录更加清晰可读。（当然， rebase 不只用来合并 master 的改动，还可以在协同开发时 rebase 队友的改动）而主分支中使用 merge 来把 feature 分支的改动合并进来，是为了保留分支信息。

那么如何合适的使用rebase和merge呢？

• 假如全使用 merge 就会导致提交历史繁复交叉，错综复杂。
• 如果全使用 rebase 就会让你的commits history变成一条光秃秃的直线。

因此，一个好的commits history，应该是这样的，有合并记录且分支不交错：

*   e2e6451 (HEAD -> master) feture-c finished
|\
| * 516fc18 C.2
| * 09112f5 C.1
|/
*   c6667ab feture-a finished
|\
| * e64c4b6 A.2
| * 6058323 A.1
|/
*   2b24281 feture-b finished

1
2
3
4
5
6
7
8
9
10
11
12

而不应该是这样的，分支交错，看起来很混乱：

*   9f0c13b (HEAD -> master) feture-c finished
|\
| * 55be61c C.2
| *   e18b5c5 merge master
| |\
| |/
|/|
* |   ee549c2 feture-a finished
|\ \
| * | 51f2126 A.3
| * |   72118e2 merge master
| |\ \
| |/ /
|/| |
* | |   6cb16a0 feture-b finished
|\ \ \
| * | | 7b27b77 B.3
| * | | 3aac8a2 B.2
| * | | 2259a21 B.1
|/ / /
| * | 785fab7 A.2
| * | 2b2b664 A.1
|/ /
| * bf9e77f C.1
|/
* 188abf9 init

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

也不应该是这样的，完全呈一条直线，没有任何的合并记录：

* b8902ed (HEAD -> master) C.2
* a4d4e33 C.1
* 7e63b80 A.3
* 760224c A.2
* 84b2500 A.1
* cb4c4cb B.3
* 2ea8f0d B.2
* df97f39 B.1
* 838f514 init

1
2
3
4
5
6
7
8
9
10

2. Merge和Rebase的对比以及使用建议

我们通过上述例子得知，rebase和 merge 不是二选一的关系，要协同使用。

当开发只属于自己的分支时尽量使用rebase，减少无用的commit合到主分支里，多人合作时尽量使用merge，一方面减少冲突，另一个方面也让每个人的提交有迹可循。按照上述思路来说，我们按照如下规则可以合理使用rebase和merge操作：

1. 如果我们只注重于更新操作时，rebase操作可能会更好些，因为没必要多生成一个除了开发外的merge记录，也可以让我们的本地提交记录清晰可读。

2. 当我们要把研发分支合入到主干时，我们更注重的是合并的操作，保留合并的记录，这个时候用merge会好些。

参考文章：https://blog.csdn.net/qq_31960623/article/details/131430880