删除提交而不还原所做的更改

时间:2017-04-30 17:36:10

标签: git github

大家好我是github的新手。我刚开始与一些朋友一起为一个团队项目开发私人存储库。我不得不做一堆提交来组织代码,添加文件夹,移动东西等等。但是,这导致了提交的混乱。我想将照片中括号内的所有提交合并为一个提交,这样看起来并不简洁:enter image description here

我创建了一个前一个帖子,我使用git rebase -i HEAD~20,然后弹出这个文本文件,但是当我更改括号内的所有内容时,我从pick改为“squash我得到了一个错误:error: cannot 'squash' without a previous commit

非常感谢任何帮助。这也是我第一次使用github,所以我对它不太了解。 enter image description here

2 个答案:

答案 0 :(得分:1)

问题是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将仅选择当前分支中的提交,并且不存在任何拓扑问题。当你从事协作项目并且需要审查你的分支机构时,这也是一个很好的习惯。在提交审核之前,您希望清理您的分支。

答案 1 :(得分:0)

您要压缩的第一个提交是4eb500d

Github没有显示它,但是提交消息("合并和组织......")告诉我为什么不能压缩这个提交:它是一个合并提交。

Squashing意味着压缩提交引入的更改将合并到父提交中。但合并提交不是常规提交;它有两个或多个父提交。

不清楚git rebase是什么父母要压制你告诉它要压缩的提交。更重要的是,如果您将其压缩到其父节点之一,则会删除合并操作。这些可能是Git不允许压缩合并提交的好理由。

使用图形Git客户端查看提交如何相互关联并分别编辑每个分支。然后,您可以重新创建合并提交,最终丢弃您不想保留的当前提交。