个人分支一个commit点提MR时候出现多个commit点

【问题】假设你在txt_main_2分支修改提交，有一个commit点，然后push到远端，准备提交到master分支，发现有3个commit点。

【原因】之所以出现多个commit点是因为，在上一次你的txt_main_1分支同步master分支的时候，直接从mster分支merge到txt_main_1，导致这次提交的时候把有些原来主线的commit点识别成为你当前分支txt_main_1的最新提交点。

【解决方法】

在txt_main_1分支 ：

git rebase br_dev_main

git push -f

 

然后再去提MR就正常了。

 

 

 

git rebase  VS   git merge

 

 

git rebase 和 git merge是git合并分支的两种方式，然而他们却采用了不同的工作方式，以下面的一个工作场景说明其区别：

场景：

下图所示：当feature分支有新的需求提交，同时，master 分支也有修改。

这时，如果要将master 上新的提交合并到你的feature分支上，我们有两种选择：merging  or   rebasing

 

merge

执行以下命令：

git checkout feature

git merge master

或者执行：

git merge master feature

此时在feature上git 自动会产生一个新的commit(merge commit)

look like this： 

 

 

 

marge 特点：自动创建一个新的commit

当合并时遇到冲突，修改后重新commit即可

优点：将commit的实际情况进行记录，便于以后查看

缺点：由于每次merge会自动产生一个merge commit，所以在使用一些git 的GUI tools，如果commit频繁，这样会使得feature分支很杂乱，这时可以考虑使用rebase来进行合并处理。

 

rebase

本质是变基，即找公共祖先

执行以下命令：

git checkout feature

git rebase master

look like this:

 

 

 

 

rebase 特点：将commit历史进行合并

优点：项目历史比较简单，少了merge commit

缺点：当发生冲突时不容易定位问题，因为re-write了history

 

合并时如果出现冲突需要按照如下步骤解决

 

修改冲突部分

git add

git rebase --continue

（如果第三步无效可以执行 git rebase --skip）

不要在git add 之后习惯性的执行 git commit命令

 

The Golden Rule of Rebasing rebase  的黄金法则

never use it on public branches(不要在公共分支上使用)

比如说如下场景：如图所示

 

 

 

 

 

如果你rebase master 到你的feature分支：

 

rebase 将所有master的commit移动到你的feature 的顶端。问题是：其他人还在original master上开发，由于你使用了rebase移动了master，git 会认为你的主分支的历史与其他人的有分歧，会产生冲突。

 

所以在执行git rebase 之前 需要认真考虑，

 

会有其他人看这个分支么？

if YES 不要采用这种带有破坏性的修改commit 历史的rebase命令

if NO ok，随你便，可以使用rebase

 

结论：

想要干净的历史，少了merge commit的线性历史树，选择git rebase

而如果你想保留历史记录，并且想要避免重写commit history的风险，使用git merge

 

 

—