我正在尝试在version control系统中添加已经现有代码库，例如git。
我遇到一个特殊问题，其中代码库包含两个名称相同的文件夹，但不同的情况如＆＃39; Form＆＃39;和＆＃39;形式＆＃39;。
以下是该方案： 假设我们有三个系统Linux（区分大小写的文件系统），MAC（不区分大小写）和WINDOWS（不区分大小写）
现在，如果LINUX上有人创建了一个文件夹名FORM，其文件为a.php，b.php，c.php，另一个文件夹名称为form，文件为{{1} }}，a.php，b.php并将其推送到远程仓库
现在，当MAC或WINDOWS上的用户克隆repo时，git在处理来自远程的d.php和FORM时会如何表现，因为MAC和WINDOWS不区分大小写
答案 0 :(得分：7)
您必须真正修复文件名。使用
可能很有用git config core.ignorecase false
以防您想要混合环境。请参阅How do I commit case-sensitive only filename changes in Git?
中的详情答案 1 :(得分：4)
您应该重命名文件夹，以便两个兄弟文件夹永远不会相同（使用不区分大小写的比较）。这将使您的代码库更具可移植性，并且不易出错，因为开发人员不会将一个文件夹与另一个文件夹混淆。
答案 2 :(得分：1)
当处理来自远程的FORM和表单时git会如何表现，因为MAC和WINDOWS不区分大小写
更好，自Git 2.17（2018年第二季度）以来，因为Git会在所有情况下跟踪那些具有不同大小写的文件夹。
之前，同一目录中的“git add”文件，但在不区分大小写的文件系统上拼写不同情况下的目录路径，已损坏
名称哈希数据结构导致了意想不到的结果。
commit c95525e见Ben Peart (benpeart)（2018年2月8日）
（Junio C Hamano -- gitster --于2018年2月27日commit 2ac76d8合并）
中的目录名称
name-hash：正确折叠adjust_dirname_case()更正
adjust_dirname_case()中的指针算法，使其调用find_dir_entry()具有正确的字符串长度。以前传入“
dir1/foo”会传递长度为6而不是正确的4 这导致find_dir_entry()永远不会找到该条目，因此后续的memcpy会将名称折叠到版本，而且正确的案例从未执行过。
答案 3 :(得分：0)
我遇到一个特殊问题，其中代码库包含两个名称相同的文件夹，但不同的情况如＆＃39; Form＆＃39;和＆＃39;形式＆＃39;。
Git是一个基于unix的代码。它区分大小写，所以它允许你在不同的情况下使用相同的名称，因为除了windows之外你不会容忍它。
除了重命名文件夹之外，您无能为力。
此问题甚至在git中引发了一个安全漏洞，允许您存储这样的文件夹：
.GIT
.GIt
http://git-blame.blogspot.com.es/2014/12/git-1856-195-205-214-and-221-and.html
您可以提交并结帐至
.Git/<anything>（或.[gG][iI][tT]的任何排列，.git全部为小写除外）。但是这将覆盖相应的.git / on不区分大小写的文件系统（例如Windows和Mac OS X）。 至于现在你无能为力，你需要有不同的文件夹。