如何为下一个git push命令列出文件

我正试图将一个分支推到原点

git push --set-upstream origin v0.8

这似乎要花很长时间，最终会因为一个错误而停止

Counting objects: 180, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (92/92), done.
Writing objects: 100% (180/180), 538.00 MiB | 72.00 KiB/s, done.
Total 180 (delta 142), reused 110 (delta 87)
remote: error: GH001: Large files detected. You may want to try Git Large File Storage - https://git-lfs.github.com.
remote: error: Trace: eef60ca4521006cb11e4b7f181bc7a1a
remote: error: See http://git.io/iEPt8g for more information.
remote: error: File X.sql is 1537.98 MB; this exceeds GitHub's file size limit of 100.00 MB
To https://github.com/X/X.git
  ! [remote rejected] v0.8 -> v0.8 (pre-receive hook declined)
error: failed to push some refs to 'https://github.com/X/X.git'

显然，它试图推送一个名为X.sql的1.5Gb文件。。。？我在任何地方都看不到这个文件？ 所以我和他一起看了日志

git log v0.8 --not --remotes=origin

给

commit 046332334e1f944f64a110f92434cdc26e9fafd0
Author: X
Date:   Thu Jun 9 23:47:27 2016 +0100

search branch pushed to remote

commit 4b6d7c87a34bcd43f098d54263a032bb66baf9db  
Merge: 631d55a 539e3dc 
Author: X
Date:   Sun Jun 5 22:10:28 2016 +0100

Merge branch 'master' of https://github.com/X

commit 631d55a0998e99ebc7614bf4f58b85baa4e85403  
Author: X
Date:   Sun Jun 5 22:10:15 2016 +0100

once

commit 4aa7275f4381c222fff7ba9ae22ab00df886ba3b
Author: fbeutler X
Date:   Sun Jun 5 22:09:27 2016 +0100

once

如何查看连接到提交的所有文件？只是为了检查一个有大文件的人？ 从下面的答案中，我看到我可能提交了一个大文件并将其删除。在这种情况下，git rebase将是删除它的方法。然而，如果没有上游分支机构，再基础就不起作用了？ 下面是rebase的输出

git rebase -i
There is no tracking information for the current branch.
Please specify which branch you want to rebase against.
See git-rebase(1) for details

    git rebase <branch>

If you wish to set tracking information for this branch you can do so with:

    git branch --set-upstream-to=origin/<branch> v0.8

我的问题可以通过删除所有当前提交并重新提交和推送我的当前版本来解决。。。可能吗

编辑：这是的输出

git log --graph --decorate --oneline --all

*   408ef30 (master) h
|\  
| * 7d4ecd3 (origin/master, origin/HEAD) new every
| * c63f869 every bug
| * a60a14a querydate bug fixed
| * 957a6d3 problem in every
| * 602891c problem in every
| * 9e827d2 problem in every
| | * 0463323 (HEAD -> v0.8, test) branch pushed to remote
| |/  
|/|   
* |   4b6d7c8 Merge branch 'master' of https://github.com/X/X
|\ \  
| |/  
| * 539e3dc pagedown removed, bibtex bug resolved
* | 631d55a once
* | 4aa7275 once
|/  

---

编辑：现在我们有了

git日志--图形--装饰--一行--所有

输出，更容易看到发生了什么并提出建议

简单的方法： 有一个基于Java的工具，基本上可以为您完成以下所有工作。我本人从未使用过它，但它在StackOverflow上有自己的标签

稍微难一点的方法：

git过滤器分支

由于您知道文件名，因此可以使用

git filter branch

以自动方式执行以下所有步骤。只需将索引过滤器与

git rm--cached--ignore unmatch path/to/X.sql

，并过滤所有

master

、

test

和

v0.8

分支。但一般来说，您应该只在知道自己在做什么之后使用

过滤器分支

，并且可以按照下面的所有步骤进行操作

困难的方法：非常像

过滤器分支

将要做的，但是是手动的 这已经变得相当长了，在这里引用将使它更长，但我认为这样更清楚，所以我们开始吧。：-）

实际图形如下所示：

* 408ef30 (master) h
|\  
| * 7d4ecd3 (origin/master, origin/HEAD) new every
| * c63f869 every bug
| * a60a14a querydate bug fixed
| * 957a6d3 problem in every
| * 602891c problem in every
| * 9e827d2 problem in every
| | * 0463323 (HEAD -> v0.8, test) branch pushed to remote
| |/  
|/|   
* |   4b6d7c8 Merge branch 'master' of https://github.com/X/X
|\ \  
| |/  
| * 539e3dc pagedown removed, bibtex bug resolved
* | 631d55a once
* | 4aa7275 once
|/  

* xxxxxxx (HEAD -> v0.8) branch pushed to remote
* xxxxxxx (repairwork) "re-merge without huge file" 
|\
* | xxxxxxx once
* | xxxxxxx once

git add . && git commit -m 'add stuff'

我们可以从中看出，

v0.8

是一个分支（不是一个标签：知道它很有用，但在推送方面没有什么区别，只是在我们修复东西时做了什么）。该特定分支指向commit

0463323

。还有一个额外的分支名称，

test

，它也指向同一个提交

0463323

的父级是……

4b6d7c8合并分支“主级”

。因为

4b6d7c8

是一个合并，所以它有两个父级。这两个父提交被

539e3dc pagedown删除，bibtex错误被解决

