Question

也许我过度思考这个问题，但有人可以详细说明以下陈述吗？

违反直觉，rebase和merges是有状态的，git可以放弃在合并/ rebase完成之前控制回你。

在对state进行简要回顾之后，我认为这与由连续（顺序）步骤组成的rebase和merge相关，其中每个步骤都是原子更改，因此可以回滚。它是否正确？有人可以更好地解释这一点，为什么这是违反直觉的？如果反对和合并不是有状态的，它们会不可逆转吗？

最后，仅在Git中使用rebase并合并有状态吗？

Answer 1

这意味着git将状态信息存储在.git目录中，用于跟踪它正在做什么。

要查看合并类型git merge --no-commit <some branch>然后ls -l .git，您将看到已创建文件MERGE_HEAD，MERGE_MODE和MERGE_MSG。提交合并时，将删除这些文件。

对于rebase，只需执行git rebase -i HEAD~1之类的操作，然后更改＆＃34; pick＆＃34;中的任何一行。到＆＃34;编辑＆＃34;。当git将控制权交还给你ls -l .git时，你会看到有一堆.git / rebase-merge目录，它包含了一大堆文件，包括仍然要执行的rebase动作列表。 git rebase --abort（或者当rebase自行结束时）并删除这些文件。

我不知道为什么那个说这些操作中的任何一个都处于状态的人都是反直觉的。如果你通过rebase一次一个地提交一个提交，你必须有一个＆＃39; todo＆＃39;列表存储在某处。如果你要合并，你必须知道在SHA中合并的是什么，所以除了HEAD之外你还要提交它。

Answer 2

作为original ~~poor explainer~~ commenter，我可以澄清我的意思。

与许多git命令（例如checkout）不同，后者会更新你的repo / index / workdir，然后将控制权交还给你，git可能会在 a {{{ 3}}或merge并将控制权交还给用户。 这一点非常重要，因为它可以让您在继续合并或变基之前解决合并冲突。

git merge --abort
git rebase --continue | --skip | --abort | --edit-todo

如果rebase失败，git会显示以下消息：

自动合并失败;修复冲突，然后提交结果。

在merge期间，git会向您显示此消息：

无法合并更改。

补丁在（步骤）失败

当你解决了这个问题后，运行＆＃34; git rebase --continue＆＃34;。如果   你宁愿跳过这个补丁，而是运行＆＃34; git rebase --skip＆＃34;。   要恢复原始分支并停止重新运行＆＃34; git rebase   --abort＆＃34;

在任何一种情况下，运行git status都会将某些文件列为

# Unmerged paths:
#   (use "git add/rm ..." as appropriate to mark resolution)
#
#   both modified:      YOURFILE
#

它不是特别违反直觉，除非你希望git完全成功或者在将控制权交还给你之前立即失败。如果你在合并或重新组合的中间留下一个目录，忘记它，并在以后期望按正常操作它返回它，你也会遇到麻烦。一个有用的技巧是rebase，我发现有助于记住我的工作目录在任何给定时间所处的状态。

Answer 3

非常简单，一旦你开始合并或变革，它就会在过程中进行。＆＃34;它还没有完成，你需要回滚它或提交它。你不能在中间制作其他主要的git命令（比如提交）。

如何重组和合并＆＃34;有状态＆＃34;在Git？

3 个答案: