Gitクローンの直後に変更されたファイル
現在、リポジトリに問題があります。Git-fuは通常は良いのですが、この問題を解決できないようです。
このリポジトリのクローンを作成すると、cdがリポジトリに、git statusが変更されたいくつかのファイルを表示します。注：リポジトリーをエディターなどで開いていません。
私はこのガイドに従ってみました： http://help.github.com/dealing-with-lineendings/ ですが、これは私の問題ではまったく役に立ちませんでした。
git checkout -- .を何度も試しましたが、何もしないようです。
私はMacを使用していますが、リポジトリ自体にはサブモジュールはありません。
ファイルシステムはMac上の「ジャーナリングHFS +」ファイルシステムであり、大文字と小文字は区別されません。ファイルは1行で、それぞれ約79KB（そう、あなたは正しいと聞きました）ですので、git diffを見るのは特に役に立ちません。 git config --global core.trustctime falseを行うと聞いたことがありますが、これは、リポジトリが保存されているコンピューターに戻ったときに役立つでしょう。
ファイルシステムの詳細を事実で変更しました！そして、git config --global core.trustctime falseトリックを試してみましたが、あまりうまくいきませんでした。
わかった。他のすべての開発者はUbuntu（私が思う）にいるため、大文字と小文字を区別するファイルシステムを持っています。ただし、私はそうしません（Macを使用しているため）。実際、git ls-tree HEAD <path>を使用してファイルを見ると、すべてのファイルに小文字の双子が含まれていました。
そのうちの1つを整理します。
リポジトリを複製した後、Macでも同じ問題が発生しました。すべてのファイルが変更されたと仮定します。
git config --global core.autocrlf inputを実行した後、すべてのファイルを変更済みとしてマークしていました。修正を探した後、ホームディレクトリにある.gitattributesファイルに遭遇しましたが、これには次のものがありました。
* text=auto
私はそれをコメントアウトし、これからクローン化された他のリポジトリは問題なく動作しました。
git config core.fileMode false
私の場合、この問題を解決しました
https://git-scm.com/docs/git-config
TL; DR;
core.fileMode
Falseの場合、インデックスと作業ツリーの実行可能ビットの違いは無視されます。 FATのような壊れたファイルシステムで役立ちます。 git-update-index（1）をご覧ください。
デフォルトはtrueです。ただし、git-clone（1）またはgit-init（1）は、リポジトリの作成時に適切な場合、core.fileModeをプローブして設定します。
Windowsを使用していると思います。リンクしたGitHubページには詳細が逆になっています。問題は、CR + LFの行末が既にリポジトリにコミットされており、core.autocrlfがどちらかに設定されているためです。 trueまたはinput、Gitは行末をLFに変換したい、[git statusはすべてのファイルが変更されたことを示します。
これがアクセスしたいだけで、関与しないリポジトリである場合、次のコマンドを実行して、実際に解決せずに問題を非表示にすることができます。
git config core.autocrlf false
これが積極的に関与し、変更をコミットできるリポジトリである場合。 CR + LFの代わりにLFを使用するようにリポジトリ内のすべての行末を変更するコミットを行って問題を修正し、それが再び発生しないように対策を講じることができます。将来は。
以下は gitattributesのmanページ から直接取得したもので、クリーンな作業ディレクトリから実行する必要があります。
echo "* text=auto" >>.gitattributes
rm .git/index # Remove the index to force Git to
git reset # re-scan the working directory.
git status # Show files that will be normalized.
git add -u
git add .gitattributes
git commit -m "Introduce end-of-line normalization"
正規化されるべきではないファイルがgit statusに表示される場合は、git add -uを実行する前にテキスト属性を設定解除してください。
manual.pdf -text
逆に、Gitが検出しないテキストファイルでは、手動で正規化を有効にできます。
weirdchars.txt text
以下のコマンドを実行してください。これで問題が解決する場合があります。
# Remove everything from the index.
git rm --cached -r .
# Write both the index and working directory from git's database.
git reset --hard
Visual Studioでは、Gitを使用している場合、.gitignoreおよび.gitattributesファイルを自動生成できます。自動生成された.getattributesファイルには次の行があります。
* text=auto
この行はファイルの上部近くにあります。行の先頭に＃を追加してコメントアウトする必要がありました。それを行った後、物事は期待どおりに動作しました。
この問題は、私の場合のように、異なるfile permissionsからも発生する可能性があります。
新しく複製されたリポジトリ（Windows、Cygwin）：
$ git ls-tree HEAD
100755 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile
↑↑↑
ベアリモートリポジトリ（Linux）：
$ git ls-tree HEAD
100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile
↑↑↑
「なぜ」これが起こるのかをより直接的に指示した答えを追加したかった。
したがって、.gitattributesには* text=auto設定があり、この問題が発生します。
私の場合、GitHubのmasterブランチ上のファイルの末尾は\r\nでした。 \nの末尾でチェックインするために、リポジトリの設定をダイヤルしました。 Gitが何をチェックアウトするのかわかりません。私のLinuxボックス（\n）にネイティブのエンディングでチェックアウトすることになっていますが、\r\nのエンディングでファイルをチェックアウトしたと思います。 Gitは、リポジトリにあるチェックアウトされた\r\nの末尾を見て、\nの設定をチェックインすることを警告するので、文句を言います。したがって、ファイルは「変更される」ことになります。
それは今のところ私の理解です。
同じ問題がありました。 Macでも。 Linuxマシンのリポジトリを見ると、2つのファイルがあることに気付きました。
geoip.datおよびGeoIP.dat
Linuxマシンで廃止されたものを削除し、リポジトリを再度Macにクローンしました。重複がある場合、リポジトリのコピーからプル、コミット、スタッシュ、プルすることができませんでした。
私にとっても同じ問題です。リモートGitリポジトリでは「textField.png」や「textfield.png」のような同じ名前の画像がいくつか表示されましたが、ローカルリポジトリでは表示されませんでした。プロジェクトのコードで使用されていない「textField.png」しか表示できませんでした。
私の同僚のほとんどは ext4 ファイルシステムを使用してUbuntu上にいるのに対して、私はAPFSを使用してMac上にいます。
Sam Elliott の回答のおかげで、解決策は非常に簡単でした。まず、Ubuntuの同僚に、大文字の冗長ファイルバージョンを削除してから、リモートでコミットしてプッシュするように依頼しました。
その後、私は次を実行しました：
# Remove everything from the index.
git rm --cached -r .
# Write both the index and working directory from git's database.
git reset --hard
最後に、これが二度と起こらないように、すべての開発者が自分のGit構成を変更することを決定しました。
# Local Git configuration
git config core.ignorecase = true
または
# Global Git configuration
git config --global core.ignorecase = true
.git/configというファイルを編集します。
Sudo gedit .git/config
または：
Sudo vim .git/config
内容
[core]
repositoryformatversion = 0
filemode = false
bare = false
logallrefupdates = true
[remote "Origin"]
url = [email protected]:DigitalPlumbing/Unicorn-magento.git
fetch = +refs/heads/*:refs/remotes/Origin/*
[branch "master"]
remote = Origin
merge = refs/heads/master
[branch "productapproval"]
remote = Origin
merge = refs/heads/productapproval
filemode=trueをfilemode = falseに変更します。
私も同じ問題を抱えていました。私の場合、リポジトリを複製しましたが、いくつかのファイルがすぐに見つかりませんでした。
これは、ファイルへのパスとWindowsにはファイル名が長すぎることが原因でした。これを解決するには、ファイルへのパスの長さを短くするために、ハードディスクドライブのルートのできるだけ近くでリポジトリを複製します。たとえば、C:\A\GitRepoではなくC:\Users Documents\yyy\Desktop\GitRepoに複製します。
MacOSの新しいバージョンでは、OSのセキュリティ機能が原因である可能性があります。
私が取り組んでいたリポジトリには、*。appをファイルタイプとして持つバイナリファイルがありました。
シリアル化されたデータでしたが、macOSはすべての* .appファイルをアプリケーションとして扱い、このファイルはユーザーによってダウンロードされなかったため、システムはそれを安全ではないと判断し、ファイルができることを確認するcom.Apple.quarantineファイル属性を追加しました実行されません。
しかし、ファイルにこの属性を設定するとファイルも変更されたため、元に戻す方法なしにGit変更セットに表示されました。
$ xattr file.appを実行すると、同じ問題があるかどうかを確認できます。
ファイルを操作する必要がない限り、ソリューションは非常に簡単です。 *.app binaryを.gitattributesに追加するだけです。
ローカルリポジトリを別のフォルダーにコピーすると、多数の変更されたファイルが表示されました。私の回避策は：変更されたファイルを隠し、隠したものを削除した。リポジトリがクリーンになりました。
誰かの助けになる場合に備えて、この問題には別の原因があります。Gitの異なるバージョンです。 Ubuntu 18.04（Bionic Beaver）ボックスでデフォルトのインストールバージョンのGitを使用していて、すべて正常に機能していましたが、Ubuntu 16.04でGitを使用してリポジトリのクローンを作成しようとすると、一部のファイルが修正済みとして表示されていました。
ここでの他の回答はどれも私の問題を解決しませんでしたが、両方のシステムで一致するようにGitのバージョンをアップグレードしても問題は解決しました。
Gitは私のファイル（この場合は.psd）をテキストとして扱っていることがわかりました。 .gitattributesでバイナリタイプに設定することで解決しました。
*.psd binary
インタラクティブなリベースをしようとしていましたが、修正されたファイルがあると主張していたので、今はそれをさせません。私はeverythingをきれいなリポジトリに戻そうとしましたが、何も機能しませんでした。他の答えは役に立たなかった。しかし、これはついにうまくいきました...
git rm -rf the-folder-with-modified-stuff
git ci -m 'WAT'
ブーム！きれいなリポジトリ。問題が解決しました。その後、rebase -iを実行したときに最後のコミットをドロップする必要があり、最終的にすべてが再びクリーンになりました。奇妙な！