我到底应该用git-merge还是git-rebase呢？( 二 ) 本文一共3165字

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分支；