idea中使用git合并分支
- 前言
- idea使用git合并分支
- 1) 将主分支(master)更新到自己的分支(dev)
- ① checkout到自己分支
- ② 目标分支(
dev
)更新到当前分支(dev_KC240524
) - ③ 当前分支出现“绿色”箭头提示(push)
- 2) 将自己的分支(dev)合并到主分支(master)
- 延申内容: Merge和Rebase的对比以及使用建议
- 1. merge和rebase的提交历史差异
- 2. Merge和Rebase的对比以及使用建议
前言
本文来说下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也有很多缺点:
-
rebase 之后 如果有冲突 解冲突时需把每次的commit都解一遍。
-
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
而不应该是这样的,分支交错,看起来很混乱:
* 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
也不应该是这样的,完全呈一条直线,没有任何的合并记录:
* 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
2. Merge和Rebase的对比以及使用建议
我们通过上述例子得知,rebase和 merge 不是二选一的关系,要协同使用。
当开发只属于自己的分支时尽量使用rebase,减少无用的commit合到主分支里,多人合作时尽量使用merge,一方面减少冲突,另一个方面也让每个人的提交有迹可循。按照上述思路来说,我们按照如下规则可以合理使用rebase和merge操作:
-
如果我们只注重于更新操作时,rebase操作可能会更好些,因为没必要多生成一个除了开发外的merge记录,也可以让我们的本地提交记录清晰可读。
-
当我们要把研发分支合入到主干时,我们更注重的是合并的操作,保留合并的记录,这个时候用merge会好些。
参考文章:https://blog.csdn.net/qq_31960623/article/details/131430880