git意外地推送了未跟踪的文件

Question

我有一个带.gitignore的本地git存储库，它被设置为忽略* .lammpstrj形式的一些大文件。运行git ls-files会生成预期的跟踪文件列表，并且运行git ls-files -o会显示正确忽略未跟踪文件。但是，当在github上推送到源时，git会尝试将大文件推送到远程存储库，从而导致推送失败。我是否正确查看未跟踪文件列表或我是否需要更改git中的某些内容以防止推送被忽略的文件？我在下面包含了ls-files输出和.gitignore文件。

缓存文件列表：

$ git ls-files
.gitignore
BONDS/BUILD
BONDS/blen
BONDS/bond_lengths.cpp
BONDS/distributions.cpp
BONDS/functions.h
BONDS/globals.h
BONDS/read_dump.cpp
BONDS/read_xyz.cpp
BONDS/unwrap.cpp
BONDS/write_traj.cpp
COMPILE
MSD/BUILD
MSD/COMPILE
MSD/calc_msd.cpp
MSD/functions.h
MSD/globals.h
MSD/msd
MSD/msd_time.cpp
MSD/read_dump.cpp
MSD/read_xyz.cpp
MSD/unwrap.cpp
README.md
RG/BUILD
RG/chain_stats.cpp
RG/distributions.cpp
RG/functions.h
RG/globals.h
RG/read_dump.cpp
RG/read_xyz.cpp
RG/rg
RG/rg_re_com.cpp
RG/unwrap.cpp
RG/write_traj.cpp
RUN
TESTS/COMPILE
TESTS/hello.c
TESTS/sizes
TESTS/sizes.c
TESTS/test
TESTS/test.c
TESTS/test.h
TRAJ/COMPILE
TRAJ/read_dump.cpp
TRAJ/read_xyz.cpp
TRAJ/unwrap.cpp
blen
msd
rg

其他（未跟踪）文件列表：

$ git ls-files . -o
BONDS/bond_lengths.o
BONDS/read_dump.o
BONDS/unwrap.o
BONDS/write_traj.o
MSD/calc_msd.o
MSD/msd_time.o
MSD/read_xyz.o
RG/chain_stats.o
RG/distributions.o
RG/read_dump.o
RG/rg_re_com.o
RG/unwrap.o
RG/write_traj.o
SAMPLE/generate.py
SAMPLE/hists.out
SAMPLE/lengths.out
SAMPLE/mol_traj.lammpstrj
SAMPLE/plot.p
SAMPLE/stats.out
SAMPLE/unwrapped_traj.lammpstrj
SAMPLE/wrapped_traj.lammpstrj

我的.gitignore文件

*.[oa]
*.lammpstrj
SAMPLE/

Answer 1

Git转移提交

首先，请记住Git传输（提取和推送）提交，而不是单个文件。有时文件会被通过这些提交拖动。但究竟是什么意思，特别是在这里？我们来看看。

提交只是：

• 工作树的完整快照（或者更准确地说，是临时区域中的内容或＆＃34;索引＆＃34;）
• 与作者和提交者（姓名，电子邮件地址和时间戳）
• 加上提交消息
• 和一些父提交。

它是第一部分 - 文件树的快照＆＃34; - 它使看起来像 Git推送文件。事实上，Git在下面工作的方式，当Git获取或推送特定提交时，它还必须传输与一起使用的所有文件，除非它们已经存在。

请记住，每次提交都是完整快照。这意味着如果您有一系列提交，以分支提示提交结束：

...--A--B--C   <-- branch-tip

并且提交B只更改了 - 甚至更有可能，添加了一个文件与A，C只有已删除一个文件为与B相比，B和C中的所有其他文件与A中的文件相同。实际上，如果您将文件添加到B，然后在C中再次将其删除，则C中的整个文件集与A中的设置相匹配。对于其余部分，让我们假设这是您所做的：添加内容并将其提交以生成B，然后再将其删除以生成C。 （更有可能的是，您添加和/或修改了多个或多个内容，可能不止一次，并且在您添加其中一个＆＃34;禁止＆＃34;文件的某个地方，然后在更长的链中删除它提交而不仅仅是B--C。）

