Git 如何修复基于提交修正的分支，该修正导致；“正在重设基准”吗；？

我对git比较陌生，所以请详细介绍。如果我做错了什么，请指出

问题是这样的：

我从远程下载，它只有一个分支，master

我向主人作出了承诺

在重新设置主控形状的基础上，我将更改推送到新获取的源/主控形状上（但更改尚未合并到远程控制中）

我从master创建了一个名为bug1的新分支，并做了一些更改

在抓取后重新定位到origin/master后，我推送了bug1（此更改尚未合并到remote）

我从大师那里得到了一个分支，叫做bug2

我在master上修改了我最近的提交（提供了对bug2有用的必要信息）

我签出了bug2，并做了

git rebase master

，希望在master中所做的所有更改现在都能反映在bug2中

通过观察，我相信我的目标确实实现了，关于master的工作现在处于bug2阶段

奇怪的是，当我做git状态时，我会得到：

rebase正在进行中；安装到ec578ba上
您当前正在重新设置“ec578ba”上的分支“bug2”的基址。
（修复冲突，然后运行“git-rebase--continue”）
（使用“git-rebase--skip”跳过此修补程序）
（使用“git rebase--abort”签出原始分支）
未合并路径：
（使用“git重置磁头…”取消分级）
（使用“git add…”标记分辨率）
两个都修改了：c.py
两个修改：f.py
两者均已修改：s.py
未为提交而暂存的更改：
（使用“git add…”更新将提交的内容）
（使用“git签出--…”放弃工作目录中的更改）
修改：t.py
修改：co.txt
修改：h.py
未跟踪的文件：
（使用“git add…”包含在将提交的内容中）
blablaa.pyc
未向提交添加任何更改（使用“git add”和/或“git commit-a”）

此外，git branch-a还显示：

*（无分支，重定基bug2）
bug1
bug2
主人
遥控器/原点/磁头->原点/主控
遥控器/源/主

我真的不知道我做错了什么。。。我以为这一切都会从我在网上学到的东西中得到解决，但显然我需要做一些“合并”来解决这个问题

有人能帮忙吗？

---

非常感谢你！这似乎是一个太具体的问题，太谷歌了，我甚至不知道我认为正确的术语。

< P>你真的处在一个重新基础的中间，就像<代码> Git状态< /代码>说。（如果你的Git版本是2.0或更高版本，

Git status

非常好而且可靠；1.7和1.8版本中有一些重大改进，因此如果你有一个真正古老的

Git status

，你应该仍然使用它，但它不如现代Git好。）

陷入合并的原因是，

git commit--amend

是一个善意的谎言：它实际上并没有改变现有的提交。相反，它生成了一个新的和改进的提交，然后说：让我们使用这个而不是旧的提交。不幸的是，任何已经拥有并依赖于旧分支的分支仍然拥有旧分支

让我们详细介绍一下：

我从远程下载，它只有一个分支，master

我假设你是说你跑了：

git clone <url>
cd <new-clone>

大写字母代表真正的哈希ID。名称

branch

，保存上次提交

H

的哈希ID

H

本身保存先前提交的哈希ID

G

，该提交保存的哈希ID为

F

，依此类推。这允许Git在一系列提交中向后走

要创建新分支，只需选择一些现有的提交并为其附加一个名称：

...--F--G   <-- newbranch
         \
          H   <-- master

表示当前名称为

newbranch

（当前提交为

H

）

请记住，我们注意到提交中的文件一直处于冻结状态。它们都是只读的。它们也被压缩，以便占用更少的空间。我喜欢叫这些冻干的。像这样被冻结，如果您有许多提交继续重复使用大多数相同的文件，Git可以并且实际上只是重复使用已经冻结的文件。这是Git防止存储库快速增长的几个技巧之一，即使每次提交都会保存每个文件。但是，虽然这对于存档来说是很好的，但对于完成任何新工作来说显然是毫无用处的。您需要可以读写的文件。因此，

git checkout

提取一个提交，它将成为您当前的提交，并将其所有冻干文件重新水化到您的工作树中。在这里，您的文件有其普通的日常格式。您可以使用它们并与它们一起工作

Git可以在这里停止冻结提交的文件，其中一个特别有趣的冻结文件集是当前提交中的文件，而工作树和其他版本控制系统中的可用文件集确实在这里停止。但是由于各种原因，Git隐藏了文件的第三个副本，介于冻结集和可用集之间。这些副本位于Git的索引或暂存区域中，这是同一事物的两个名称。索引中的内容是冻干格式的。但与实际提交不同，这些文件可以随时替换，也可以添加新文件或删除文件

每当您进行新的提交时，Git真正做的是将预冻干的索引副本打包到提交中。这进展非常快，根本不需要也不使用工作树中的内容！因此，您首先必须让Git更新其索引，这就是GitAdd的内容。git add命令freeze会干燥一个工作树文件并覆盖索引中的副本，或者如果该文件以前不在索引中，则在那里创建它

打包了文件，添加了您的名字和日志消息等等，Git设置了新提交的父级

... <-F <-G <-H   <--branch

...--F--G   <-- newbranch
         \
          H   <-- master

...--F--G--H   <-- newbranch, master

...--F--G--H   <-- newbranch (HEAD), master

...--F--G--H   <-- newbranch (HEAD), master
            \
             I

...--F--G--H   <-- master
            \
             I   <-- newbranch (HEAD)

             I   <-- master (HEAD)
            /
...--F--G--H   <-- origin/master

git fetch origin              # or just `git fetch`, which does the same thing
git rebase origin/master      # or `git pull --rebase origin master`
git push origin master

...--F--G--H--I   <-- master

...--F--G--H--I   <-- master (HEAD), origin/master

git checkout -b bug1

...--F--G--H--I   <-- bug1 (HEAD), master, origin/master

...--F--G--H--I   <-- master, origin/master
               \
                J   <-- bug1 (HEAD)

...--F--G--H--I   <-- master, origin/master
               \
                J   <-- bug1 (HEAD), origin/bug1

git checkout -b bug2 master

...--F--G--H--I   <-- bug2 (HEAD), master, origin/master
               \
                J   <-- bug1, origin/bug1

git checkout master

...--F--G--H--I   <-- bug2, master (HEAD), origin/master
               \
                J   <-- bug1, origin/bug1

<make some changes and run git add>
git commit --amend

             K   <-- master (HEAD)
            /
...--F--G--H--I   <-- bug2, origin/master
               \
                J   <-- bug1, origin/bug1

             K   <-- master
            /
...--F--G--H--I   <-- bug2 (HEAD), origin/master
               \
                J   <-- bug1, origin/bug1

git rebase master

               I'  <-- bug2 (HEAD)
              /
             K   <-- master
            /
...--F--G--H--I   <-- origin/master
               \
                J   <-- bug1, origin/bug1

             K   <-- bug2 (HEAD), master
            /
...--F--G--H--I   <-- origin/master
               \
                J   <-- bug1, origin/bug1

git rebase --onto master <anything that specifies commit I>

git rebase --abort

             K   <-- master
            /
...--F--G--H--I   <-- bug2 (HEAD), origin/master
               \
                J   <-- bug1, origin/bug1

             K   <-- bug2 (HEAD), master
            /
...--F--G--H--I   <-- origin/master
               \
                J   <-- bug1, origin/bug1

git push --force-with-lease origin master

git checkout bug1
git rebase --onto master bug1~1

               L--M   <-- bug2
              /
             K   <-- master, origin/master
            / \
...--F--G--H   J'   <-- bug1 (HEAD)
            \
             I
              \
               J   <-- origin/bug1

git push --force-with-lease origin bug1