“；“未为提交而进行的更改”；即使在git提交之后-am b/c origin也有一个文件名为de-capitalize的文件

问题：同一目录中两个不同名称案例下的两个文件，我一开始不知道。所以我很惊讶的看到这个,

git commit -am "why"
On branch tmp
Changes not staged for commit:
    modified:   src/view/callCenter/seatReport/SeatSubstate.vue

然后我发现origin在路径

src/view/callCenter/seatReport

但是在我的mac电脑上

ls src/view/callCenter/seatReport/
...     seatSubstate.vue /* did NOT show SeatSubstate.vue only seatSubstate.vue */

我知道有人在讨论这个问题

但是我仍然不明白为什么git不能提交这个文件

第二，我如何解决这个问题？例如，在那次讨论中，很多人都提到了

git-mv

，但我不确定

git-mv

能否解决我的问题

-----更新-----

我突然意识到我的mac电脑（我的高清电脑）不区分大小写（APFS），请参阅

通常情况下，这意味着SeatSubstate.vue和SeatSubstate.vue是同一个文件，但git使它们成为两个不同的文件，从而导致了问题

gitmv

似乎可以解决问题，但我不是100%确定

请参阅正确定义问题 Git总是能够在提交和Git的索引中存储两个文件，这两个文件位于同一目录中的两个不同名称的情况下（例如，

README

和

README

），因为Git根本不在操作系统目录中存储文件。文件要么在提交中被冻结，1这意味着无论它们是在Linux、Windows、MacOS或任何其他系统上，它们都保持其形式，要么它们在Git的索引中，实际上只是一个数据文件。2

出现问题的原因是，作为人类操作Git的用户，您希望使用操作系统提供的文件系统，在该系统中，您的计算机以正常的日常形式存储文件，以便计算机的其他部分也可以使用它们。这不是一个不合理的要求，Git的内部文件存储在只有Git才能使用的内部形式中。您需要能够使用Git完成一些事情，而不仅仅是整天玩Git

MacOS能够提供区分大小写的文件系统（可以将

自述文件

和

自述文件

保存在同一目录中），但默认情况下不提供。所以，要么根本不使用MacOS，要么使用这种功能，有人不是你做了这类事情：

然后我发现origin在路径

src/view/callCenter/seatReport

换句话说，您在某些现有提交中同时拥有这两个文件。正如我们刚才所说，Git完全能够处理这个问题。不是你的操作系统

因此，如果您运行

git checkout

并选择提交，git将把这两个文件复制到您的索引中，该索引现在有两个拼写，

SeatSubstate.vue

和

SeatSubstate.vue

。它还会将两个文件（都有拼写！）复制到您的工作树中，但您的操作系统只能保存一个拼写，因此一个文件会删除另一个文件，而您只剩下一个文件和一个拼写

当Git将索引文件及其内容与工作树文件及其内容进行比较时，Git将：

• 看，根据索引，有两个文件
• 尝试将每个索引文件与Git打开该名称时获取的工作树文件进行比较
• 抱怨其中一个被修改了

下面是一个示例，我在Unix-y系统上创建了一个存储库，给它两个文件，

README

和

README

，它们的内容不同，然后将它们克隆到Mac上：

sh-3.2$ git clone ssh://[path]/caseissue
...
Receiving objects: 100% (4/4), done.
sh-3.2$ cd caseissue
sh-3.2$ ls
readme

让我们看一下索引中的内容：

sh-3.2$ git ls-files --stage
100644 a931371bf02ce4048b623c56beadb9a926138516 0       README
100644 418440c534135db897251cc3ceca362fe83c2117 0       readme

sh-3.2$ git show :README
I AM AN UPPERCASE FILE
UPPERCASE IS LIKE SHOUTING
sh-3.2$ git show :readme
i am a lowercase file

果然，它有两个文件，只是大小写不同。让我们看看这些文件中有什么，以及工作树中有什么：

sh-3.2$ git show :0:README
I AM AN UPPERCASE FILE
sh-3.2$ git show :0:readme
i am a lowercase file
sh-3.2$ cat readme 
i am a lowercase file

以及我们的地位：

sh-3.2$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   README

no changes added to commit (use "git add" and/or "git commit -a")

现在，根本不要使用

gitcommit-a

，因为这将同时进行两次删除。相反，处理剩下的文件（在我的例子中，一个也没有），做任何你需要做的事情，然后阶段-

git add

