建议何时使用Git rebase与Git merge?

成功重新创建数据库后,是否仍需要合并?


当前回答

在合并/重新基础之前:

A <- B <- C    [master]
^
 \
  D <- E       [branch]

git合并主机后:

A <- B <- C
^         ^
 \         \
  D <- E <- F

git rebase master之后:

A <- B <- C <- D' <- E'

(A、B、C、D、E和F为提交)

在Git基础教程中可以找到这个例子以及更多关于Git的详细信息。

其他回答

这句话的意思是:

总的来说,实现两个世界的最佳效果的方法是重新定位本地在推送更改之前,您已进行但尚未共享的更改为了整理你的故事,但千万不要重复你推送的任何内容在某处

来源:3.6 Git分支-重新分类、重新分类与合并

在合并/重新基础之前:

A <- B <- C    [master]
^
 \
  D <- E       [branch]

git合并主机后:

A <- B <- C
^         ^
 \         \
  D <- E <- F

git rebase master之后:

A <- B <- C <- D' <- E'

(A、B、C、D、E和F为提交)

在Git基础教程中可以找到这个例子以及更多关于Git的详细信息。

我什么时候使用git rebase?几乎不会,因为它改写了历史。gitmerge几乎总是首选,因为它尊重项目中实际发生的事情。

一些与Gerrit用于审查和交付集成的大规模开发相关的实际示例:

当我将我的功能分支提升到一个新的远程主机时,我就合并了。这提供了最小的提升工作,并且很容易跟踪功能开发的历史,例如gitk。

git fetch
git checkout origin/my_feature
git merge origin/master
git commit
git push origin HEAD:refs/for/my_feature

我在准备交付提交时合并。

git fetch
git checkout origin/master
git merge --squash origin/my_feature
git commit
git push origin HEAD:refs/for/master

无论什么原因,当我的交付提交未能集成时,我都会重新启动,我需要将其更新为新的远程主机。

git fetch
git fetch <gerrit link>
git checkout FETCH_HEAD
git rebase origin/master
git push origin HEAD:refs/for/master

Pro Git的书在重新设置基础页面上有一个很好的解释。

基本上,合并将进行两次提交并合并它们。

一个重基将转到这两者的共同祖先,并在彼此之上逐步应用更改。这使得历史更加“清晰”和线性。

但当您重新创建基准时,您将放弃以前的提交并创建新的提交。因此,您永远不应该重新设置公共存储库的基础。其他在存储库中工作的人会恨你。

仅出于这个原因,我几乎完全合并了。99%的时候,我的分支机构没有太大的差异,所以如果有冲突,只会发生在一两个地方。