SourceTree应用程序说，即使对于新克隆的存储库，也未提交更改 – 可能是错误的？
使用Atlassian SourceTree将远程git存储库克隆到本地框中。 即使在工作树中没有真正修改过文件，Atlassian在“未提交的更改”下面立即列出了一堆文件。 每个文件显示相同的行数都被删除和添加，这个计数等于文件中的行数。 这会以某种方式暗示我们正在碰到某种结束问题。
但是，存储库的.gitattribute包含
# Set default behaviour, in case users don't have core.autocrlf set. * text=auto
每GitHub文章处理行结束应明确core.autocrlf真正的存储库。 不过~/.gitconfig包含autocrlf = true 。
如果修改的文件被试图“恢复”回到先前的提交，则不起作用。 相同的文件仍被视为未提交。
版本库已被克隆到多个位置，并确保没有文件在同一path中，以确保SourceTree或git不logging旧文件。
该存储库与Windows，Linux和OSX盒配合使用。 此问题仅在OSX中出现。
在SourceTree / repository / git安装程序中还有什么可能是错误的？
更新＃1，2013年4月20日
由于还有问题，这里是git config --list部分输出。
从SourceTree控制台（OSX）
core.excludesfile=/Users/User/.gitignore_global core.autocrlf=input difftool.sourcetree.cmd=opendiff "$LOCAL" "$REMOTE" difftool.sourcetree.path= mergetool.sourcetree.cmd=/Applications/SourceTree.app/Contents/Resources/opendiff-w.sh "$LOCAL" "$REMOTE" -ancestor "$BASE" -merge "$MERGED" mergetool.sourcetree.trustexitcode=true core.repositoryformatversion=0 core.filemode=true core.bare=false core.logallrefupdates=true core.ignorecase=true core.autocrlf=true
这里是从Windows端相应的输出：
core.symlinks=false core.autocrlf=false color.diff=auto color.status=auto color.branch=auto color.interactive=true pack.packsizelimit=2g help.format=html http.sslcainfo=/bin/curl-ca-bundle.crt sendemail.smtpserver=/bin/msmtp.exe diff.astextplain.textconv=astextplain rebase.autosquash=true http.proxy= core.autocrlf=true core.repositoryformatversion=0 core.filemode=false core.bare=false core.logallrefupdates=true core.symlinks=false core.ignorecase=true core.hidedotfiles=dotGitOnly core.eol=native core.autocrlf=true
和有问题的存储库完整的.gitattributes
# Set default behaviour, in case users don't have core.autocrlf set. * text=auto *.php text *.twig text *.js text *.html text diff=html *.css text *.xml text *.txt text *.sh text eol=lf console text *.png binary *.jpg binary *.gif binary *.ico binary *.xslx binary
我是SourceTree开发人员之一（实际上我开发了Mac版本的产品），所以希望我能有所帮助。
Windows机器在提交时将CRLF转换为LF，在检出时将LF转换为CRLF。 autocrlf确保库中的所有内容都是LF。 我们感兴趣的选项是text = auto ，正如它在文档中所说的那样 ：
当文本设置为“自动”时，该path被标记为自动结束标准化。 如果git判定内容是文本，那么它的行尾就会在登记时被标准化为LF。
所以你在签入时会看到它会说：“嘿，我需要规范这些行尾，因为它们不是LF格式，而是CRLF。 从而修改你的工作副本来完成它所期望的工作。 通常在Mac / Linux上，你不需要规范化，因为一切都在LF中，但是Git会做一个检查，因为你可能已经从以前在Windows上开发的仓库检出，或者在使用CRLF的编辑器而不是LF。
所以简而言之，你可能想要重新提交所有这些文件，因为它们应该是LF格式，但是也要像在文档中所说的那样确保在你的Windows存储库中使用autocrlf = true （编辑，总是为true！） ：
如果您只是想在工作目录中使用CRLF行结束符，则无论您使用的存储库如何，都可以在不更改任何属性的情况下设置configurationvariables“core.autocrlf”。
尽pipe想象之前的引用是为特定的存储库和全局设置autocrlf 。
希望这有一些帮助，如果没有，请随时提出更多的问题！
这里有一个很好的post：行结束： 为什么我应该在Git中使用core.autocrlf = true？
编辑
基于上述的答案，我们需要在这里确定一些事情。
- 你已经在你的
.git/config设置了相关的git选项 - 如果你想保持CRLF行结束，那么设置
autocrlf=true - 如果在签出存储库时不希望自动转换行结束
text（导致所有文件立即处于“已修改”状态），请将text选项unset为未unset。 添加这个选项，如果一个全局的gitconfiguration已经设置为你不想要的值。 - 如果你在一个项目上同时在Windows和Mac上工作，那么最好你有
text=auto，并确保LF在整个板上使用。 这就是为什么像这样的问题蔓延; 因为你的gitconfiguration有所不同，或者因为Windows上的初始项目/ git设置假定当你的Mac采用LF时CRLF。
我仍然无法100％理解它，但是对于我们来说，问题是存储库中.gitattribute文件中的* text=auto 。 我检查了一下，我们肯定有core.autocrlf=true设置在每个可以在Windows PC上为我的用户设置的地方。 我知道这不是一个SourceTree问题，因为TortoiseGit和Windows Git（msysgit）都对这个存储库有相同的“问题”。 真奇怪的行为 – 我会克隆回购一次，立即看到11“不同”的文件，然后我会删除，重新开始，下一个克隆将有14个“不同”的文件。
在存储库的.gitattribute文件中.gitattribute * text=auto修复所有内容。 它几乎就像text=auto不像autocrlf=true一样，如果第一个被设置在.gitattribute文件中，后者被禁用。 但是，这并不是每一个网上指南似乎表明。
刚刚遇到这个问题。 一个新的克隆将拉动几个文件，这些文件不仅是未提交的，而且还有许多真正的新代码。 git reflog没有显示任何内容，这不是一个实际的提交，所以一个分离的HEAD是没有问题的。
经过约一个小时的调查，我们find了原因。 我们的一个* nix开发人员很可能错误地将文件添加到与预期文件夹名称相同但文件大小不同的文件夹中。 * nix环境能够轻松处理这个新文件夹，但Windows（由于其不区分大小写）合并了这两个文件夹。
所以，举个例子，如果你有两个文件夹test和test，每个文件夹里面都有一个file.txt和两个file.txt文件是不一样的，那么Windows实际上会复制/replace其中的一个文件夹克隆文件夹），从而在“全新安装”后直接“更改”文件并在“Test / file.txt”中创build未提交的更改。
例：
test/ --file.txt (with contents of "This is a commit") Test/ --file.txt (with contents of "This is a commit with some changes")
这将始终显示新的未提交的更改，包括在Windows计算机上克隆时在Test / file.txt中添加“有一些更改”一词，而基于nix的计算机没有问题。
这不一定涉及OP的问题，而是直接与标题中的问题有关。 希望能帮助那里的人。
我添加了以下两行到configuration文件。 我做的另一件事是点击“Staged Files”checkbox，然后取消点击它，一切都刷新自己。 祝你好运。
text = auto autocrlf = true
通常在.gitattribute这行：
* text=auto
自动确保Git认为是文本的所有文件都将在存储库中具有规范化（LF）的行结尾，即使当git config core.autocrlf设置为false （默认）时也是如此。 因此Git根据这些规则自动更改文件。
所以你有以下的可能性：
-
假设规范化更改是正确的（只要他们完成了文本文件），并简单地提交它们，例如
$ git diff $ git commit -m "Introduce end-of-line normalization" -a -
从
.gitattribute文件中删除/禁用自动标准化并重置文件， -
删除索引并重新扫描文件，例如
$ rm -v .git/index # Or: git rm --cached -r . $ git reset --hard # Rewrite the Git index. Or: git add -u -
或者，无论你做什么，试着用力（
-f），例如git pull origin -f，git checkout master -f等， - 使用
git命令行代替，因为它可能是一个SourceTree应用程序自己的问题。
请参阅： 处理 GitHub文档中的行结尾 。