以这种方式提交共享大量文件非常常见。 （此外，git push和git fetch通常通过巧妙地使用Git所称的＆＃34;瘦包＆＃34;来推送和提取时压缩内容，但这些在查找和查找方面都不重要解决这个问题。）

git fetch和git push涉及两个 Git存储库

每个Git存储库都是自己完整的独立实体。存储库至少在原则上是 peers ：您的存储库并不优于其他存储库，也不逊于它。我们确实可以肯定地说，您的存储库是您的，而他们的他们的。你和他们（无论他们＆＃34;他们是谁）可以自由地强加某种老板/员工或任何风格的关系，但这是你和他们之间的关系，而不是Git自己关心的事情。

无论你是推还是抓，你的Git都会与他们的Git交谈，找出你所拥有的那些他们不想要的（git push），或者他们拥有你不要你想要的（git fetch）。那些提交可能有也可能没有关联文件--Git调用＆＃34; blob＆＃34; - 你和/或他们可能已经那些文件，无论你是否和他们有这些提交

例如，假设您将提交B和C推送到已经提交A的其他Git存储库。你的Git会将他们的Git提交 - 以及他们没有的所有文件，这只是B中添加的文件。

如果您在自己的存储库中要求您的 Git向您显示当前提交中的内容，以及分支提示提交C，您会看到他们在提交A中拥有的同一组文件，与提交A完全相同。 （事实上​​，那些丑陋的SHA-1哈希来自于：它们唯一地标识了确切的Git对象，因此你的Git和它们的Git都可以告诉你们两者都有提交A。请注意即使{ {1}}和A具有相同的树，它们具有不同的提交。它们具有不同的时间戳;但即使它们没有＃＆＃ 39; t，他们也有不同的父母：C的父母是我们无法看到的提交，在左边，而A的父母是C。 ）

仅仅通过查看B，您看不到的是，提交C需要一个额外的文件。如果该文件违反了其他Git强制执行的某些规则，那么您的B将被拒绝，因为他们将检查提交git push 和提交B，并找到有问题的文件。

该怎么办

一般来说，对于这样的项目，答案是＆＃34;重写＆＃34;您自己的提交历史记录 - 例如，仅使用一次新提交替换提交C和B，甚至完全删除C和B。

最棘手的部分通常是弄清楚他们拥有什么＆＃34; vs＆＃34;你有什么＆＃34;，它决定你的Git将发送哪些提交。但通常情况下，如果他们是您的同行 - 甚至是您的C - 您可以使用origin获取其提交的最新副本集，即＆＃34 ;他们拥有什么＆＃34;，然后使用git fetch，可选择git log，以查看你他们不具备的内容。例如，如果您以名称--graph --oneline --decorate跟踪其存储库，则可以执行以下操作：

origin

让你的 Git带来他们的提交，然后：

git fetch origin

看看你的Git有什么不是他们的。 （git log --graph --oneline --decorate @{upstream}..HEAD 实际上只对确定他们是否在某些其他分支上共享您的某些提交有用;如果是这样，重定位，复制提交，可能会导致更多令人头疼，而您＃＆＃ 39;我需要格外小心。）

通常这只会向您显示您自己的提交 - 如果您很幸运和/或小心，没有合并 - 然后您可以使用--decorate来删除或修复包含不需要的文件的提交。使用：

git rebase

查看相同的提交（如果您愿意，也可以使用git log --oneline --name-status @{u}.. 和其他选项），在每个提交的每个单行日志消息后添加--graph，以便您可以找到确定哪些提交修改或添加了您不想发送的文件。

另见git trying to push non-existent file ... after clearing cache。