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인덱스에서만 파일을 제거하고 resetgit에게 마지막 커밋에서 git 인덱스를 다시로드하도록 지시 하는 수단 입니다.
가능한 한 가지 이유가 더 있습니다 (현재 내 경우에는 사실로 판명 됨). .gitignore파일을 확인하십시오 . 작업하려는 파일의 파일 또는 확장자가 등록되어 .gitignore변경된 파일로 인식되지 않는 이유를 설명 할 수 있습니다.
이 질문에 대한 답이 충분하지 않으므로 몇 가지 추측을하겠습니다.
1) 유형을 수정하기 위해 변경 사항을 숨겼습니다. git stash pop
2) 변경 사항이 있고 커밋 한 경우 커밋을 볼 수 있어야합니다. git log
3) 당신이 어떤 종류의 변경을 git reset --hard했거나, 당신의 변경 사항이 reflog에있을 수 있으며, 입력 한 git reflog --all다음 확인하거나 ref를 찾으면 체리를 선택하십시오.
4) 동일한 저장소를 여러 번 체크 아웃했으며 잘못된 저장소에 있습니다.
이미 논의했듯이 파일은 아마도 "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"플래그에 관계없이 모든 파일의 변경 사항을 추적하도록 강제합니다.
이런 펑키 한 일이 일어났습니다. Eclipse Kepler의 git 플러그인은 .gitignore 폴더에서 모든 프로젝트 폴더를 무시한 것으로 자동 표시했습니다.
내가 메뉴 commit에 도착했을 때 Team, 그들은 모두 무시로 돌아갔습니다. 내가 알 수있는 한, 이것은 부모 프로젝트에서 파생 된 것으로 설정했기 때문입니다. 이 문제를 해결 한 것으로 표시 해제합니다 dervied. 나는 Indigo에서 전에 이것을 본 적이 없습니다. 그것이 도움이되기를 바랍니다.
미친 것처럼 들리지만 때로는 자신이 있다고 생각하더라도 올바른 저장소에 있지 않습니다. 예를 들어, 상위 디렉토리를 이동했지만 텍스트 편집기에서 저장소를 전환하는 것을 잊었을 수 있습니다. 또는 그 반대로 : 텍스트 편집기에서는 올바른 저장소에 있지만 명령 줄에서는 잘못된 저장소에 있습니다. 첫 번째 상황에서는 올바른 파일 에서 편집 하지만 명령 줄에 열려있는 폴더가 아니므로 실제로는 잘못된 파일입니다. 두 번째 상황에서는 실제로 올바른 파일을 편집했지만 명령 줄의 올바른 디렉토리에 있지 않기 때문에 명령 줄 git이 변경 사항을 인식하지 못합니다.
Sublime Text-3 을 사용하는 동안 비슷한 문제가 발생했습니다 . 코드를 새로 변경하고 저장 한 후 git add ./status 명령을 시도했을 때 응답은 "분기가 이미 최신 상태"였습니다. 텍스트 편집기에서 업데이트를 저장하더라도 파일은 실제로 변경되지 않았습니다. 다른 편집기에서 파일을 열고 변경 사항을 저장하면 저에게 효과적이었습니다.
TL; DR; 올바른 저장소에 있습니까?
내 이야기는 약간 웃기지 만 비슷한 시나리오를 가지고있는 누군가와 함께 할 수 있다고 생각해서 여기서 공유했습니다.
사실 내 컴퓨터에, 나는 두 개의 자식 저장소를 가지고 repo1와 repo2이름이 같은 루트 디렉토리에 구성 source. 이 두 저장소는 본질적으로 회사에서 작업하는 두 제품의 저장소입니다. 이제는 표준 지침으로 모든 제품의 소스 코드 디렉토리 구조가 우리 회사에서 정확히 동일하다는 것입니다.
그래서 실현하지 않고 난에 정확히 같은 이름의 파일을 수정 repo2내가 변화했는데 어느 repo1. 그래서 저는 계속 명령 git status을 실행 repo1했고 계속 같은 메시지를주었습니다.
브랜치 마스터
커밋 할 항목이 없음, 작업 디렉토리 정리
30 분 동안. 그런 다음 제 동료는 그것을 독립적 인 눈으로 관찰하고 제가 잘못되었지만 매우 유사한 저장소에 있다는 것을 알게되었습니다. repo1Git으로 전환 하자마자 변경된 파일을 알아 차리기 시작했습니다.
그리 흔한 경우는 아닙니다. 그러나 당신은 결코 알지 못합니다!
WinMerge 도구를 통해 차이점을 전송하여 파일을 변경할 때 Windows에서 이런 일이 발생했습니다. 분명히 WinMerge (적어도 내 컴퓨터에서 구성된 방식)는 때때로 변경되는 파일의 타임 스탬프를 업데이트하지 않습니다.
Windows에서 git status 는 무엇보다도 파일의 타임 스탬프와 파일 크기 변경을 사용하여 파일이 변경되었는지 여부를 결정합니다. 따라서 타임 스탬프가 업데이트되지 않았기 때문에 파일 크기 만 필요했습니다. 불행히도 문제의 파일은 내용이 7.1.2 에서 7.2.0으로 변경된 간단한 버전 파일이었습니다 . 즉, 파일 크기도 변경되지 않았습니다. WinMerge에 의해 변경되고 타임 스탬프가 업데이트되지 않았지만 변경 사항이 git 상태 로 감지 된 후 크기가 다른 다른 파일도 있습니다 .
일반적으로이 문제와 관련하여 먼저 자신이 생각하는 파일을 편집하고 있는지 확인하십시오! 소스 파일 대신 트랜스 파일 된 JavaScript 파일을 편집 할 때이 문제가 발생했습니다 (트랜스 파일 된 버전은 소스 제어를받지 않았습니다).
Visual Studio에서 파일을 편집하면 파일이 저장되지 않은 경우에도 즉시 git 변경 사항에 나열됩니다. 따라서 파일을 수동으로 저장하기 만하면 (현재 표시된 파일의 경우 Ctrl + S, 모든 프로젝트 파일의 경우 Ctrl + Shift + S) git bash가 파일을 선택합니다.
어떤 종류의 파일을 업로드하려고 했습니까? 이제는 CSS 수정 사항을 업로드하는 데 거의 한 시간을 소비합니다. 그러나이 CSS는 스타일 파일에서 컴파일되었으므로 git은 무시했습니다. 스타일 소스를 변경하면 모든 것이 작동했습니다.
도움이 되었기를 바랍니다.
I had this issue. Mine wasn't working because I was putting my files in the .git folder inside my project.
My Git client (Gitg) caused this issue for me. Normal commands that I would usually run weren't working. Even touching every file in the project didn't work.
I found a way to fix it and I'm still not sure what caused it. Copy your project directory. The missing files will show up in the copied directory's git status. Renaming might do the same thing.
Did you move the directory out from under your shell? This can happen if you restored your project from a backup. To fix this, just cd out and back in:
cd ../
cd -
Sometimes depend and by git version and if you forget to do git add ..
To check about your change on repository use always git status that show all untracked and changed files. Because git diff show only added files.
Make sure not to create symlinks (ln -s source dest) from inside of Git Bash for Windows.
It does NOT make symlinks, but does a DEEP copy of the source to the dest
I experienced same behavior as OP on a MINGW64 terminal from Git Bash for Windows (version 2.16.2) to realize that my 'edited' changes actually were in the original directory, and my git bash commands were from within a deep copy that had remained unchanged.
I had the same problem. Turns out I had two copies of the project and my terminal was in the wrong project folder!
Ran into the issue, but it was only two directories and unknown to me was that both those directories ended up being configured as git submodules. How that happened I have no clue, but the process was to follow some of the instructions on this link, but NOT remove the directory (as he does at the end) but rather do git add path/to/dir
try to use git add * then git commit
'Program Tip' 카테고리의 다른 글
| Mercurial에서 git reset --hard HEAD를 어떻게합니까? (0) | 2020.11.01 |
|---|---|
| 'int main () {return (0);의 부동 소수점 예외 (SIGFPE) (0) | 2020.11.01 |
| HTTPS에서만 .htaccess에서 HSTS 헤더를 설정하는 방법 (0) | 2020.11.01 |
| NetBeans 6.8에서 모든 중단 점을 제거하려면 어떻게해야합니까? (0) | 2020.11.01 |
| 메서드 내에서 변수 대신 const를 사용할 때의 이점 (0) | 2020.11.01 |