我以为我理解git pull -rebase是如何工作的,但是这个例子让我感到困惑.我猜想以下两种情况会产生相同的结果,但它们不同.
首先,有效的.
# Dan and Brian start out at the same spot:
dan$ git rev-parse HEAD
067ab5e29670208e654c7cb00abf3de40ddcc556
brian$ git rev-parse HEAD
067ab5e29670208e654c7cb00abf3de40ddcc556
# Separately, each makes a commit (different files, no conflict)
dan$ echo 'bagels' >> favorite_foods.txt
dan$ git commit -am "Add bagels to favorite_foods.txt"
brian$ echo 'root beer' >> favorite_beverages.txt
brian$ git commit -am "I love root beer"
# Brian pushes first, then Dan runs `git pull --rebase`
brian$ git push
dan$ git pull --rebase
dan$ git …我经常发现自己在处理不同 git 分支上的两个不同工作票，但一个依赖于另一个，如下所示：
* later-branch
|
* earlier-branch
|
* some prior commit
|
（这里的每个提交都是一次提交，因为我们使用的是 gerrit，但是这个问题也可能适用于每个提交的多个提交。）较早的分支可能正在接受审查，因此我可能不得不在某个时候返回并修改它与git commit --amend. 正如必须发生的那样，这将分叉历史：
* earlier-branch
|
| * later-branch
| |
| * previous version of earlier-branch
| /
* some prior commit
|
在这一点上，我想later-branch在新版本的earlier-branch. 但是如果我只做 agit checkout later-branch后跟 a git rebase earlier-branch，它总是会发生冲突，因为（我认为）它必须首先将previous version of earlier-branch提交应用于earlier-branch.
我结束了正在做git checkout earlier-branch -b new-later-branch-name，然后git cherry-pick later-branch和git br -D later-branch …
我经常git rebase -i在发布之前清理我的历史记录。通常我想将提交编辑回当前分支分支的任何地方，而不改变其分支点。我这样做：git rebase -i $(git show-branch --merge-base $PARENT_BRANCH HEAD)
这是一个丑陋的命令，我正在努力寻找更好的方法。只要我在，我想让 git 自动找出正确的父母。
我想我想要的是 的别名git rebase -i --fork-point $(something)， wheresomething找到具有当前分支的最新共同祖先的分支。它不需要防弹。如果它适用于线性主题分支，那对我的目的来说已经足够了。
我正在努力更好地理解git-rebase背后的魔力.今天我对以下行为感到非常惊喜,我没想到.
TLDR:我重新设置了一个共享分支,导致所有提交sha1都发生了变化.尽管如此,派生分支能够准确地识别出其原始提交被"别名"为具有不同sha1的新提交.rebase并没有造成任何混乱.
拿一个主分支: M1
将它分支到branch-X,添加一些额外的提交:M1-A1-B1-C1.记下git-log输出.
将branch-X分支到branch-Y,添加了一个额外的提交:M1-A1-B1-C1-D1.记下git-log输出.
将新提交添加到主分支的提示: M1-M2
将branch-X重新引导到更新后的master : M1-M2-A2-B2-C2. 请注意,A2-B2-C2都具有与A1-B1-C1相同的消息,内容和作者日期.但是,它们具有完全不同的sha1值以及提交日期.根据这篇文章,SHA1不同的原因是因为提交的父级已经改变.
将branch-Y重新引导到更新的分支-X上.结果:M1-M2-A2-B2-C2-D2.
值得注意的是,仅应用D1提交(并且变为D2).分支-Y中的A1-B1-C1提交被git-rebase完全忽略.您可以在输出日志中看到这一点.
这很棒,但git-rebase如何知道忽略A1-B1-C1？git-rebase如何知道A2-B2-C2与A1-B1-C1相同,因此可以安全地忽略？我一直认为git使用sha1标识符跟踪提交,但是尽管上面的提交有不同的sha1s,git仍然知道它们是链接在一起的.它是如何做到的？鉴于上述行为,何时修改共享分支真的很危险？
使用git 2.11,git rebase文档说:
如果提供了--onto选项,则当前分支将重置为<upstream>或<newbase>.这与git reset --hard(或)具有完全相同的效果.ORIG_HEAD设置为在重置之前指向分支的尖端.
我理解它upstream并且newbase指向相同的"基本引用",这意味着下面的两个rebase语法是等价的:
git rebase ABC
git rebase --onto ABC
这是我设置的演示.让我们假设当前分支是FeatureABC与远程分支完全同步.
#---create two identical branches, behind current branch by 5 commits
(FeatureABC) git branch Demo1-Rebase-ABC HEAD~4
(FeatureABC) git branch Demo2-Rebase-onto-ABC HEAD~4
#---Make a new commit in branch Demo1
git checkout Demo1-Rebase-ABC
echo "Demo of: git rebase FeatureABC Demo1-Rebase-ABC" > ./Demo1_BogusFile.txt
git add ./Demo1_BogusFile.txt
git commit -m "Create file Demo1_BogusFile.txt"
git rebase FeatureABC
首先,倒带头重播你的工作
...应用:创建文件Demo1_BogusFile.txt
git log --oneline -3 …
我有一个我一直在研究的分支。git status表明它是最新的。
我检查了 master，它“落后于 43 个提交并且可以快进”。
git merge --ff-only
现在 master 是最新的，我再次检查了我的分支。git status显示它仍然是最新的。
我现在想变基来掌握：
git pull --rebase
但是我最终在一个只有我更改的文件上遇到了一系列合并冲突。我尝试修复合并冲突，但每个人git rebase --continue都提出了另一个冲突，似乎回应了我对它所做的每一个更改。
事实上，有问题的文件被重命名，我得到的合并冲突是旧文件名。在过去的几天里，我执行了多次提交，对文件进行了更新并重命名了几次。一切都在我的分公司完成。每次我进行更新时，我都会提交并将其推送到我的分支。
我不明白合并冲突的原因。该文件在我的分支中看起来是最新的。什么可能导致这种情况发生？
在 rebase 期间，我将本地功能分支同步到上游分支以完成拉取请求，我尝试使用所有三种方法（git rebase、git rebase -i 和 git merge），每种方法都提供了完全不同的体验，当它涉及解决冲突。
Git merge 一次向我展示了我所有的冲突。我解决了它们并在解决所有这些问题后添加了更改。正如预期的那样，合并弄乱了我的历史，我不得不再次恢复。
Git Rebase 分两步引导我解决冲突。在每个中，我添加了我的更改并在此之后继续 rebase。在这期间，我丢失了一个补丁，不得不重新开始。
交互式变基工作就像一个魅力。它引导我逐个提交冲突，在每次解决之后，它再次开始从功能分支的基础快速转发到下一个冲突。我可以确保提交的共同作者被正确包含，最后甚至不需要添加“合并”或“变基”提交，完成后坐在分支的头部。
我对何时使用它们中的每一个都有概念性的理解，但是为什么即使没有交互式编辑修订版，rebase 和交互式 rebase 的行为也有如此大的不同？为什么 git merge 和 git rebase 甚至使用，当它们似乎做的事情很糟糕并且更容易弄乱历史中的某些东西时？