git의 색인에서 파일을 제거하는 방법은 무엇입니까?


355

파일 시스템에서 파일을 제거하지 않고 인덱스에서 파일을 제거하는 방법 (= 준비 영역 = 캐시)?


5
"이전에 그 파일을 원하지 않기 때문에 이전에 있던 항목으로 재설정"또는 "삭제"를 의미합니까?
Andrew Aylett

내 경우에는 파일이 이전에 존재하지 않았기 때문에 동일하다.
hcs42

답변:


504

당신이 원하는 :

git rm --cached [file]

--cached옵션 을 생략 하면 작업 트리에서도 옵션이 삭제됩니다. 준비된 콘텐츠가 분기의 끝 또는 디스크의 파일과 일치하지 않으면 경고 메시지가 표시되므로 git rm보다 약간 안전 git reset합니다. (그렇지 않으면을 추가해야합니다 --force.)


8
예를 들어 실수로 .gitignore로 만들지 않은 일부 빌드 중간체 또는 로컬 구성 파일을 체크인 한 경우에도 효과적입니다. 사용 git rm --cached의 REPO에서 제거 .gitignore, 무대에 관련 파일이나 디렉토리를 추가하고 정상적으로 커밋합니다. 그들은 리포지토리에서 사라지지만 로컬 트리에서 그대로 유지되며 실수로 다시 체크인하지 않습니다.
Ionoclast Brigham

22
또한 커밋하고 푸시 한 후 파일을 리포지토리 (원격)에서 삭제합니다.
powder366

6
인덱스에서 제거하지는 않지만 인덱스에서 삭제 된 것으로 표시합니다.
JotaBe

4
이 대답은 의도 한 결과가 아닌 저장소에서 파일을 제거하기 때문에 (@ powder366이 이미 언급했듯이) 잘못되었을 가능성이 큽니다.
otomo

1
이 솔루션은 저에게 효과적이지 않았습니다. 지정된 파일을 삭제 된 것으로 표시 한 다음 로컬 리포지토리에서 제거합니다.
paiego

134

파일을 제거하거나 수정하지 않고 <file>의 스테이지를 해제해야합니다.

git reset <file>

6
이렇게하면 특정 파일에 대한 최신 변경 사항이 제거되지만 커밋 및 푸시 후에 repo (원격)에 유지됩니다.
powder366

1
이것이 내가 찾던 대답입니다. 을 지정할 필요는 없습니다 HEAD.
Michael Dorst

좋은 점 @MichaelDorst. 생략하도록 답변을 업데이트했습니다 HEAD!
David Underhill

3
git reset HEAD <file> 

색인에서 특정 파일을 제거합니다.

git reset HEAD

인덱싱 된 파일을 모두 제거합니다.


1

워크 플로에 따라, 이것은 명령 줄 솔루션을 알아 내려는 데 거의 도움이되지 않을 정도로 거의 필요하지 않을 수도 있습니다 (어떤 이유로 그래픽 인터페이스없이 작업하지 않는 한).

인덱스 관리를 지원하는 GUI 기반 도구 중 하나를 사용하십시오 (예 :

  • git gui <-Tk 윈도우 프레임 워크를 사용합니다. gitk
  • git cola <-보다 현대적인 GUI 인터페이스

포인트 앤 클릭으로 인덱스 안팎으로 파일을 이동할 수 있습니다. 또한 파일의 일부 (개별 변경)를 선택하거나 인덱스에서 이동하는 기능도 지원합니다.


다른 관점은 어떻습니까? 제안되고 다소 비밀스러운 명령 중 하나를 사용하는 동안 엉망이되면 :

  • git rm --cached [file]
  • git reset HEAD <file>

... 실제로 데이터를 잃어 버리거나 최소한 찾기가 어려울 수 있습니다. 매우 높은 빈도로이 작업을 수행해야하는 경우가 아니라면 GUI 도구를 사용하는 것이 더 안전 할 것 입니다.


색인없이 작업

의견과 투표를 바탕으로 많은 사람들이 항상 색인을 사용한다는 것을 알게되었습니다. 난 아니야 방법은 다음과 같습니다.

  • 전체 작업 사본을 커밋하십시오 (일반적인 경우). git commit -a
  • 몇 개의 파일 만 커밋하십시오. git commit (list of files)
  • 수정 된 파일을 제외하고 모두 커밋 : git commit -a다음을 통해 수정git gui
  • 작업 사본의 모든 변경 사항을 그래픽으로 검토하십시오. git difftool --dir-diff --tool=meld

@ 마틴 : 워크 플로우에 달려 있다고 생각합니다. 내 접근 방식에서는 색인을 직접 사용하지 않습니다. 작업 내용을 저장하고 싶을 때는 전체 커밋을 수행 git commit -a합니다. 이 질문에 답할 때 파일을 색인에 넣는 (이국적인) " 역 체리 선택 "을 수행했기 때문에 커밋하기 전에 파일을 편집하고 싶었습니다. diffs가 익숙한 방식으로 작동하도록 파일을 편집하는 동안 색인에서 파일을 가져 왔습니다.
nobar

내 사용 사례는 매우 좁고 실제로 쓸모가 없었습니다. 분기 전용 파일로 채워진 폴더 추가; 마스터로 전환; 병합; ops, 마스터에 잘못된 폴더 추가, gitignore에 추가 파일은 커밋에서 제거되지 않을 것입니다. 물론 더 나은 솔루션은 바로 사용하는 rm것이지만 지점을 전환해도 무시 된 폴더는 죽이지 않을 것이라고 생각했습니다 . 그러나 ... 나는 나를 위해 충분히 좋은 github "gui based"도구를 사용하고 이것을 지원하지 않는 것을 제외하고 일부 색인 관리를 지원합니다. 좁은 사용을 위해 2 GUI를 사용해야합니까? 여전히 대답에 동의 할 수 없습니다.
cregox

3
이것은 결정적으로 인기가없는 답변입니다. 그러나 나는 내가 제안한 접근법이 일부 사람들에게 적합한 접근법이라고 확신합니다 (자체 포함). 이 도구 중 하나를 사용하여 일년에 몇 번 색인을 조작합니다.
nobar

1
오늘날 프로그래밍 편집기와 IDE는 그래픽 인덱스 조작을 지원할 가능성이 높습니다. 적어도 GitHub의 Atom 은 않습니다.
nobar

1
더 위험한 경우에도 GUI보다 CLI 인터페이스를 선호합니다. 예를 들어 원격 서버에 그러한 도구를 설치할 수 없을 때 길을 잃지 않고 GUI를 사용하지 않고도 git을 사용할 수 있습니다. 이 답변은 완벽하게 유효하며 "의사 엘리트 주의자"공감대를받을 자격이 없습니다.
SidOfc
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.