에서 제공하는 정보 git help fetch
중에는 다음과 같은 작은 항목이 있습니다.
-p, --prune
After fetching, remove any remote-tracking branches which no longer exist on the remote.
아마 git fetch -p
당신이 찾고있는 것입니까?
편집 : 좋아, 사실 3 년이 지난 후에도 여전히이 답변에 대해 토론하는 사람들을 위해이 답변을 제시 한 이유에 대한 약간의 정보가 있습니다 ...
먼저 OP는 "원격에 더 이상 있지 않은 원격 지점에서 생성 된 로컬 지점도 제거합니다"라고 말합니다. 이것은 분명하게 가능하지 않습니다git
. 다음은 예입니다.
하자 내가 중앙 서버에 REPO가 있다고, 그것은라는 두 가지를 가지고 A
와 B
. 내 로컬 시스템에 그 REPO를 복제, 내 복제는 지역 심판 (실제적인 지점 아직)라는 것 origin/A
등을 origin/B
. 이제 내가 다음을 수행한다고 가정 해 봅시다.
git checkout -b A origin/A
git checkout -b Z origin/B
git checkout -b C <some hash>
여기서 중요한 사실은 어떤 이유로 든 로컬 리포지토리에서 원래 이름과 다른 이름을 가진 브랜치를 생성하기로 선택했으며, 원래 리포지토리에 아직 (아직) 존재하지 않는 로컬 브랜치를 가지고 있다는 것입니다.
이제하자 내가 모두 제거 말 A
과 B
원격 REPO에 지점을하고 (내 지역의 repo 업데이트 git fetch
내 로컬 심판을 야기 어떤 형태의)을 origin/A
하고 origin/B
사라. 자, 내 지역의 repo는 세 가지 아직,이 A
, Z
등을 C
. 이들 중 어느 것도 원격 저장소에 해당 분기가 없습니다. 그 중 두 가지는 "원격 지사에서 만들어졌습니다". 그러나 B
원산지에 전화 한 지사가 있다는 것을 알고 있어도 알 수있는 방법이 없습니다.Z
에서 생성을B
프로세스에서 이름이 바뀌었기 때문일 수 있습니다. 따라서 실제로 외부 프로세스 기록 분기 출처 메타 데이터 또는 기록을 알고있는 사람이 없으면 세 가지 분기 중 OP가 제거 대상이되는 것을 알 수 없습니다. git
자동으로 유지 관리되지 않는 외부 정보가 없으면git fetch -p
가능한 한 가깝고 OP가 요청한 것을 문자 그대로 시도하는 자동 방법은 너무 많은 분기를 삭제하거나 OP가 그렇지 않은 일부를 놓칠 위험이 있습니다. 삭제하고 싶다.
다른 시나리오도 있습니다. 예를 들어, 세 가지 별도의 분기를 만들어서 origin/A
서로 다른 세 가지 접근 방식을 테스트 한 다음 origin/A
사라지는 것과 같습니다 . 이제 세 가지 분기가 있는데 이름이 모두 일치하지는 않지만에서 생성 origin/A
되었으므로 OPs 질문을 문자 그대로 해석하려면 세 가지를 모두 제거해야합니다. 그러나 신뢰할 수있는 방법을 찾을 수 있다면 바람직하지 않을 수 있습니다 ...