git이 내 파일이 변경되었음을 인식하지 못하는 이유는 git add가 작동하지 않습니다.

bash를 사용하여 내 파일을 github에 푸시하려고합니다. 그들은 이미 거기에 있고 새 줄과 코드 등으로 최신 버전을 업로드하고 있습니다. 그러나 시도하면 git add다음과 같이 표시 git status됩니다.

브랜치 마스터

커밋 할 항목이 없음, 작업 디렉토리 정리

그리고 내가 사용하는 파일이 방금 수정되었습니다.

한때 내 파일에서 git 인덱스를 '변경되지 않은 것으로 가정'하도록 설정하는 문제가 발생했습니다.

다음을 사용하여 git에게 파일의 변경 사항 무시를 중지하도록 지시 할 수 있습니다.

git update-index --no-assume-unchanged path/to/file

그래도 도움이되지 않는 경우 다른 이상한 경우에는 재설정 으로 충분할 수 있습니다.

실제로 캐시 된 파일을 제거하고 작동하도록 재설정하는 것을 발견했습니다.

git rm --cached path/to/file
git reset path/to/file

git rm --cached만에 수단은 인덱스에서 파일을 제거하고, reset마지막 커밋에서 자식 인덱스를 다시로드 자식 알려줍니다.

.gitignore파일을 확인하십시오 . 파일, 파일 확장자 또는 작업하려는 파일의 경로가의 항목과 일치하는 것을 발견 할 수 있습니다 .gitignore. 이는 해당 파일이 무시되고 변경된 파일로 인식되지 않는 이유를 설명합니다.

비슷한 문제가 생겼을 때도 마찬가지였습니다.

미친 것처럼 들리지만 때로는 자신이 있다고 생각하더라도 올바른 저장소에 있지 않습니다. 예를 들어, 상위 디렉토리를 이동했지만 텍스트 편집기에서 저장소를 전환하는 것을 잊었을 수 있습니다. 또는 그 반대 : 텍스트 편집기에서는 올바른 저장소에 있지만 명령 줄에서는 잘못된 저장소에 있습니다. 첫 번째 상황에서는 올바른 파일 에서 편집 하지만 명령 줄에 열려있는 폴더가 아니므로 실제로는 잘못된 파일입니다. 두 번째 상황에서는 실제로 올바른 파일을 편집했지만 명령 줄의 올바른 디렉토리에 있지 않기 때문에 명령 줄 git이 변경 사항을 인식하지 못합니다.

이미 논의했듯이 파일은 아마도 "assume-unchanged"로 플래그가 지정되었을 것입니다. 이것은 기본적으로 git에게 파일을 수정하지 않을 것임을 알려주므로 변경 사항을 추적 할 필요가 없습니다. 그러나 이것은 여러 파일에 영향을 미칠 수 있으며 큰 작업 공간 인 경우 하나씩 모두 확인하고 싶지 않을 수 있습니다. 이 경우 시도해 볼 수 있습니다. git update-index --really-refresh

문서에 따르면 :

Like --refresh, but checks stat information unconditionally, without regard to the "assume unchanged" setting.

기본적으로 git이 "assume-unchanged"플래그에 관계없이 모든 파일의 변경 사항을 추적하도록 강제합니다.

이 질문에 대한 답이 충분하지 않으므로 몇 가지 추측을하겠습니다.

1) 유형을 수정하기 위해 변경 사항을 숨겼습니다. git stash pop

2) 변경 사항이 있고 커밋 한 경우 커밋을 볼 수 있어야합니다. git log

3) 당신이 어떤 종류의 변경을 git reset --hard했거나, 당신의 변경 사항이 reflog에있을 수 있습니다, git reflog --all당신이 그것을 찾았다면 reflog를 입력 하고 체크 아웃하거나 체리를 선택하십시오.

4) 동일한 저장소를 여러 번 체크 아웃했는데 잘못된 저장소에 있습니다.

이런 펑키 한 일이 일어났습니다. Eclipse Kepler의 git 플러그인은 .gitignore 폴더에서 모든 프로젝트 폴더를 무시한 것으로 자동 표시했습니다.

