Git 복제 후 수정 된 것으로 표시되는 파일

현재 리포지토리에 문제가 있으며 Git-fu가 일반적으로 좋지만이 문제를 해결할 수없는 것 같습니다.

그때,이 저장소를 복제 할 때 cd저장소에, git status쇼 여러 파일이 변경한다. 참고 : 편집기 나 다른 곳에서 저장소를 열지 않았습니다.

http://help.github.com/dealing-with-lineendings/ 이 안내서를 따르려고 시도 했지만 문제가 전혀 도움이되지 않았습니다.

나는 git checkout -- .여러 번 시도했지만 아무것도하지 않는 것 같습니다.

저는 Mac을 사용하고 있으며 저장소 자체에는 하위 모듈이 없습니다.

파일 시스템은 Mac에서 "Journaled HFS +"파일 시스템이며 대소 문자를 구분하지 않습니다. 파일은 한 줄로되어 있으며 각각 약 79KB입니다 (예, 잘 들었습니다). 따라서 보는 git diff것이 도움이되지 않습니다. git config --global core.trustctime false도움이 될 수 있는 일에 대해 들었 습니다. 저장소가있는 컴퓨터로 돌아갈 때 시도해 볼 것입니다.

파일 시스템의 세부 사항을 사실로 변경했습니다! 그리고 git config --global core.trustctime false잘 작동하지 않는 트릭을 시도했습니다 .

저장소를 복제 한 후 Mac에서도 동일한 문제가 발생했습니다. 모든 파일이 변경되었다고 가정합니다.

를 실행 한 git config --global core.autocrlf input후에도 여전히 모든 파일이 변경된 것으로 표시되었습니다. 수정 사항을 찾은 후 .gitattributes다음과 같은 홈 디렉토리의 파일을 발견했습니다.

* text=auto

나는 그것을 주석 처리했으며 지금부터 다른 복제 된 저장소는 정상적으로 작동했습니다.

알았어 다른 모든 개발자는 우분투에 있으며 대소 문자를 구분하는 파일 시스템을 가지고 있습니다. 그러나 (나는 Mac에 있기 때문에)하지 않습니다. 실제로 모든 파일은을 사용하여 살펴볼 때 소문자 쌍둥이를 가졌습니다 git ls-tree HEAD <path>.

그것들 중 하나를 정리해 드리겠습니다.

git config core.fileMode false

내 경우 에이 문제를 해결했다.

https://git-scm.com/docs/git-config

TL; DR;

core.fileMode

False 인 경우 인덱스와 작업 트리 간의 실행 비트 차이는 무시됩니다. FAT와 같은 손상된 파일 시스템에 유용합니다. git-update-index (1)를 참조하십시오.

git-clone (1) 또는 git-init (1)이 리포지토리가 생성 될 때 적절한 경우 core.fileMode를 검사하고 설정하는 것을 제외하고 기본값은 true입니다.

나는 당신이 Windows를 사용한다고 가정합니다. 링크 한 GitHub 페이지에 세부 정보가 있습니다. 문제는 CR + LF 줄 끝이 이미 저장소에 커밋되었으며 core.autocrlf 가 true 또는 input으로 설정되어 있기 때문에 Git은 줄 끝을 LF로 변환하려고하므로 git status모든 파일이 변경되었음을 보여줍니다.

액세스하려는 저장소이지만 관련이없는 리포지토리 인 경우 실제로 해결하지 않고 문제를 숨기려면 다음 명령을 실행할 수 있습니다.

git config core.autocrlf false

이 저장소 인 경우 적극적으로 참여하여 변경 사항을 커밋 할 수 있습니다. CR + LF 대신 LF를 사용하도록 저장소의 모든 줄 끝을 변경 한 커밋을 작성하여 문제가 해결 될 수 있습니다. 그런 다음 나중에 다시 발생하지 않도록 조치를 취하십시오.

다음은 gitattributes 매뉴얼 페이지 에서 직접 가져 왔으며 깨끗한 작업 디렉토리에서 수행해야합니다.

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실행하기 전에 text 속성을 설정 해제하십시오 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이 무엇을 체크 아웃하는지 모른다. 내 리눅스 상자 ( \n) 에 네이티브 엔딩으로 체크 아웃해야 하지만 \r\n엔딩으로 파일을 체크 아웃 한 것 같습니다 . Git \r\n은 저장소에 있는 체크 아웃 된 결말을 보고 \n설정 을 체크인 할 것이라고 경고 하기 때문에 불평 합니다 . 따라서 파일은 "수정됩니다".

지금은 내 이해입니다.

나는 같은 문제가 있었다. Mac에서도 가능합니다. Linux 컴퓨터의 저장소를 보면 두 개의 파일이 있음을 알았습니다.

geoip.dat 및 GeoIP.dat

Linux 시스템에서 더 이상 사용되지 않는 것을 제거하고 저장소를 Mac에 다시 복제했습니다. 복제본이있을 때 저장소 사본을 가져 오거나, 커밋하거나, 숨기거나 끌 수 없었습니다.

나에게도 같은 문제입니다. 원격 Git 리포지토리에서 "textField.png"및 "textfield.png"와 같은 이름을 가진 여러 이미지를 볼 수 있지만 로컬 리포지토리에는 없습니다. 프로젝트 코드에서 사용되지 않은 "textField.png"만 볼 수있었습니다.

내 동료의 대부분은 ext4 파일 시스템을 사용하는 Ubuntu 에 있고 APFS를 사용하는 Mac에 있습니다.

Sam Elliott 의 답변 덕분에 솔루션은 매우 간단했습니다. 먼저 우분투의 동료에게 대문자로 중복 파일 버전을 삭제 한 다음 커밋하고 원격으로 푸시하도록 요청했습니다.

그런 다음 다음을 실행했습니다.

# 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 이이 문제의 원인이 될 수 있습니다. 우분투 18.04 (Bionic Beaver) 상자에 기본 설치된 버전의 Git을 사용하고 있었고 모든 것이 잘 작동했지만 우분투 16.04에서 Git을 사용하여 저장소를 복제하려고 할 때 일부 파일이 수정 된 것으로 표시되었습니다.

여기에있는 다른 대답은 내 문제를 해결하지 못했지만 두 시스템에서 일치하도록 Git 버전을 업그레이드하면 문제가 해결되었습니다.