北京个人网站建设,单页面网站,粤icp备案号查询网官网,苏州网站制作公司排名参考
【Git学习笔记】逃不掉的merge和rebase-腾讯云开发者社区-腾讯云git merge 和 git rebase - 知乎git cherry-pick 教程 - 阮一峰的网络日志
简单理解各种合并的方法
线性合并#xff0c;使用 rebase —— feature 分支开发#xff0c;提交前拉取 master 最新改动进行…参考
【Git学习笔记】逃不掉的merge和rebase-腾讯云开发者社区-腾讯云git merge 和 git rebase - 知乎git cherry-pick 教程 - 阮一峰的网络日志
简单理解各种合并的方法
线性合并使用 rebase —— feature 分支开发提交前拉取 master 最新改动进行合并保留合并历史使用 merge会产生一个新的 commit —— master 分支合并 feature挑选别的分支某几个 commit 进行合并使用 cherry-pick
git rebase 使用场景 —— 线性合并
本地 feature 分支开发完成后想要给远端 master 提交一个合并的 PR此时发现远端 master 分支已经提交了很多 feature就是本地 master 分支落后远端 master 分支多个 commit
# 1. 备份将当前分支 feature 推到远端
git push origin feature# 2. 切换到本地 master 分支并拉取远端最新 master
git checkout master
git pull origin master# 3. 切换到自己 feature 分支采用 rebase 合并不像 merge 会产生新分支
git checkout feature
git rebase master # 直接执行 esc :q 就行
# 若有冲突就进行解决之后再执行 git rebase --continue
# 合并完成后git log 会发现本地 feature 分支已合并了远端 master 分支新增的 commit
# 本地 feature 开发提交的 commit 会在远端 master 新增 commit 之后不会产生新的 commit是线形的# 4. 推送到远端覆盖
git push origin feature --force# 5. 提交 pr 到远程仓库的 master 分支# 注意
# git rebase 想要合并到哪个分支就先切换到那个分支然后执行 git rebase {另一个分支名}
# 如有两个分支 A 和 BA 想要 B 分支的新增 commit
git checkout A
git rebase B
# git log 查看历史就是 A和B 共同的 commit -- B-commit -- A-commit(HEAD)--------------- ---------------
-------| master branch |------| new commit-A |--------------- ---------------| | v --------------- ---------------
-------|featrue branch |------| commit-B |--------------- ---------------# git pull origin master
# git checkout feature
# git rebase master
# 通过 git log --graph 即可看到合并历史信息如下是个线形的但没有清楚记录从哪个分支合并的merge 可以记录--------------- --------------- ---------------
-------|featrue branch |------| new commit-A |------| commit-B |--------------- --------------- ---------------git rebase 使用场景 —— 保留合并历史
假设 AB 两个人都是基于当前 master 分支进行开发开发不同的功能但是可能会对相同文件进行改动也可能不会A 首先完成提交 pr 到 master 分支master 分支维护者进行合并这时候没有冲突直接合并但会产生一个新的 merge commit该 commit 无文件更改就是个说明这时候 B 也完成了提交 pr 到 master 分支master 分支维护者进行合并这时候可能会有冲突解决后也会产生一个新的 merge commit该 commit 可能文件更改解决冲突可以看到下面
# git checkout master
# git merge A (合并 A 分支到 master 分支)
# 生成一个 merge commit A
# git merge B (合并 B 分支到 master 分支)
# 生成一个 merge commit B
# 可以看到下面记录了 合并的历史信息 ,通过 git log --graph 即可看到合并历史信息--------------- --------------- | A branch |------| commit-A |-------- --------------- --------------- | ^ | | v --------------- --------------- ---------------
-------| master branch |-----------------------|merge-commit-A |----|merge-commit-B |--------------- --------------- ---------------| ^ v | --------------- --------------- | | B branch |-----------| commit-B |------------------------- --------------- --------------- git cherry-pick 使用场景 —— 挑选 commit 进行合并
上面 merge 和 rebase都是将所有新增的 commit 进行合并那么若只想挑选几个 commit 进行合并呢 —— cherry-pick 应运而生若 A 分支新增了几个 commit如 commit-a1、commit-a2、commit-a3、commit-a4
# 现 master 分支只想要 commit-a2
git checkout master
git cherry-pick commit-a2
git cherry-pick --continue# 现 master 分支想要 a2到a4 的commit
git checkout master
# 范围符号是两个点 ..
# 注意 首个commit一定要有 ^ 符号否则不包含 首个 commit
# 如 commit-a2..commit-a4 表示合并 commit-a3 、 commit-a4 到 master 分支
git cherry-pick commit-a2^..commit-a4
git cherry-pick --continuerebase 和 merge 的基本原则 【Git学习笔记】逃不掉的merge和rebase-腾讯云开发者社区-腾讯云 git merge 和 git rebase - 知乎 下游分支更新上游分支内容的时候使用 rebase 上游分支合并下游分支内容的时候使用 merge
在 dev 上开发了一段时间后要把 master 分支提交的新内容更新到 dev 分支此时切换到 dev 分支使用 git rebase master等 dev 分支开发完成了之后要合并到上游分支 master 上的时候切换到 master 分支使用 git merge dev。
因为自己一直用的都是merge以前完全没听过还有rebase这个命令
后来被问了一脸懵逼所以研究了一下才发现rebase好像也有点东西
git merge
先构造一下环境
git init# mater初始化提交
touch master.txt
git add .
git commit -m init master# master第一次提交
# master.txt第一行加个1
git add .
git commit -m commit 1# 拉取feature分支
git branch feature# master第二次提交
# master.txt第二行加个2
git add .
git commit -m commit 2# master第三次提交
# master.txt第三行加个3
git add .
git commit -m commit 3# 到feature分支进行提一次冲突提交
# master.txt第二行加个feature change1
git switch feature
git add .
git commit -m confict1# 进行提一次冲突提交
# master.txt第三行加个feature change2
git add .
git commit -m confict2好了这个时候准备工作就完成了
现在master要merge feature分支的更新
git switch master
git merge feature# 解决完冲突后git add .
git commit -m merged feature这是 git merge的流程
我们可以来看下此时的log
git log --graph --prettyonelinemaster上的日志分支出现了feature分支的提交
也就是说merge的流程是将分支的改动合并到当前分支后再形成一个新的commit
这只是一条分支一旦分支多了merge多了可以想象master的提交记录将会是多么可怕…
这个时候如果单纯只是为了保持master分支的纯净使其的日志以一条线性的方式存在看起来就会比较清晰。
git rebase
顾名思义 —— 变基
我的理解就是将当前所在的分支作为目标分支的新基线
还是先来跑一下新找个目录
git init# mater初始化提交
touch master.txt
git add .
git commit -m init master# master第一次提交
# master.txt第一行加个1
git add .
git commit -m commit 1# 拉取feature分支
git branch feature# master第二次提交
# master.txt第二行加个2
git add .
git commit -m commit 2# master第三次提交
# master.txt第三行加个3
git add .
git commit -m commit 3# 到feature分支进行提一次冲突提交
# master.txt第二行加个feature change1
git switch feature
git add .
git commit -m confict1# 进行提一次冲突提交
# master.txt第三行加个feature change2
git add .
git commit -m confict2这个时候用一下rebase
# 切回master分支
git switch master# 使用rebase
git rebase -i feature# 解决冲突这样rebase之后我们用相同的方式来看下master的日志 你看就是完全线性的了
rebase的过程实际就是以当git 前最新的master的版本再拉出一条分支作为当前最新的分支上原先该分支上的改动就变成现在分支上的新的commit 了
单从master的提交记录来看rebase之后的日志记录是线性的肯定是舒适很多
那么问题来了那不是都用rebase就好了吗用啥merge操作呢
使用场景是纯个人看法
1、个人开发分支管理使用rebase
比如我们现在在feature分支上开发我们新功能master正常迭代
feature开发到一半master迭代的很多了再不更新你的feature就会导致和master的偏移越来越大
这个时候获取最新的master代码merge的话刚刚看了别的分支的commit记录乱的一批全混到你的分支来了
重新拉一条分支本地的改动备份还原又不方便
看来看去rebase算是最好的选择了可以线性化个人分支的commit
版本追溯起来更清晰roll back 也更方便
2、master公共分支使用merge
这个我觉得应该没毛病公共分支上的commit历史还是不能去篡改的所以老老实实git merge --no-ff 好了
git cherry-pick
git cherry-pick 教程 - 阮一峰的网络日志
一、基本用法
git cherry-pick命令的作用就是将指定的提交commit应用于其他分支。 $ git cherry-pick commitHash上面命令就会将指定的提交commitHash应用于当前分支。这会在当前分支产生一个新的提交当然它们的哈希值会不一样。
举例来说代码仓库有master和feature两个分支。 a - b - c - d Master\e - f - g Feature现在将提交f应用到master分支。 # 切换到 master 分支
$ git checkout master# Cherry pick 操作
$ git cherry-pick f上面的操作完成以后代码库就变成了下面的样子。 a - b - c - d - f Master\e - f - g Feature从上面可以看到master分支的末尾增加了一个提交f。
git cherry-pick命令的参数不一定是提交的哈希值分支名也是可以的表示转移该分支的最新提交。 $ git cherry-pick feature上面代码表示将feature分支的最近一次提交转移到当前分支。
二、转移多个提交
Cherry pick 支持一次转移多个提交。 $ git cherry-pick HashA HashB上面的命令将 A 和 B 两个提交应用到当前分支。这会在当前分支生成两个对应的新提交。
如果想要转移一系列的连续提交可以使用下面的简便语法。 $ git cherry-pick A..B 上面的命令可以转移从 A 到 B 的所有提交。它们必须按照正确的顺序放置提交 A 必须早于提交 B否则命令将失败但不会报错。
注意使用上面的命令提交 A 将不会包含在 Cherry pick 中。如果要包含提交 A可以使用下面的语法。 $ git cherry-pick A^..B 三、配置项
git cherry-pick命令的常用配置项如下。
1-e--edit
打开外部编辑器编辑提交信息。
2-n--no-commit
只更新工作区和暂存区不产生新的提交。
3-x
在提交信息的末尾追加一行(cherry picked from commit ...)方便以后查到这个提交是如何产生的。
4-s--signoff
在提交信息的末尾追加一行操作者的签名表示是谁进行了这个操作。
5-m parent-number--mainline parent-number
如果原始提交是一个合并节点来自于两个分支的合并那么 Cherry pick 默认将失败因为它不知道应该采用哪个分支的代码变动。
-m配置项告诉 Git应该采用哪个分支的变动。它的参数parent-number是一个从1开始的整数代表原始提交的父分支编号。 $ git cherry-pick -m 1 commitHash上面命令表示Cherry pick 采用提交commitHash来自编号1的父分支的变动。
一般来说1号父分支是接受变动的分支the branch being merged into2号父分支是作为变动来源的分支the branch being merged from。
四、代码冲突
如果操作过程中发生代码冲突Cherry pick 会停下来让用户决定如何继续操作。
1--continue
用户解决代码冲突后第一步将修改的文件重新加入暂存区git add .第二步使用下面的命令让 Cherry pick 过程继续执行。 $ git cherry-pick --continue2--abort
发生代码冲突后放弃合并回到操作前的样子。
3--quit
发生代码冲突后退出 Cherry pick但是不回到操作前的样子。
五、转移到另一个代码库
Cherry pick 也支持转移另一个代码库的提交方法是先将该库加为远程仓库。 $ git remote add target git://gitUrl上面命令添加了一个远程仓库target。
然后将远程代码抓取到本地。 $ git fetch target上面命令将远程代码仓库抓取到本地。
接着检查一下要从远程仓库转移的提交获取它的哈希值。 $ git log target/master最后使用git cherry-pick命令转移提交。 $ git cherry-pick commitHash完
