Git自己进行分支

我一直在一个存储库中使用git，我是该存储库的单独贡献者。存储库托管在Github上。出于某种原因，git偶尔似乎会在Github上分支，而我却不做任何更改。我只在一台计算机上更改此回购协议，不在Github上修改任何内容。然而，正如您在这段缩短的git log--oneline--decoration--graph--all选择中所看到的，我似乎不得不随机地这样做。提交

271056c

在Github上的

cfacddf

处重复

这是什么原因造成的？是虫子吗

我现在考虑的可能理论是：这可能是git commit--amend的结果吗

git日志的输出--oneline--decoration--graph--all：

*   d030d88 (HEAD -> master, origin/master, origin/HEAD) Merge branch 'master' of ***
|\
| * cfacddf Fixed a few things:
* | 798afef modified:   tasks.txt
* | 2c19ea0 Paginated:
* | 271056c Fixed a few things:
|/
* 63a429c Added lock icon to annotation headers

git日志的输出

：

commit d030d8820456b0f129d2d3e5167ed88f87ebe028
Merge: 798afef cfacddf
Author: ***
Date:   Wed Oct 3 16:49:00 2018 -0400

    Merge branch 'master' of https://github.com/malan88/icc

commit 798afefabe24027a955853771072755c08318b47
Author: Michael Alan <michaelalantarpon@gmail.com>
Date:   Wed Oct 3 16:48:54 2018 -0400

    modified:   tasks.txt

commit 2c19ea0b735d148f0057852c196254c4258c2c6b
Author: ***
Date:   Wed Oct 3 16:42:20 2018 -0400

    Paginated:

    - Author index
    - Book index
    - User Annotations
    - Tag index

commit 271056c1c34444dbb3b8c2b6a67efae67f27b44b
Author: ***
Date:   Wed Oct 3 15:24:14 2018 -0400

    Fixed a few things:

    - hash_id bug
    - line_number_form on read.html bug
    - horribly inefficient permissions check on line edits on read.html
    - Added lock change mechanism for when admin doesn't want to edit
        annotation
    - cleaned up some bad whitespace
    - Bug that didn't include query parameters in next parameter (e.g.
    pagenumbers, etc)

commit cfacddfb5395e0fa3676fbc1e19457c45c7c3529
Author: ***
Date:   Wed Oct 3 15:24:14 2018 -0400

    Fixed a few things:

    - hash_id bug
    - line_number_form on read.html bug
    - horribly inefficient permissions check on line edits on read.html
    - Added lock change mechanism for when admin doesn't want to edit
        annotation
    - cleaned up some bad whitespace
    - Bug that didn't include query parameters in next parameter (e.g.
    pagenumbers, etc)

commit cfacddfb5395e0fa3676fbc1e19457c45c7c3529
Author: ***
Date:   Wed Oct 3 15:24:14 2018 -0400

    Fixed a few things:

    - hash_id bug
    - line_number_form on read.html bug
    - horribly inefficient permissions check on line edits on read.html
    - Added lock change mechanism for when admin doesn't want to edit
        annotation
    - cleaned up some bad whitespace

commit 63a429c828cec06fa30e4994f3912fab387c7a4c
Author: ***
Date:   Wed Oct 3 15:21:58 2018 -0400

    Added lock icon to annotation headers

