也許我在想這個，但有人可以詳細說明下面的說法嗎？Git中的rebase和merge狀態如何？
違反直覺，重定位和合並是有狀態的，git可以在合併/重定位完成之前將控制權切回 。
的state簡要回顧之後，我相信這是與底墊做，合併組成的序列（順序）的步驟，其中每個步驟是一個原子的變化，因此它可以被回滾。它是否正確？有人能更好地解釋這一點，爲什麼這是違反直覺的？如果重組和合並不是有狀態的，它們會不可逆轉嗎？
最後，只有在Git中才有rebase和merge stateful嗎？
作爲original poor explainer commenter，我可以澄清我的意思。
不像許多Git命令（如檢出），它更新您的回購/索引/ WORKDIR然後控制返回給你，這是可能的GIT中在一個merge或rebase，下達控制中間退出回到用戶。 這一點特別重要，因爲它讓您有機會在繼續合併或重新綁定之前解決合併衝突。
git merge --abort
git rebase --continue | --skip | --abort | --edit-todo
如果merge失敗，git會告訴你這個消息：
自動合併失敗;修復衝突，然後提交結果。
，並在一個rebase，git會告訴你這個消息：
未能在變更合併。
在補丁（步驟）
當你已經解決了這個問題，運行 「git的變基--continue」 失敗。如果 你寧願跳過這個補丁，而是運行「git rebase --skip」。 要恢復原始分支並停止重新分配運行「git rebase --abort」。
在運行git status將列出一些文件作爲
# Unmerged paths:
# (use "git add/rm ..." as appropriate to mark resolution)
#
# both modified: YOURFILE
#
它不是特別直觀，除非你期望的git要麼完全成功，要麼立即返回控制你之前失敗兩種情況下。如果您將目錄置於合併或重新綁定的中間，忘記它，並在稍後返回時希望像平常一樣操作它，那麼您也可能會遇到麻煩。一個有用的技術是add your branch name and merge state onto your shell prompt，我發現它有助於記住我的工作目錄在任何給定時間處於哪個狀態。
很簡單，一旦您開始合併或重新綁定，它就「正在處理」。它尚未完成，您需要將其回滾或提交。你不能中間做其他主要的git命令（如提交）。
好吧，rebase（尤其是交互式rebase）故意停止並讓你做提交。但一般來說，當你處於重組或合併以及處理衝突時，你不希望開始其他的事情，是的。 – torek 2014-09-25 05:02:02
這意味着git會在.git目錄中存儲狀態信息，用於跟蹤它正在做什麼。
要查看合併類型git merge --no-commit <some branch>然後ls -l .git，您將看到文件MERGE_HEAD，MERGE_MODE和MERGE_MSG已創建。合併提交時，這些文件被刪除。
對於rebase，只需要執行如git rebase -i HEAD~1之類的操作，並將任何行從「pick」更改爲「edit」。當git給你回控制ls -l .git，你會看到有一個.git/rebase-merge目錄創建了一大堆文件，包括仍然要執行的rebase動作列表。 git rebase --abort（或者當rebase自行結束時）並且這些文件被刪除。
我不知道爲什麼說那些認爲這些操作有狀態的人是反直覺的。如果你通過rebase一次一個地提交一個提交，你必須有一個「todo」列表存儲在某個地方。如果你正在合併，你必須知道在SHA中合併的是什麼，所以你除了HEAD之外還要承諾它。
我之所以把它叫做違反直覺的只是因爲它可能對於一個新的git用戶來說並不直觀，即如果存儲庫在進程中間，如果它們返回到shell提示符下，這個用戶可能會處於這個過程中。例如，在將控制權交還給用戶之前，Subversion將交互式地要求衝突解決。 – 2014-09-25 05:57:00
「和git可以放棄控制回你」---我確定它隱含地提到了必須手動解決的合併衝突。所以它們是有狀態的，因爲並不是每一次合併/重組都可能以同樣的方式執行。 – zerkms 2014-09-25 04:41:36