问题是git rebase -i HEAD~20
向您显示了您的项目的虚假线性历史。 Git和Github有这样做的坏习惯,这是很多混淆的根源。实际上,Git是一个图形(在计算机科学意义上)。
以下是由git log --decorate --oneline
产生的假的线性历史记录,遗憾地被Github使用。
1ff521a (HEAD -> master, origin/master, origin/HEAD) Revert "Boulder code + minor changes"
85cb9fa Merge remote-tracking branch 'origin/master'
47d93ec Boulder code + minor changes
e6bb627 Recommit actor and sw
c6a48cc Add files via upload
1f005ec Create readme.txt
33f251b Added missing files, reuploading project
0b520fd Boulder code + minor changes
4068bca Recommit actor and sw
9b2aa1c Add files via upload
f7ed4ad Create readme.txt
14a6d35 Add files via upload
244e6d9 Create readme.txt
ce33d87 Add files via upload
86ae9a2 Add files via upload
8bec858 Add files via upload
f001fb0 Create readme.txt
d8dbf27 Create readme.txt
9ef59fc Delete Debug
64bfb3e Create Debug
aab055b Created DiggerMan folder (organization)
deb834b Added Debug Items
f219ae5 Create readme.txt
9da61f0 Added missing files, reuploading project
d6459cb added missing dll files, no other major change
42b500d Merged and organized code from last commit.
0a87678 Merge remote-tracking branch 'origin/master'
81f93fb Created new base class for objects that can be picked up
67e6369 HUD now displayed and partially implemented
4da4bff DiggerMan can now dig!
这是git log --graph --decorate --oneline
的现实。它显示了提交的真实关系。
* 1ff521a (HEAD -> master, origin/master, origin/HEAD) Revert "Boulder code + minor changes"
* 85cb9fa Merge remote-tracking branch 'origin/master'
|\
| * 0b520fd Boulder code + minor changes
| * 4068bca Recommit actor and sw
| * 9b2aa1c Add files via upload
| * f7ed4ad Create readme.txt
| * 14a6d35 Add files via upload
| * 244e6d9 Create readme.txt
| * ce33d87 Add files via upload
| * 86ae9a2 Add files via upload
| * 8bec858 Add files via upload
| * f001fb0 Create readme.txt
| * d8dbf27 Create readme.txt
| * 9ef59fc Delete Debug
| * 64bfb3e Create Debug
| * aab055b Created DiggerMan folder (organization)
| * deb834b Added Debug Items
| * f219ae5 Create readme.txt
| * 9da61f0 Added missing files, reuploading project
* | 47d93ec Boulder code + minor changes
* | e6bb627 Recommit actor and sw
* | c6a48cc Add files via upload
* | 1f005ec Create readme.txt
* | 33f251b Added missing files, reuploading project
|/
* d6459cb added missing dll files, no other major change
* 42b500d Merged and organized code from last commit.
* 0a87678 Merge remote-tracking branch 'origin/master'
|\
| * 67e6369 HUD now displayed and partially implemented
* | 81f93fb Created new base class for objects that can be picked up
|/
* 4da4bff DiggerMan can now dig!
那些看起来像分支的东西是分支。 Git分支只是一个提交的标签。当你git branch -d
你只是删除标签。 合并后保留实际分支。这被称为“拓扑顺序”,需要了解Git中发生了什么。拓扑顺序是重要的。
git rebase -i HEAD~20
向您展示了一个虚假的线性历史记录,使您看起来像可以压缩所有提交。相反,您必须查看地形并分别挤压每个分支。
如果这看起来过于复杂,那就是。有一个更简单的方法。
最简单的是这样的:不用担心有太多的提交。一般来说,提交太多的小提交比提交较少的提交要好。版本控制的目的之一,特别是提交消息的目的是知道为什么发生更改。小的提交使得将更改与原因联系起来更容易。合并提交将所有原因合并在一起。关于压扁合并有很多建议,不要这样做。
提交的数量和它们的大小是没有意义的措施。相反,良好的提交使代码更容易理解和审查未来。例如,刚刚修复前一个提交中的拼写错误的提交没有意义,如Create Debug
后跟Delete Debug
。使用fixup
摆脱它,或者完全删除这两个提交,或立即用git commit --amend
重写前一个提交。同样,您有四次“创建readme.txt”,这可能是一个错误。OTOH Created DiggerMan folder (organization)
可能是一个有意义的提交,保留它。
最后,在合并前清理您的分支。这可以避免现在这类问题。在合并之前,git rebase -i master
将仅选择当前分支中的提交,并且不会有任何拓扑问题。当你参与一个合作项目并且你的分支需要被审查时,这也是一个好习惯。你需要清理你的分支,然后再提交审查。
你可以向编辑器显示“squash”的更改吗?就像在你保存并关闭它之前一样。 – Schwern
这是:http://imgur.com/a/Ec1hi – StacksAndParsing
rebase中的一些提交ID与Github上的内容不对应。看看“重新演员和sw”。还要注意,rebase有立即前面两个“Create readme.txt”,而Github没有。以线性方式查看提交历史会丢失大量信息。你可以显示一个'git log --graph --decorate',这样我们就可以看到真正的顺序了吗?更好的是,你可以链接到Github回购? – Schwern