힘내 : 저장소에서 파일을 삭제하지 않고 색인에서 파일을 제거하는 방법
사용할 때
git rm --cached myfile
로컬 파일 시스템에서 삭제되지 않습니다. 이것이 목표입니다. 그러나 이미 파일의 버전을 지정하고 커밋 한 경우 중앙 저장소로 파일을 푸시하고 명령을 사용하기 전에 다른 저장소로 파일을 가져 오면 해당 시스템에서 파일이 삭제됩니다.
파일 시스템에서 파일을 삭제하지 않고 버전 관리에서 파일을 제거하는 방법이 있습니까?
편집 : 명확히, 나는 희망한다.
Git 커밋이 "이 파일 추적을 중지하지만 삭제하지 마십시오"와 같은 의도를 기록 할 수 있다고 생각하지 않습니다.
이러한 의도를 실현하려면 파일을 삭제하는 커밋을 병합하거나 리베이스하는 저장소에서 Git 외부의 개입이 필요합니다.
사본 저장, 삭제 적용, 복원
아마도 가장 쉬운 방법은 다운 스트림 사용자에게 파일 사본을 저장하고 삭제 한 다음 파일을 복원하도록 지시하는 것입니다. 리베이스를 통해 파일을 가져오고 파일을 수정하는 경우 충돌이 발생합니다. 이러한 충돌을 해결하려면 git rm foo.conf && git rebase --continue(충돌 된 커밋이 제거 된 파일 이외의 변경 사항이있는 git rebase --skip경우 ) 또는 (충돌하는 커밋이 제거 된 파일로만 변경된 경우)를 사용하십시오.
삭제 된 커밋을 가져온 후 파일을 추적되지 않은 상태로 복원
이미 삭제 커밋을 가져온 경우 git show 를 사용하여 파일의 이전 버전을 복구 할 수 있습니다 .
git show @{1}:foo.conf >foo.conf
또는 git checkout (William Pursell의 의견에 따라; 색인에서 다시 제거해야합니다!) :
git checkout @{1} -- foo.conf && git rm --cached foo.conf
삭제를 가져온 후 다른 조치를 취한 경우 (또는 분리 된 HEAD로 리베이스를 사용하는 경우) 이외의 조치가 필요할 수 있습니다 @{1}. 그들은 git log -g삭제하기 직전에 커밋을 찾는 데 사용할 수 있습니다 .
한 의견에서,“추적 해제하지만 유지”하려는 파일은 소프트웨어를 실행하는 데 필요한 일종의 구성 파일이라고합니다 (직접 저장소 외부에서).
파일을 '기본'으로 유지하고 수동 / 자동으로 활성화
이 저장소에있는 구성 파일의 내용을 유지하기 위해 계속 완전히 받아 들일 수없는 경우 (예를 들어)에서 추적 파일의 이름을 변경 할 수 있습니다 foo.conf에 foo.conf.default다음 사용자에 지시하려면 cp foo.conf.default foo.conf이름 바꾸기 커밋 적용한 후. 또는 사용자가 이미 리포지토리의 기존 부분 (예 : 스크립트 또는 리포지토리의 내용으로 구성된 다른 프로그램 (예 : Makefile유사))을 사용하여 소프트웨어를 시작 / 배포하는 경우 기본 메커니즘을 시작 / 배포 프로세스 :
test -f foo.conf || test -f foo.conf.default &&
cp foo.conf.default foo.conf
이러한 기본 메커니즘을 사용하면 사용자는 추가 작업을 수행하지 않고도 이름 foo.conf을 바꾸는 커밋을 가져올 수 foo.conf.default있습니다. 또한 나중에 추가 설치 / 저장소를 만드는 경우 구성 파일을 수동으로 복사하지 않아도됩니다.
기록을 다시 쓰려면 수동 개입이 필요합니다…
저장소에 컨텐츠를 유지하는 것이 허용되지 않는 경우 다음과 같이 히스토리에서 컨텐츠를 완전히 제거 할 수 git filter-branch --index-filter …있습니다. 이것은 기록을 다시 작성하는데, 각 브랜치 / 리포지토리에 대해 수동 개입이 필요합니다 ( git rebase 맨 페이지 의“업스트림 리베이스 에서 복구”섹션 참조 ). 구성 파일에 필요한 특수 처리는 다시 쓰기에서 복구하는 동안 수행해야하는 또 다른 단계 일뿐입니다.
- 구성 파일의 사본을 저장하십시오.
- 다시 쓰기에서 복구하십시오.
- 구성 파일을 복원하십시오.
재발을 방지하기 위해 무시
어떤 방법을 사용하든, .gitignore아무도 실수로 git add foo.conf다시 할 수 없도록 저장소 의 파일에 구성 파일 이름을 포함 시키려고 할 수 있습니다 (가능하지만 -f/ 가 필요함 --force). 구성 파일이 둘 이상인 경우 구성 파일을 모두 단일 디렉토리로 '이동'하고 전체를 무시하는 것을 고려할 수 있습니다 ( '이동'함으로써 프로그램이 구성 파일을 찾을 위치를 변경하고 사용자를 가져 오는 것을 의미합니다 (또는 파일을 새 위치로 복사 / 이동하기위한 실행 / 배포 메커니즘) : 파일을 무시할 디렉토리에 mv 파일을 넣고 싶지는 않을 것입니다).
이번 주에 실수로 커밋했을 때 똑같은 문제가 있었지만 공유 저장소에서 빌드 파일을 제거하려고 시도했습니다.
http://gitready.com/intermediate/2009/02/18/temporarily-ignoring-files.html
나를 위해 잘 작동했지만 지금까지 언급하지 않았습니다.
git update-index --assume-unchanged <file>
버전 관리에서 관심있는 파일을 제거하려면 다른 모든 명령을 정상적으로 사용하십시오.
git update-index --no-assume-unchanged <file>
다시 넣고 싶었다면.
편집 : Chris Johnsen 및 KPM의 의견을 참조하십시오.이 기능은 로컬에서만 작동하며 다른 사용자가하지 않은 경우 파일을 버전 제어 상태로 유지합니다. 허용 된 답변은이를 처리하기위한보다 완전하고 올바른 방법을 제공합니다. 이 방법을 사용하는 경우 링크의 참고 사항도 있습니다.
분명히 이것과 관련하여 몇 가지주의 사항이 있습니다. 파일을 직접 추가하면 인덱스에 추가됩니다. 이 플래그를 사용하여 커밋을 병합하면 병합이 정상적으로 실패하여 수동으로 처리 할 수 있습니다.
색인에서 파일을 제거하려면 다음을 사용하십시오.
git reset myfile
This should not affect your local copy or anyone else's.
After doing the git rm --cached command, try adding myfile to the .gitignore file (create one if it does not exist). This should tell git to ignore myfile.
The .gitignore file is versioned, so you'll need to commit it and push it to the remote repository.
git rm --cached remove_file- add file to gitignore
git add .gitignoregit commit -m "Excluding"- Have fun ;)
My solution is to pull on the other working copy and then do:
git log --pretty="format:" --name-only -n1 | xargs git checkout HEAD^1
which says get all the file paths in the latest comment, and check them out from the parent of HEAD. Job done.
The above solutions work fine for most cases. However, if you also need to remove all traces of that file (ie sensitive data such as passwords), you will also want to remove it from your entire commit history, as the file could still be retrieved from there.
Here is a solution that removes all traces of the file from your entire commit history, as though it never existed, yet keeps the file in place on your system.
https://help.github.com/articles/remove-sensitive-data/
You can actually skip to step 3 if you are in your local git repository, and don't need to perform a dry run. In my case, I only needed steps 3 and 6, as I had already created my .gitignore file, and was in the repository I wanted to work on.
To see your changes, you may need to go to the GitHub root of your repository and refresh the page. Then navigate through the links to get to an old commit that once had the file, to see that it has now been removed. For me, simply refreshing the old commit page did not show the change.
It looked intimidating at first, but really, was easy and worked like a charm ! :-)
'Programming' 카테고리의 다른 글
| Ruby : require vs require_relative-Ruby <1.9.2 및> = 1.9.2에서 실행하는 최상의 방법 (0) | 2020.06.08 |
|---|---|
| Android 앱에 어떤 Eclipse 버전을 사용해야합니까? (0) | 2020.06.08 |
| 두 저장소 간의 차이점 얻기 (0) | 2020.06.07 |
| Eclipse가 자원을 자동으로 새로 고칠 수 있습니까? (0) | 2020.06.07 |
| 특정 문자의 문자열을 확인하는 방법은 무엇입니까? (0) | 2020.06.07 |