tl;dr: 올바른 접근 방식은 다음과 같습니다: git rm --cached logs/xx.log, 그런 다음 대상 파일을 무시하고 업데이트 .gitignore하고 마지막으로 git commit -m "We really don't want Git to track this anymore!"

구체적인 이유는 다음과 같습니다.

받아들인 답변은 (일시적인) 목적을 달성할 수 있지만 가장 올바른 접근 방식은 아닙니다. 그렇게 하는 것은 git update-index의 의미를 오해하는 것이며, 그렇게 할 경우 가장 직접적인(바람직하지 않은) 결과는 다음과 같습니다.

1. 모든 팀원은 대상 파일 git update-index --assume-unchanged <PATH>에서 실행해야 합니다. Git이 대상 파일의 변경 사항을 보지 못한 척 하도록 해도 파일 자체는 여전히 Git의 기록에 있으므로 fetch가 실행될 때 팀의 모든 구성원이 대상 파일에 변경 사항을 가져오기 때문입니다. . (그러나 사실 대상 파일은 변경되는 것을 못 본 척하기보다는 Git에 전혀 기록되기를 원하지 않습니다.)

2. 누군가 대상 파일을 변경하고 git update-index --assume-unchanged <PATH> 없이 직접 push하면 최신 코드를 가져온 모든 멤버는 update-index를 다시 실행해야 합니다. 그렇지 않으면 Git은 대상 파일에 대한 변경 사항을 다시 기록하기 시작합니다. 예를 들어, 구성원이 시스템이나 하드 디스크를 변경하고 새 코드 베이스를 복제하는 경우 대상 파일이 여전히 Git 기록에 있으므로 를 잊어버릴 가능성이 높습니다. 🎜>색인 업데이트.

왜 이런 일이 일어나는 걸까요? 답은 Git의 man 페이지에 있습니다.

우선 git update-index의 정의는 다음과 같습니다.

워킹 트리에 있는 파일 내용을 인덱스에 등록(워크스페이스에 있는 파일 내용을 인덱스 영역에 등록)

이 문장의 암시적 의미는 다음과 같습니다. update-index는 무시해야 하는 파일이 아니라 Git 데이터베이스에 기록된 파일을 대상으로 합니다.

그런 다음 --assume-unchanged에 대한 몇 가지 관련 설명을 읽어보세요.

"변경되지 않은 것으로 가정" 비트가 켜져 있으면 Git은 가능한 수정 사항이 있는지 작업 트리 파일 검사를 중지하므로 작업 트리 파일을 변경할 때 Git에게 알리려면 비트를 수동으로 설정 해제해야 합니다. lstat(2) 시스템 호출(예: cifs)이 매우 느린 파일 시스템의 대규모 프로젝트.

대략 다음을 의미합니다.

이 플래그를 적용한 후 Git은 작업 공간 파일에 대한 가능한 변경 사항을 살펴보는 것을 중지하므로 Git이 파일 변경 내용 추적을 다시 시작하려는 것을 알 수 있도록 수동으로 플래그를 재설정해야 합니다. 이는 파일 시스템의 lstat 시스템 호출이 매우 느린 대규모 프로젝트에서 작업할 때 유용할 수 있습니다.

Git는 코드 버전 관리에만 사용되는 것이 아니라 다른 분야의 많은 프로젝트에서도 Git을 사용하는 것으로 알고 있습니다. 예를 들어, 우리 회사의 클라이언트 프로젝트 중 하나는 정밀 부품 도면 문서의 버전 관리와 관련되었으며 Git도 사용했습니다. 한 가지 사용 시나리오는 일부 대용량 파일을 수정하는 것이지만 Git이 파일을 저장할 때마다 파일의 변경 사항을 계산하고 작업 공간을 업데이트해야 합니다. 이러한 지연은 하드 디스크가 느릴 때 매우 분명합니다.

git update-index --assume-unchanged의 실제 사용법은 다음과 같습니다.

1. 큰 파일을 수정하는 경우 git update-index --assume-unchanged Git이 파일 수정 사항을 일시적으로 무시하도록
해야 합니다.
2. 작업이 끝나고 제출할 준비가 되면 플래그를 재설정하세요. git update-index --no-assume-unchanged 따라서 Git은 한 번만 업데이트하면 됩니다.
3. 제출 + 푸시.

또한 문서의 추가 설명에 따르면:

이 옵션은 추적된 파일에서 커밋되지 않은 변경 사항을 무시하는 대략 파일 수준 메커니즘으로 사용할 수도 있습니다(추적되지 않은 파일에 대해 .gitignore가 수행하는 작업과 유사).

