我到底应该用git-merge还是git-rebase呢？( 二 )
git rebase -i HEAD~3
b. 操作指令包括：
pick：保留该commit；reword：保留该commit但是修改commit信息；edit：保留该commit但是要修改commit内容；squash：将该commit和前一个commit合并；fixup：将该commit和前一个commit合并 ， 并不保留该commit的commit信息；exec：执行shell命令；drop：删除该commit 。
在本次操作中 ， 我们将使用squash命令 ， 将第二个合并到第一个里面去 ， 修改后保存退出 ， 如下：
文章插图
在编辑器中修改 ， 将第二个的操作指令修改为squash
c. 保存退出 ， 进入编辑器 ， 对合并后的commit信息进行编辑 ， 我们将“1 --tt-darkmode-color: #A3A3A3;">rebase：会把你当前分支的 commit 放到公共分支的最后面,所以叫变基 。 就好像你从公共分支又重新拉出来这个分支一样 。
就像刚刚上面的例子: 如果你从 master 拉了个dev分支出来,然后你提交了几个 commit,这个时候刚好有人把他开发的东西合并到 master 了,这个时候 master 就比你拉分支的时候多了几个 commit,如果这个时候你 rebase master 的话 ， 就会把你当前的几个 commit ， 放到那个人 commit 的后面 。
merge：会把公共分支和你当前的commit 合并在一起 ， 形成一个新的 commit 提交 。
两者的使用场景merge命令一般用于将开发分支、热修复分支等合并到主分支上 ， 因为该命令不会修改分支的历史信息 ， 只会增加新节点 ， 非常适合主分支这种稳定性且需要用于版本控制的分支上 。
rebase命令一般用于将基分支的新提交记录 ， 合并到正在进行开发任务或修复任务的分支上 ， 因为该命令能保证开发分支的历史与基分支的历史保持一致 ， 从而减少污染性 。
但要注意 ， rebase命令最好不要用于一个公共的分支 ， 假设你们公司的开发分支是一个公用的分支 ， 此时多人在这个分支上开发 ， 由于rebase的修改历史的特点 ， 可能会出现丢失修改的问题 ， 对于这种运用 ， 建议团队之间进行沟通后决定使用merge或rebase来保证该公用开发分支的可用和完整 。
我在工作中的运用在工作中 ， 我们会拥有自己的开发分支 ， 在完成需求需要进行版本迭代的时候 ， 会将开发分支的提交合并到master上 ， 一般我的操作如下：
【我到底应该用git-merge还是git-rebase呢？】a. 通过git stash ， 将我自己开发分支的代码保存到暂存区中 ， 恢复本地仓库到修改前的状态；
b. checkout master进入主分支 ， git pull拉取master的最新commits；
c. checkout mydev进入开发分支 ， 通过git rebase master将master最新的提交 ， 合并到自己的开发分支上 ，保证该分支的历史提交与master相同；
d. git stash pop将自己的修改取出；git commit、git push提交到远程开发分支上；
e. 发起merge请求 ， 合并到master分支；
推荐阅读
- 操控都成主打卖点 手机的未来战场到底在哪？
- 点菜不应该只有扫码一种选择
- 今年过年不回家的你 应该怎样度过七天假期？
- “滑向2022”新浪杯高山滑雪公开赛，与华为WATCH GT2 Pro一起雪战到底
- 从事Java开发时发现基础差，是否应该选择辞职自学一段时间
- 一文读懂，书架箱和落地箱到底哪个好？
- Win10 真的要兼容安卓 App 了，微软到底想玩什么
- 20款游戏实战！酷睿i7-10750H、锐龙9 4900H到底谁更强？
- 手机出现“自动更新”，到底要不要更新？答案已确认
- 充电太快会爆炸吗？氮化镓到底有多火？