提交d030d8820456b0f129d2d3e5167ed88f87ebe028
合并：798afef cfacddf
作者：***
日期：2018年10月3日星期三16:49:00-0400
合并的“主”分支https://github.com/malan88/icc
提交798AFEFABE24027A955853771072755C0831838B47
作者：迈克尔·艾伦
日期：星期三10月3日16:48:54 2018-0400
修改：tasks.txt
提交2C19EA0B735D148F0057852C196254C258C2C6B
作者：***
日期：2018年10月3日星期三16:42:20-0400
分页：
-作者索引
-图书索引
-用户注释
-标签索引
提交271056c1c34444dbb3b8c2b6a67efae67f27b44b
作者：***
日期：2018年10月3日星期三15:24:14-0400
修正了一些问题：
-散列id错误
-read.html错误上的行号表单
-read.html上的在线编辑权限检查效率极低
-添加了当管理员不想编辑时的锁更改机制
注释
-清除了一些不好的空白
-在下一个参数中没有包含查询参数的Bug（例如。
页码等）
提交cfacddfb5395e0fa3676fbc1e19457c45c7c3529
作者：***
日期：2018年10月3日星期三15:24:14-0400
修正了一些问题：
-散列id错误
-read.html错误上的行号表单
-read.html上的在线编辑权限检查效率极低
-添加了当管理员不想编辑时的锁更改机制
注释
-清除了一些不好的空白
-在下一个参数中没有包含查询参数的Bug（例如。
页码等）
提交cfacddfb5395e0fa3676fbc1e19457c45c7c3529
作者：***
日期：2018年10月3日星期三15:24:14-0400
修正了一些问题：
-散列id错误
-read.html错误上的行号表单
-read.html上的在线编辑权限检查效率极低
-添加了当管理员不想编辑时的锁更改机制
注释
-清除了一些不好的空白
提交63a429c828cec06fa30e4994f3912fab387c7a4c
作者：***
日期：2018年10月3日星期三15:21:58-0400
在注释标题中添加了锁定图标

让我们从以下内容开始：

我现在考虑的可能理论是：这可能是git commit--amend的结果吗

对

现在让我们回到这里，因为这里有一个隐藏的假设，这是一个关键因素：

我一直在一个存储库中使用git，我是该存储库的单独贡献者。存储库托管在GitHub上

这是不对的。这里您的意思是GitHub上有一个存储库。它不是存储库：它是多个或多个存储库中的一个。在本例中，它是两种情况之一。另一个在你自己的机器上

要获得正确的解释，请参阅我的许多较长的答案中的任何一个。另请参见网站，该网站有许多重要背景。但简而言之，请记住这里有两个存储库：您的存储库和GitHub上的Git存储库

当您进行提交时，它是由其哈希ID唯一标识的，哈希ID是一个丑陋的十六进制大字符串，例如

cfacddfb5395e0fa3676fbc1e19457c45c7c3529

。这就是Git在分支名称

master

中存储的内容。每个提交还存储其上一个或父提交的哈希ID。合并提交是至少有两个父级的提交。当分支名称或提交存储提交的哈希ID时，我们称此名称或此提交指向目标提交

我们可以绘制（水平方向的）图形，最新的提交位于右侧：

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

运行

git commit

时，通常的过程是立即将索引中的内容冻结到新快照中，使用

HEAD

所连接的分支名称中的指针使快照的父级成为当前提交：

...--F--G--H--I

然后Git将新提交的哈希ID放入当前分支名称中，以便它现在指向新提交：

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

也就是说，

--amend

将当前提交推到一边

如果你没有按，这个很好用 如果您从未将commit

H

推到任何位置，那么现在可以修改它。新的提交

I

接管；提交

H

消失，再也看不见。（默认情况下，您可以在自己的存储库中找到它至少30天，直到记住它的reflog条目过期。但它不会显示在正常的

git日志输出中。）

但如果你有，它就失败了
但是，如果您已将commit
H
发送到另一个Git，例如您存储在GitHub上的存储库，那么无论何时您与他们联系，他们都会再次向您提供commit
H
，作为其
主分支上的一个重要commit。这就是本案发生的情况

您已将提交
H
推送到GitHub。然后让Git将
H
推开，如上所述，但GitHub仍然有
H
。你的Git会记住这一点，但是如果你的Git忘记了或者你擦除了它的内存，那么下次你让Git在GitHub上调用Git时，它会提醒你的Git。现在你有了这个：

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

此时，您运行了
git pull
，它让您的git在GitHub调用git，并从GitHub获得任何新的提交（没有），并将您的
origin/master
更新为
          H
         /
...--F--G--I   <-- master (HEAD)

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

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

          H_  <-- origin/master
         /  `----__
...--F--G--I--J--K-=L   <-- master (HEAD)

git push origin master

! [rejected]        master -> master (non-fast-forward)