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으로 전환하는 순간 변경된 파일을 알아 차리기 시작했습니다.
그리 흔한 경우는 아닙니다. 그러나 당신은 결코 알지 못합니다!