이 설명은 두 가지 사실을 알려줍니다.

1. 포스터가 원하는 결과를 얻기 위해 사용할 수는 있지만 세련된 접근 방식은 아닙니다.
2. .gitignore 파일(추적되지 않은 파일의 경우)을 사용하여 동일한 작업을 수행해야 합니다.

발생하는 질문은 다음과 같습니다. .gitignore에 규칙을 추가했는데 효과가 없는 이유는 무엇입니까?

추적되지 않은 파일에서만 사용할 수 있는 .gitignore 파일의 목적을 잘못 이해했기 때문입니다. Git 파일(추가된 이후 추가되거나 커밋된 적이 없는 파일)에 의해 기록되었습니다.

규칙이 적용되지 않는 이유는 해당 .log 파일이 Git에 의해 기록되었기 때문입니다. 따라서 .gitignore은 해당 파일에 대해 완전히 유효하지 않습니다. 이것이 바로 시작 부분의 짧은 대답이 하는 일입니다:

1. Git 데이터베이스에서 파일 추적을 제거합니다.
2. 무시를 적용하려면 해당 규칙을 .gitignore에 작성하세요.
3. 제출 + 푸시.

이렇게 해야 모든 팀원이 부작용 없이 일관성을 유지할 수 있고, 이렇게만 하면 다른 팀원이 파일 변경 사항을 무시하기 위해 추가 작업을 할 필요가 전혀 없습니다.

마지막으로 주의할 점은 git rm --cached 실제 파일이 아닌 추적 상태를 삭제한다는 점입니다. 실제로 원하지 않는 경우 직접 rm+무시+제출할 수도 있습니다.

유지관리된 파일의 경우 gitignore를 추가해도 도움이 되지 않습니다.
다음 명령을 사용하십시오:
git update-index --assume-unchanged logs/*.log
이렇게 하면 제출할 때마다 로그 아래의 파일이 표시되지 않습니다.

자세한 답변을 주세요
.gitignore는 원래 추적되지 않은 파일만 무시할 수 있습니다. 일부 파일이 버전 관리에 포함된 경우 .gitignore 수정은 유효하지 않습니다.
올바른 접근 방식은 복제된 각 웨어하우스에서 특정 파일의 변경 사항을 확인하지 않도록 수동으로 설정하는 것입니다.

또한 git은 동일한 작업을 수행하는 또 다른 제외 방법도 제공합니다. 차이점은 .gitignore 파일 자체가 저장소에 제출된다는 것입니다. 제외해야 하는 공용 파일을 저장하는 데 사용됩니다. 그리고 .git/info/exclude는 로컬에서 제외해야 하는 파일을 여기에 설정합니다. 그는 다른 누구에게도 영향을 미치지 않을 것입니다. 저장소에 제출되지 않습니다.

.gitignore에는 흥미로운 작은 기능도 있습니다. 빈 .gitignore 파일을 자리 표시자로 사용할 수 있습니다. 이는 프로젝트에 대한 빈 로그 디렉터리를 생성해야 할 때 유용합니다. 로그 디렉터리를 만들고 여기에 빈 .gitignore 파일을 넣을 수 있습니다. 이런 방식으로 이 저장소를 복제하면 git이 자동으로 빈 로그 디렉터리를 생성합니다.

로그 파일을 삭제하고 Ingore를 추가한 후 다시 커밋하세요

가장 많은 득표수를 얻은 답변(n͛i͛g͛h͛t͛i͛r͛e͛)이 질문을 전혀 이해하지 못한 것으로 나타났습니다.
대신 @FatGhosta의 답변이 정답입니다

n ͛i ͛ g ͛ h ͛ t ͛i ͛ r ͛e ͛ 방법을 따르면
"파일을 로컬에 유지하면서 기록할 필요가 없는 파일을 git에서 삭제하고 무시합니다.
"커밋할 때 git에 이미 존재하는 파일 무시"
를 달성하는 대신 향후 커밋에서"

실제로 장면은 이렇습니다. 데이터베이스의 링크 정보 같은 구성 파일이 있습니다.
모든 사람의 링크 정보는 반드시 동일하지는 않지만 표준 템플릿을 제공하여 어떻게 해야 하는지 알 수 있습니다. 링크 정보를 입력하세요
그러면 git에 표준 구성 파일을 기록해야 하는 상황이 있는데, 모든 사람이 각자의 특정 상황에 따라 자신이 사용할 링크 정보의 복사본을 구성하지만 해당 파일을 제출하지 않는 경우가 있습니다.
따라서 이 질문에 대한 FatGhosta의 답변이 정답입니다.