나는에 도착 할 때 commit온 Team메뉴, 그들은 모든 설정 다시는 무시한다. 내가 알 수있는 한, 이것은 부모 프로젝트에서 파생 된 것으로 설정했기 때문입니다. 이 문제를 해결 한 것으로 표시 해제합니다 dervied. 나는 Indigo에서 이것을 본 적이 없습니다. 그것이 도움이되기를 바랍니다.

TL; DR; 올바른 저장소에 있습니까?

내 이야기는 약간 웃기지 만 비슷한 시나리오를 가지고 있을지도 모르는 누군가와 함께 여기에서 공유 할 수 있다고 생각했습니다.

사실 내 컴퓨터에, 나는 두 개의 자식 저장소를 가지고 repo1와 repo2이름이 같은 루트 디렉토리에 구성 source. 이 두 저장소는 본질적으로 회사에서 작업하는 두 제품의 저장소입니다. 이제는 표준 지침으로 모든 제품의 소스 코드 디렉토리 구조가 회사에서 정확히 동일하다는 것입니다.

그래서 repo2내가 .NET에서 변경해야 할 정확히 동일한 이름의 파일을 수정했다는 사실을 깨닫지 못하고 repo1. 그래서 저는 계속 명령 git status을 실행 repo1했고 계속 같은 메시지를주었습니다.

브랜치 마스터

커밋 할 항목이 없음, 작업 디렉토리 정리

30 분 동안. 그런 다음 제 동료는 그것을 독립적 인 눈으로 관찰하고 제가 잘못되었지만 매우 유사한 저장소에 있다는 것을 알게되었습니다. repo1Git으로 전환하는 순간 변경된 파일을 알아 차리기 시작했습니다.

그리 흔한 경우는 아닙니다. 그러나 당신은 결코 알지 못합니다!

WinMerge 도구를 통해 차이점을 전송하여 파일을 변경할 때 Windows에서 이런 일이 발생했습니다. 분명히 WinMerge (적어도 내 컴퓨터에서 구성된 방식)는 때때로 변경되는 파일의 타임 스탬프를 업데이트하지 않습니다.

Windows에서 git status 는 무엇보다도 파일의 타임 스탬프와 파일 크기 변경을 사용하여 파일이 변경되었는지 여부를 결정합니다. 따라서 타임 스탬프가 업데이트되지 않았기 때문에 파일 크기 만 필요했습니다. 불행히도 문제의 파일은 내용이 7.1.2 에서 7.2.0으로 변경된 단순한 버전 파일이었습니다 . 즉, 파일 크기도 변경되지 않았습니다. WinMerge에 의해 변경되고 타임 스탬프가 업데이트되지 않았지만 변경 사항이 git 상태 로 감지 된 후 크기가 다른 다른 파일도 괜찮습니다.

Sublime Text-3 을 사용하는 동안 비슷한 문제가 발생했습니다 . 코드를 새로 변경하고 저장 한 후 git add ./status 명령을 시도했을 때 응답은 "분기가 이미 최신 상태"였습니다. 텍스트 편집기에서 업데이트를 저장하더라도 파일은 실제로 변경되지 않았습니다. 다른 편집기에서 파일을 열고 변경 사항을 저장하면 저에게 효과적이었습니다.

쉘 아래에서 디렉토리를 이동 했습니까? 백업에서 프로젝트를 복원 한 경우 발생할 수 있습니다. 이 문제를 해결하려면 다음을 수행하십시오 cd.

cd ../
cd -

일반적으로이 문제와 관련하여 먼저 자신이 생각하는 파일을 편집하고 있는지 확인하십시오! 소스 파일 대신 트랜스 파일 된 JavaScript 파일을 편집 할 때이 문제가 발생했습니다 (트랜스 파일 된 버전은 소스 제어를받지 않았습니다).

내 Git 클라이언트 (Gitg)가이 문제를 일으켰습니다. 일반적으로 실행하는 일반 명령이 작동하지 않았습니다. 프로젝트의 모든 파일을 만져도 작동하지 않았습니다.

