git merge， rebase

git rebase --onto master 76cada^   

git checkout  master    git merge feature_branch

把其他分支76cada之后的commit都合并到master分支上。

 

 

merge会生成一个新的提交，有菱形存在，不好 。但commit id保留了

git rebase 会产生线性提交，但commit id都变了。  再进行git log --no-merges 或 git log master...mybranch 或 git log ^master mybranch时结果就不对了

矛盾

 

• git rebase 也能合并代码，例如

branch1：     1， 2，3，4

branch2：　  1，2，3

git rebase branch1 branch2

此时

First, rewinding head to replay your work on top of it...
Fast-forwarded branch2 to branch1.

branch2也会变成：1，2，3，4

• rebase后需要merge的情况：

master:  1, 2， 3

dev: 1，2，3，4

git rebase master dev

git checkout master

git merge dev

 

git checkout --ours file 和 git checkout --theirs file

 

 

https://github.com/geeeeeeeeek/git-recipes/wiki/5.1-%E4%BB%A3%E7%A0%81%E5%90%88%E5%B9%B6%EF%BC%9AMerge%E3%80%81Rebase-%E7%9A%84%E9%80%89%E6%8B%A9

 

 

将 master 分支合并到 feature 分支最简单的办法就是用下面这些命令：

git checkout feature
git merge master

或者，你也可以把它们压缩在一行里。

git merge master feature

feature 分支中新的合并提交（merge commit）将两个分支的历史连在了一起。你会得到下面这样的分支结构：

 

 

Rebase

作为 merge 的替代选择，你可以像下面这样将 feature 分支并入 master 分支：

git checkout feature    对特性分支进行rebase，对当前分支的基进行更改/rebase
git rebase master       把master作为当前分支的新的基

它会把整个 feature 分支移动到 master 分支的后面，有效地把所有 master 分支上新的提交并入过来。但是，rebase 为原分支上每一个提交创建一个新的提交，重写了项目历史，并且不会带来合并提交。

 

 

rebase最大的好处是你的项目历史会非常整洁。如上图所示，rebase 导致最后的项目历史呈现出完美的线性。

 

Rebase 的黄金法则

当你理解 rebase 是什么的时候，最重要的就是什么时候 不能 用 rebase。git rebase 的黄金法则便是，绝不要在公共的分支上使用它。

比如说，如果你把 master 分支 rebase 到你的 feature 分支上会发生什么：

 

 

 

这次 rebase 将 master 分支上的所有提交都移到了 feature 分支后面。

问题是它只发生在你的代码仓库中，其他所有的开发者还在原来的 master 上工作。因为 rebase 引起了新的提交，Git 会认为你的 master 分支和其他人的 master 已经分叉了。

同步两个 master 分支的唯一办法是把它们 merge 到一起，导致一个额外的合并提交和两堆包含同样更改的提交。不用说，这会让人非常困惑。

所以，在你运行 git rebase 之前，一定要问问你自己「有没有别人正在这个分支上工作？」。

如果答案是肯定的，那么把你的爪子放回去，重新找到一个无害的方式（如 git revert）来提交你的更改。不然的话，你可以随心所欲地重写历史。