Gitクローンの直後に変更されたファイル

現在、リポジトリに問題があり、私のGit-fuは通常は良いのですが、この問題を解決できないようです。

このリポジトリのクローンを作成cdすると、リポジトリに、git status変更されたファイルがいくつか表示されます。注：リポジトリなどをエディターで開いていません。

私はこのガイドに従って試してみました：http : //help.github.com/dealing-with-lineendings/、これは私の問題でまったく助けになりませんでした。

私はgit checkout -- .何度も試しましたが、何もしないようです。

私はMacを使用していますが、リポジトリ自体にサブモジュールはありません。

ファイルシステムはMacの「ジャーナリングHFS +」ファイルシステムであり、大文字と小文字は区別されません。ファイルは1行で、それぞれ約79 KBです（そう、そうですね、そうですね）git diff。見ることは特に役に立ちません。することについて聞いたgit config --global core.trustctime false役立つかもしれないたことがあります。リポジトリが存在するコンピュータに戻ったときに、これを試します。

ファイルシステムの詳細をファクトで変更しました！そして、git config --global core.trustctime falseうまくいかないトリックを試しました。

リポジトリのクローンを作成した後、Macでも同じ問題が発生しました。すべてのファイルが変更されたと想定されます。

を実行した後git config --global core.autocrlf inputも、すべてのファイルを変更済みとしてマークしていました。修正を探した後.gitattributes、ホームディレクトリにある次のファイルを見つけました。

* text=auto

私はそれをコメントアウトしました、そしてこれからの他のクローンされたリポジトリはすべてうまくいきました。

わかった。他のすべての開発者はUbuntu（私はそう思う）を使用しているため、大文字と小文字を区別するファイルシステムを使用しています。ただし、私はそうしません（Macを使用しているため）。確かに、を使用してそれらを調べたところ、すべてのファイルに小文字のツインがありましたgit ls-tree HEAD <path>。

そのうちの1つを整理してもらいます。

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をfalseに設定する場合を除きます。

あなたは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

この行はファイルの先頭近くにあります。その行の前に＃を追加して、行をコメント化する必要がありました。その後、問題なく動作しました。

この問題は、私の場合のように、ファイルのアクセス許可が異なることからも発生する可能性があります。

新しく複製されたリポジトリ（Windows、Cygwin）：

$ git ls-tree HEAD
100755 blob 8099ea496a2c78d71125d79a05855f60ebf07904    testfile
   ↑↑↑

ベアリモートリポジトリ（Linux）：

$ git ls-tree HEAD
100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904    testfile
   ↑↑↑

これを修正する方法についてはすでに良い答えがあるので、「なぜ」これが起こるのかについてより詳細な回答を追加したかったのです。

だから、.gitattributes持っている* text=autoこの問題の原因となる設定を、。

私の場合、GitHubのマスターブランチにあるファイルには末尾が\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にいることがわかりました。

サムエリオットの回答のおかげで、解決策は非常に簡単でした。まず、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

私も同じ問題を抱えていました。私の場合、リポジトリのクローンを作成したところ、いくつかのファイルがすぐに見つかりませんでした。

これは、ファイルのパスとファイル名がWindowsでは長すぎるために発生しました。この問題を解決するには、リポジトリをできるだけハードディスクドライブのルートの近くにクローンして、ファイルへのパスの長さを短くします。たとえば、C:\A\GitRepoではなくにクローンしC:\Users Documents\yyy\Desktop\GitRepoます。

次のファイルを編集します.git/config。

sudo gedit .git/config

または：

sudo vim .git/config

目次

[core]
    repositoryformatversion = 0
    filemode = false
    bare = false
    logallrefupdates = true

[remote "origin"]
    url = kharadepramod@bitbucket.org: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ます。

macOSの新しいバージョンの場合、これはOSのセキュリティ機能が原因である可能性があります。

私が作業していたリポジトリに、ファイルタイプとして* .appが含まれるバイナリファイルがありました。

これは単なるシリアル化されたデータでしたが、macOSはすべての* .appファイルをアプリケーションとして扱い、このファイルはユーザーによってダウンロードされなかったため、システムはそれを安全ではないと判断com.apple.quarantineし、ファイルを実行できないようにするファイル属性を追加しました。

しかし、この属性をファイルに設定すると、ファイルも変更されたため、元に戻す方法なしでGit変更セットに表示されました。

を実行して、同じ問題があるかどうかを確認できます$ xattr file.app。

ファイルで作業する必要がない限り、解決策は非常に簡単です。に追加*.app binaryするだけ.gitattributesです。

ローカルリポジトリを別のフォルダーにコピーすると、変更されたファイルの束が表示されました。私の回避策は、変更されたファイルを隠しておき、隠し場所を削除したことです。リポジトリはきれいになりました。

Gitがファイル（この場合は.psd）をテキストとして処理していることがわかりました。.gitattributesでバイナリタイプに設定すると解決しました。

*.psd binary

インタラクティブなリベースを実行しようとしていましたが、変更されたファイルがいくつかあるため、現時点では実行できませんでした。クリーンなリポジトリに戻すためにすべてを試しましたが、何もうまくいきませんでした。他の答えはどれも役に立ちませんでした。しかし、これはついにうまくいきました...

git rm -rf the-folder-with-modified-stuff
git ci -m 'WAT'

ブーム！クリーンなリポジトリ。問題が解決しました。それから私は私がやったときに最後のコミットをドロップしなければならず、rebase -iそして最後にすべてが再びきれいになりました。奇妙な！

それが他の誰かを助ける場合に備えて、この問題には別の原因がある可能性があります：Gitの異なるバージョンです。Ubuntu 18.04（Bionic Beaver）ボックスでデフォルトでインストールされたGitのバージョンを使用していて、すべてが正常に機能していましたが、Ubuntu 16.04でGitを使用してリポジトリのクローンを作成しようとすると、一部のファイルが変更されたように表示されました。

ここでの他の回答はどれも私の問題を解決しませんでしたが、両方のシステムで一致するようにGitのバージョンをアップグレードしても問題は解決しました。