-只处理那些你修改过的文件，而不以任何方式接触任何已删除的文件

现在，您可以

git commit

在不影响工作树中丢失但仍存在于新提交中的两个文件的情况下提交结果：

sh-3.2$ echo 'this file is independent of the READMEs' > newfile
sh-3.2$ git add newfile
sh-3.2$ git commit -m 'add new file'
[master 6d5d8fc] add new file
 1 file changed, 1 insertion(+)
 create mode 100644 newfile
sh-3.2$ git push origin master
Counting objects: 3, done.
...
   2dee30f..6d5d8fc  master -> master

在另一台（区分大小写的文件系统）计算机上，更新到此提交后：

$ ls
newfile readme  README
$ for i in *; do echo -n ${i}: && cat $i; done
newfile:this file is independent of the READMEs
readme:i am a lowercase file
README:I AM AN UPPERCASE FILE

因此，我们完全有能力在Mac（或Windows！）系统上进行这些提交：我们只需删除不需要的文件，并小心避免分段删除

如果您确实需要其中一个文件，但不需要更改它，该怎么办 现在问题更难了一点，因为在Mac或Windows系统上，我们不区分大小写的工作树中无法同时保存两个拼写的文件

但是我们可以选择我们得到的文件！假设我们需要

自述文件。我们可以看到，我们得到了上面的
readme
文件。因此，我们将删除错误的一个（嗯，我们已经删除了），然后：

sh-3.2$ git checkout -- README
sh-3.2$ ls
README  newfile
sh-3.2$ cat README 
I AM AN UPPERCASE FILE

如果我们需要，请使用小写字母：

sh-3.2$ rm README 
sh-3.2$ git checkout -- readme
sh-3.2$ ls
newfile readme
sh-3.2$ cat readme
i am a lowercase file

也就是说，我们删除了错误的一个，然后使用索引操作中的“抓取一个文件”-
git checkout--path
——来获取包含我们想要的一个案例的一个文件。我们现在可以使用此文件。但我们不能添加或更改它

如果您需要两个文件，或者需要处理其中一个文件，该怎么办？
如果您需要同时使用这两种命名方式，那么您就有麻烦了，因为您的操作系统实际上无法做到这一点，至少在这个文件系统上不行；您将需要创建一个区分大小写的文件系统，然后整个问题就解决了。但是如果你一次只需要一个，去做一些改变，这是我们可以做到的，尽管很尴尬

首先，请注意，您可以很容易地获取一个或两个文件的内容：

sh-3.2$ git show :README
I AM AN UPPERCASE FILE
sh-3.2$ git show :readme
i am a lowercase file

（旁注：字符串
：0:README
和
：README
的含义完全相同。）
sh-3.2$ rm readme
sh-3.2$ git checkout -- README
sh-3.2$ echo UPPERCASE IS LIKE SHOUTING >> README
sh-3.2$ git add README 
sh-3.2$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   readme

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   README

sh-3.2$ git show :0:README
I AM AN UPPERCASE FILE
sh-3.2$ git show :0:readme
I AM AN UPPERCASE FILE
UPPERCASE IS LIKE SHOUTING

sh-3.2$ git reset --hard
HEAD is now at 6d5d8fc add new file
sh-3.2$ rm readme 
sh-3.2$ git status --short
 D README
 D readme

sh-3.2$ git checkout -- README
sh-3.2$ cat README 
I AM AN UPPERCASE FILE

sh-3.2$ echo UPPERCASE IS LIKE SHOUTING >> README

sh-3.2$ blob=$(git hash-object -w README)
sh-3.2$ echo $blob
fd109721431e207046a4daefc9712f1424d7f38f

sh-3.2$ printf '100644 %s 0\tREADME\n' $blob | git update-index --index-info
sh-3.2$ git status --short
M  README
 M readme

sh-3.2$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   readme

sh-3.2$ git show :README
I AM AN UPPERCASE FILE
UPPERCASE IS LIKE SHOUTING
sh-3.2$ git show :readme
i am a lowercase file

sh-3.2$ git commit -m 'annotate README'
[master ff51464] annotate README
 1 file changed, 1 insertion(+)
sh-3.2$ git push origin master
Counting objects: 3, done.
...
   6d5d8fc..ff51464  master -> master

$ for i in *; do echo -n ${i}: && cat $i; done
newfile:this file is independent of the READMEs
readme:i am a lowercase file
README:I AM AN UPPERCASE FILE
UPPERCASE IS LIKE SHOUTING