blocks|key|3399729|text|使用。而不是...|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3399730|git+checkout+.|code-block|syntax|javascript|3399731|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

Use . instead of --

<pre><code>git checkout .
</code></pre>

blocks|key|1674980|text|如果您想放弃所做的所有更改，只需使用|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1674981|git+checkout+.|code-block|syntax|javascript|1674982|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

If you want to discard all changes you've made, just use

<pre><code>git checkout .
</code></pre>

blocks|key|3312162|text|当您使用"rm+-r+file“从文件系统中删除文件时，您不会将其从存储库中删除。你需要在git中使用"git+rm“做同样的事情。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3312163|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

when you delete file from filesystem using "rm -r file" you don't delete it from repository. Yo need do de same in git using "git rm "

blocks|key|1675060|text|我使用了git+checkout+--。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1675061|还有git结账。|1675062|==和op说的一样，都能在MacOSX10.7和Linux上工作，在这两种系统上都能工作|1675063|使用git版本1.7.7.5+(Apple+Git-26)和git+1.7.1编译|1675064|尝试不同的存储库，看看是否得到相同的结果。也许是git版本中的命令错误？|1675065|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

I used git checkout -- . 

Also git checkout . 

== the same thing as the op said
both worked Mac OSX 10.7 and Linux, worked on both

with git version 1.7.7.5 (Apple Git-26)
and
git 1.7.1 compiled

Try a different repo and see if you get the same results.
Maybe a command bug in the git version?

blocks|key|1675110|text|这是由于多个文件具有相同的名称但不同的大小写。在OSX中，不区分大小写，不喜欢多个同名不同大小写的文件。它将它们视为相同的文件。为了解决这个问题，我对一个临时文件名运行了git+mv+(或者只是mv)，添加了临时文件，这允许git删除旧的/错误命名的版本，然后第二次提交来重新命名它们。这也可以在允许具有相同名称的不同文件具有不同大小写的文件系统上得到纠正。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1675111|entityMap^0|2D|6|2P|2|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

The cause for this was due to multiple files with the same name but different cases. In OSX, which is case-insensitive, doesn't like multiple files with the same name but different cases. It views them as the same file.
To fix this, I ran <code>git mv</code> (or just <code>mv</code>) to a temporary filename, added the temp files, which allowed git to remove the old/incorrectly named versions, then a second commit to name them back.
This could also be corrected on a filesystem which allows different files with the same name to be different cases.

blocks|key|1890426|text|根据您的评论，您必须将存储库配置为区分大小写：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1890427|git+config+core.ignorecase+false|code-block|syntax|javascript|1890428|这允许git跟踪这两个文件(尽管文件系统只显示一个，这非常令人困惑)。以下是复制步骤，用于演示git正确跟踪大小写敏感度时发生的情况：|1890429|git+init+/tmp/test+&&+cd+/tmp/test
git+config+core.ignorecase+false
echo+test>test+&&+git+add+test+&&+git+commit+-m+"lowercase+t"
mv+test+Test|1890430|现在git+status与test没有什么不同|offset|length|style|CODE|1890431|git+status+-s
+??+Test|1890432|提交Test并使用git+ls-files查看我们现在正在跟踪的内容：|1890433|git+add+Test+&&+git+commit+-m+"uppercase+T"
git+ls-files
+Test
+test|1890434|ls会报告什么？为什么，只是“测试”，很自然：|1890435|ls
+Test|1890436|最后，当我们修改Test时会发生什么？|1890437|echo+garbage>Test
git+status+-s
+M+Test
+M+test|1890438|啊!怎么这么乱呀。|1890439|entityMap^0|0|0|0|0|2|A|D|4|0|0|2|4|9|C|0|0|0|2|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|19|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|1A|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|1B|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|1C|8|@$M|1D|N|1E|O|P]|$M|1F|N|1G|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|D|7|1H|8|@]|9|@]|A|$E|F]]|$1|S|3|T|5|6|7|1I|8|@$M|1J|N|1K|O|P]|$M|1L|N|1M|O|P]]|9|@]|A|$]]|$1|U|3|V|5|D|7|1N|8|@]|9|@]|A|$E|F]]|$1|W|3|X|5|6|7|1O|8|@$M|1P|N|1Q|O|P]]|9|@]|A|$]]|$1|Y|3|Z|5|D|7|1R|8|@]|9|@]|A|$E|F]]|$1|10|3|11|5|6|7|1S|8|@]|9|@]|A|$]]|$1|12|3|13|5|D|7|1T|8|@]|9|@]|A|$E|F]]|$1|14|3|15|5|6|7|1U|8|@]|9|@]|A|$]]|$1|16|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]]|17|$]]

Based on your comments, you must configure your repository to be case sensitive: 

<pre><code>git config core.ignorecase false
</code></pre>

This allows git to track both files (although the file system only shows one, which is enormously confusing). Here are replication steps to demonstrate what's happening, when git is correctly tracking case sensitivity:

<pre><code>git init /tmp/test &amp;&amp; cd /tmp/test
git config core.ignorecase false
echo test&gt;test &amp;&amp; git add test &amp;&amp; git commit -m "lowercase t"
mv test Test
</code></pre>

Now <code>git status</code> shows no differences to <code>test</code>:

<pre><code>git status -s
 ?? Test
</code></pre>

Commit <code>Test</code> and use <code>git ls-files</code> to see what we're now tracking:

<pre><code>git add Test &amp;&amp; git commit -m "uppercase T"
git ls-files
 Test
 test
</code></pre>