和

631d55a一次

提交

539e3dc

在

origin/master

上，因此已经在GitHub上。它不可能有问题的大文件，也不可能有任何父提交（也在GitHub上）。但是，提交

631d55a

不在GitHub上，其父提交

4aa7275

也不在GitHub上。下面还有一行丢失了，但我们可以从

|/

行中看到，commit

4aa7275

和commit

539e3dc

必须在任何提交时将它们的历史记录合并在一起

我们仍然无法确定大文件是从何处潜入的，也无法确定它随后是从何处删除的，但我们仅从四种可能性开始：

• 0463323分支已推送到远程

  （尽管名称不同，但实际上并未推送到远程；推送到失败）

• 4b6d7c8合并分支“主”的…

• 631d55a一次

• 4aa7275一次

（这四个也在GitLogV0.8中——不是——remotes=origin输出）

原始答案中的推理仍然有效。大文件不能位于最上面的提交中（分支名称

v0.8

指向的提交），因为我们会在那里看到大文件。它也不能在该提交的父级中，因为如果它是，当我们查看最上面的提交时，我们会看到该文件被删除，而我们不会

这就留下了将

631d55a一次

和

4aa7275一次

作为剩余的潜在罪犯。这些提交中至少有一个（可能是两个）具有我们不想要的大文件

我们可以解决这个问题，但是。。。 从

v0.8

开始，沿着链向下（回顾历史）是我们发现这四个候选提交的原因。但是，请查看图的顶部，标记为

master

（

408ef30h

）的提交位于该图的顶部。此提交也是一个合并提交，有两个父级。其中一位家长是

7d4ecd3 new every

，标签为

origin/master

。另一个父级是…的4b6d7c8合并分支“主级”

此合并提交

4b6d7c8

连接到已删除的

pagedown

提交，该提交很好，位于

origin/master

上，但也连接到两次

提交中最新的一次
提交，我们怀疑该提交不正确

这意味着为了澄清这一切，我们需要：

查找两个
提交中的哪一个是错误的（可能是两个）；我们不再需要这些了

至少编写一个我们确实需要的新提交，它的父级是
4aa7275的父级一次
：未显示的提交位于图表底部
有多种方法可以做到这一点，但我认为这是一种最简单的方法。我假设在两次
提交之后，两次
提交中有一些好的东西，您确实希望在这两次提交之后进行合并，并且您确实希望在合并之后创建一个名为
v0.8
的分支，并且您确实希望
master
成为这个新链的大部分顶部的合并提交，包括中间合并提交，它将
origin/master
合并回新链中

如果这些假设是错误的，这不是您想要做的（过滤分支或BFG cleaner“简单”方法也不是您真正想要的）。但这一切都超出了本报告的范围
git cherry-pick -n 4aa7275

* xxxxxxx (HEAD -> repairwork) once
* xxxxxxx once
|
| * 408ef30 (master) h
| |\  
| | * 7d4ecd3 (origin/master, origin/HEAD) new every
| | * c63f869 every bug
| | * a60a14a querydate bug fixed
| | * 957a6d3 problem in every
| | * 602891c problem in every
| | * 9e827d2 problem in every
| | | * 0463323 (v0.8, test) branch pushed to remote
| | |/  
| |/|   
| * |   4b6d7c8 Merge branch 'master' of https://github.com/X/X
| |\ \  
| | |/  
| | * 539e3dc pagedown removed, bibtex bug resolved
| * | 631d55a once
| * | 4aa7275 once
| |/  
|//
*  xxxxxxx some commit msg

* xxxxxxx (HEAD -> repairwork) "re-merge without huge file" 
|\
* | xxxxxxx once
* | xxxxxxx once

git checkout -b v0.8-fixed       # make new branch
git cherry-pick v0.8             # copy one commit to it
git branch -m v0.8 v0.8-broken   # rename broken branch
git branch -m v0.8               # rename our branch

* xxxxxxx (HEAD -> v0.8) branch pushed to remote
* xxxxxxx (repairwork) "re-merge without huge file" 
|\
* | xxxxxxx once
* | xxxxxxx once

git checkout master
git reset --hard <some commit>
git merge <another commit>

git push --set-upstream origin v0.8

git add . && git commit -m 'add stuff'

git rm bigfile && git commit -m 'rm 1.5 GB file'

git log v0.8 --not --remotes=origin

Counting objects: 180, done.

Delta compression using up to 4 threads.
Compressing objects: 100% (92/92), done.

Writing objects: 100% (180/180), 538.00 MiB | 72.00 KiB/s, done.
Total 180 (delta 142), reused 110 (delta 87)

remote: error: GH001: Large files detected. You may want to try ...
remote: error: Trace: eef60ca4521006cb11e4b7f181bc7a1a
remote: error: See http://git.io/iEPt8g for more information.
remote: error: File X.sql is 1537.98 MB; this exceeds ...

git cat-file -t eef60ca4521006cb11e4b7f181bc7a1a

To https://github.com/X/X.git
  ! [remote rejected] v0.8 -> v0.8 (pre-receive hook declined)
error: failed to push some refs to 'https://github.com/X/X.git'

$ git push origin refs/tags/derp2
Total 0 (delta 0), reused 0 (delta 0)
remote: pre receive hook
remote: found tag
To [redacted]
 ! [remote rejected] derp2 -> derp2 (pre-receive hook declined)
error: failed to push some refs to '[redacted]'