나는 그것을 고칠 방법을 찾았지만 그 원인이 무엇인지 여전히 잘 모르겠습니다. 프로젝트 디렉토리를 복사하십시오. 누락 된 파일은 복사 된 디렉토리의 git status. 이름 바꾸기도 같은 일을 할 수 있습니다.

문제가 발생했지만 디렉토리가 두 개 뿐이며 두 디렉토리가 모두 git 하위 모듈로 구성되었다는 사실을 알 수 없었습니다. 어떻게 된 일인지 모르겠지만 프로세스는이 링크의 지침 중 일부를 따르고 디렉토리를 제거하지 않고 (마지막 에서처럼)git add path/to/dir

Visual Studio에서 파일을 편집하면 파일이 저장되지 않은 경우에도 즉시 git 변경 사항에 나열됩니다. 따라서 파일을 수동으로 저장하기 만하면 (현재 표시된 파일의 경우 Ctrl + S, 모든 프로젝트 파일의 경우 Ctrl + Shift + S) git bash가 파일을 선택합니다.

어떤 종류의 파일을 업로드하려고 했습니까? 이제는 CSS 수정 사항을 업로드하는 데 거의 한 시간을 소비합니다. 그러나이 CSS는 스타일 파일에서 컴파일되었으므로 git은 무시했습니다. 스타일 소스를 변경하면 모든 것이 작동했습니다.

도움이 되었기를 바랍니다.

때로는 git 버전에 의존하고 잊은 경우 git add ..

저장소의 변경 사항을 확인하려면 항상 git status추적되지 않고 변경된 모든 파일을 표시하는 사용 하십시오. 때문에 git diff쇼에만 추가 된 파일을.

확인 되지 심볼릭 링크 (작성하는 ln -s source destWindows 용 망할 놈의 배쉬의 내부에서 참조).

심볼릭 링크를 만들지는 않지만 소스를 대상으로 DEEP 복사합니다.

Windows 용 Git Bash (버전 2.16.2)의 MINGW64 터미널에서 OP와 동일한 동작을 경험하여 '편집 된'변경 사항이 실제로 원래 디렉터리에 있고 내 git bash 명령이 남아있는 깊은 복사본 내에 있음을 알았습니다. 변하지 않은.

나는 같은 문제가 있었다. 두 개의 프로젝트 복사본이 있고 터미널이 잘못된 프로젝트 폴더에있는 것으로 나타났습니다!

나에게도 일어난 일이며 위에서 언급 한 방법을 시도했지만 아무것도 도움이되지 않았습니다. 그런 다음 해결책은 GUI가 아닌 터미널을 통해 파일을 변경하는 것입니다. 왜 이것이 효과가 있었는지 모르겠지만 효과가 있습니다. 터미널에서 nano를 통해 파일을 편집 한 후 git이 변경된 것으로 인식하고 추가하고 커밋 할 수있었습니다.

나는 여기에 동일한 문제가 있습니다 .VS2015는 내 js 파일 변경 사항을 인식하지 못했고 저장소 설정에서 원격을 제거한 다음 원격 URL 경로를 다시 추가하면 문제가 해결되었습니다.

vi 편집기로 서버에서 패치 파일을 만들 때 비슷한 문제가 발생했습니다. 간격에 문제가있는 것 같습니다. 로컬에서 패치를 푸시했을 때 배포가 적절했습니다.

나는이 문제가 있었다. 내 프로젝트의 .git 폴더에 파일을 저장했기 때문에 내 파일이 작동하지 않았습니다.

제 경우에는 git reset --hard파일을 삭제 하고 빈 폴더를 남겼습니다. 내용을 조사한 후 디렉토리가 비어 있음을 알았습니다.

그러나 git은 빈 폴더를 무시합니다. (수정, git은 내용을 추적하므로 모든 디렉토리를 무시하고 빈 폴더는 내용이 아닙니다.)

git add * 그때 사용하려고git commit