What does <code>ls</code> report? Why, just 'Test', naturally:

<pre><code>ls
 Test
</code></pre>

Finally, what happens when we modify Test?

<pre><code>echo garbage&gt;Test
git status -s
 M Test
 M test
</code></pre>

What a mess.

blocks|key|1675203|text|我也面临着同样的问题。我发现这两个有问题的文件都有DOS行结束字符。我这样做是为了解决这个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1675204|1-使用不同的克隆将行结尾更改为UNIX+2-清除出现问题的克隆，然后重新克隆它。|1675205|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I faced the same problem. I found that the two problematic files had DOS line ending characters. I did this to fix the problem.

1- use a different clone to change the line ending to UNIX
2- blow away the clone where the problem was appearing and re clone it.

blocks|key|1675207|text|你试过了吗|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1675208|git+config+--global+core.autocrlf+false|code-block|syntax|javascript|1675209|或|1675210|git+config+--global+core.filemode+false|1675211|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

Did you try

<pre><code>git config --global core.autocrlf false
</code></pre>

or

<pre><code>git config --global core.filemode false
</code></pre>

blocks|key|1890468|text|出于某种原因，同样的事情也发生在我身上，但这不是一个区分大小写的问题。删除文件，然后更改分支解决了此问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1890469|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

For some reason this same thing happened to me, but it was not a case-sensitivity problem. Deleting the file, then changing branches resolved the issue.

blocks|key|3312397|text|为了避免下次出现这个问题，我决定将我的文件系统转换为区分大小写。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3312398|令我惊喜的是，它在Mac+(10.13.4)上非常容易。|3312399|可以使用不同的文件系统快速创建新的磁盘卷：|3312400|卷上运行磁盘应用工具，然后单击Container|3312401|click+on+|unordered-list-item|3312402|(%2B)|3312403|3312404|3312405|我将新卷命名为"Projects“，并将格式设置为APFS+(区分大小写)。|3312406|在那之后，我将所有的项目都移到了新的卷中。|3312407|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|X|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|Y|8|@]|9|@]|A|$]]|$1|K|3|L|5|J|7|Z|8|@]|9|@]|A|$]]|$1|M|3|-4|5|J|7|10|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|12|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|13|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|T|$]]

To avoid this problem next time, I decided to convert my file system to case-sensitive.

I was pleasantly surprised that it is pretty easy on Mac OS (10.13.4).

It's possible to create quickly a new disk-volume with a different file system:

<ul>
<li>run Disk Utility</li>
<li>click on Container</li>
<li>click on Volume (+)</li>
</ul>

I named new volume "Projects" and set Format to APFS (Case-sensitive).

After that I moved all projects to the new volume.

blocks|key|1675290|text|对我的情况有帮助的是：(也改进了vinboxx的答案)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1675291|我已经通过以下方式配置了.gitattributes：|offset|length|style|CODE|1675292|*+text+eol=crlf|code-block|syntax|javascript|1675293|(我想让-X+renormalize在合并后自动使用正确的格式)|1675294|在临时注释该行并设置git+config+core.autocrlf+false之后。一切都恢复正常了。|1675295|entityMap^0|0|C|E|0|0|0|A|U|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@$D|U|E|V|F|G]]|9|@]|A|$]]|$1|H|3|I|5|J|7|W|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|Y|8|@$D|Z|E|10|F|G]]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|R|$]]

What helped in my case: (also improving vinboxx's answer)

I had got configured <code>.gitattributes</code> in a following way:

<pre><code>* text eol=crlf
</code></pre>

(I wanted -X renormalize to automatically use proper format after merge)

After temporarily commenting that line along with setting <code>git config core.autocrlf false</code>. Everything went back to normal.

I have changes in my working directory that I'm trying to discard (reset to the current indexed version of the files), however, <code>git checkout -- &lt;file&gt;</code> will not discard the changes.
I've attempted to manually remove the files (<code>rm -r files</code>) then run <code>git checkout -- .</code>, which displays the files as modified again.

<pre><code>$ git checkout -- .
$ git status
# On branch master
# Changes not staged for commit:
# (use "git add &lt;file&gt;..." to update what will be committed)
# (use "git checkout -- &lt;file&gt;..." to discard changes in working directory)
#
# modified: files/Hulk.png
# modified: files/Hulk_2.png
#
no changes added to commit (use "git add" and/or "git commit -a")
</code></pre>

Running <code>git diff</code> shows the files are modified...

<pre><code>diff --git a/files/Hulk.png b/files/Hulk.png
index 1c256cb..1d37fe0 100644
Binary files a/files/Hulk.png and b/files/Hulk.png differ
diff --git a/files/Hulk_2.png b/files/Hulk_2.png
index 1c256cb..0717199 100644
Binary files a/files/Hulk_2.png and b/files/Hulk_2.png differ
</code></pre>

NOTE: Some people have said to run <code>git checkout .</code>, however this will achieve the same result as <code>git checkout -- .</code>. The <code>--</code> is just a notation used in the git checkout command to differentiate treeish/commit points from files/paths.

OS: OSX 10.6
Git: 1.7.10.2

git checkout -- <files> doesn't discard changes?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我尝试放弃工作目录中的更改(重置为文件的当前索引版本)，但是，git checkout -- <file>不会放弃这些更改。我尝试手动删除文件(rm -r files)，然后运行git checkout -- .，它会再次将文件显示为已修改。$ git checkout -- .$ git status# On bra...

问<files>签出-- git不放弃更改？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问<files>签出-- git不放弃更改？EN