서브모듈을 어떻게 제거합니까?

질문자 :R. Martinho Fernandes

Git 하위 모듈을 어떻게 제거합니까?

git submodule rm whatever 할 수 없는 이유가 있습니까?

Git Submodule Tutorial 페이지를 통해 :

하위 모듈을 제거하려면 다음을 수행해야 합니다.

1. .gitmodules 파일에서 관련 섹션을 삭제합니다.
2. .gitmodules 변경 사항을 준비합니다.
   git add .gitmodules
3. .git/config 에서 관련 섹션을 삭제합니다.
4. 작업 트리 및 색인에서 하위 모듈 파일을 제거합니다.
   git rm --cached path_to_submodule (후행 슬래시 없음).
5. 하위 모듈의 .git 디렉토리를 제거합니다.
   rm -rf .git/modules/path_to_submodule
6. 변경 사항을 커밋합니다.
   git commit -m "Removed submodule <name>"
7. 현재 추적되지 않는 하위 모듈 파일을 삭제합니다.
   rm -rf path_to_submodule

참조 : 아래의 대체 단계 .

Community Wiki

git1.8.3 이후 (2013년 4월 22일) :

git submodule init "로 하위 모듈에 관심을 표명하면 "나는 더 이상 이 하위 모듈에 관심이 없습니다"라고 말하는 도자기 방식이 없었습니다.
" git submodule deinit "는 그렇게 하는 방법입니다.

삭제 프로세스에서도 git rm 사용합니다(2013년 10월 git1.8.5 이후).

요약

3단계 제거 프로세스는 다음과 같습니다.

 0. mv a/submodule a/submodule_tmp 1. git submodule deinit -f -- a/submodule 2. rm -rf .git/modules/a/submodule 3. git rm -fa/submodule # Note: a/submodule (no trailing slash) # or, if you want to leave it in your working tree and have done step 0 3. git rm --cached a/submodule 3bis mv a/submodule_tmp a/submodule

설명

rm -rf : 이것은 Daniel Schroeder 의 답변에 언급되어 있으며 Eonil 이 주석 에 요약했습니다.

이렇게 하면 .git/modules/<path-to-submodule>/ 변경되지 않습니다.
따라서 이 방법으로 하위 모듈을 한 번 삭제하고 다시 추가하면 저장소가 이미 손상되었기 때문에 불가능합니다.

---

git rm : 커밋 95c16418 참조 :

현재 git rm "을 사용하면 수퍼 프로젝트의 작업 트리에서 하위 모듈의 작업 트리가 제거되고 인덱스에서 gitlink가 제거됩니다.
.gitmodules 의 하위 모듈 섹션은 그대로 유지됩니다. 이는 이제 제거된 하위 모듈의 남은 부분이며 사용자를 짜증나게 할 수 있습니다( .git/config 의 설정과 달리, 이것은 사용자가 이 하위 모듈에 관심을 보였다는 것을 상기시켜 주어야 합니다. 따라서 나중에 이전 커밋이 체크아웃될 때 다시 채워집니다.

" git rm "이 작업 트리에서 하위 모듈을 제거할 뿐만 아니라 .gitmodules submodule.<submodule name> " 섹션을 제거하고 둘 다 준비하여 사용자를 돕게 하십시오.

---

git submodule deinit : 이 패치 에서 유래했습니다.

" git submodule init "를 사용하여 사용자는 git에게 하나 이상의 하위 모듈에 관심이 있고 " git submodule update "에 대한 다음 호출에서 채워지기를 원한다고 말할 수 있습니다.
그러나 현재 git에게 하위 모듈에 대해 더 이상 신경 쓰지 않고 로컬 작업 트리를 제거하고 싶다고 말할 수 있는 쉬운 방법은 없습니다(사용자가 하위 모듈 내부에 대해 많이 알고 " submodule.$name.url "을 제거하지 않는 한). 작업 트리 자체와 함께 .git/config 에서 설정).

' deinit ' 명령을 제공하여 해당 사용자를 deinit
이것은 . '이 제공된 경우 초기화된 모든 하위 모듈)에 대해 .git/config submodule.<name> 섹션을 제거합니다.
강제하지 않는 한 현재 작업 트리에 수정 사항이 포함되어 있으면 실패합니다.
명령줄에 지정된 하위 모듈의 경우 url 설정을 .git/config 에서 찾을 수 없을 때 불평하지만 그럼에도 불구하고 실패하지는 않습니다.

이것은 (de)초기화 단계( .git/config 및 .git/modules/xxx )가

git1.8.5부터 git rm 은 다음 도 처리합니다.

• .gitmodules 파일에 하위 모듈의 URL을 기록하는 ' add ' 단계: 제거해야 합니다.
• 하위 모듈 특수 항목 ( 이 질문에 설명된 대로): git rm이 인덱스에서 이를 제거합니다.
  git rm --cached path_to_submodule (후행 슬래시 없음)
  그러면 특수 모드 "160000"으로 인덱스에 저장된 해당 디렉토리가 제거되어 하위 모듈 루트 디렉토리로 표시됩니다.

마지막 단계를 잊어버리고 하위 모듈을 일반 디렉토리로 추가하려고 하면 다음과 같은 오류 메시지가 표시됩니다.

 git add mysubmodule/file.txt Path 'mysubmodule/file.txt' is in submodule 'mysubmodule'

---

참고: Git 2.17(2018년 2분기)부터 git submodule deinit는 더 이상 셸 스크립트가 아닙니다.
C 함수에 대한 호출입니다.

Prathamesh Chavan( pratham-pc )의 commit 2e61273 , commit 1342476 (2018년 1월 14일)을 참조하십시오.
^{(2018년 2월 13일 ead8dbe 커밋 에서 Junio C gitster -- gitster -- 병합)}

 git ${wt_prefix:+-C "$wt_prefix"} submodule--helper deinit \ ${GIT_QUIET:+--quiet} \ ${prefix:+--prefix "$prefix"} \ ${force:+--force} \ ${deinit_all:+--all} "$@"

VonC

이 질문에 대한 대부분의 답변은 구식이거나 불완전하거나 불필요하게 복잡합니다.

git 1.7.8 이상을 사용하여 복제된 하위 모듈은 로컬 저장소에 최대 4개의 흔적을 남깁니다. 이 네 가지 흔적을 제거하는 프로세스는 아래 세 가지 명령으로 제공됩니다.

 # Remove the submodule entry from .git/config git submodule deinit -f path/to/submodule # Remove the submodule directory from the superproject's .git/modules directory rm -rf .git/modules/path/to/submodule # Remove the entry in .gitmodules and remove the submodule directory located at path/to/submodule git rm -f path/to/submodule

fvgs

그냥 메모입니다. git 1.8.5.2 이후로 두 가지 명령이 수행됩니다.

 git rm -r the_submodule rm -rf .git/modules/the_submodule

@Mark Cheverton의 대답이 올바르게 지적했듯이 두 번째 줄을 사용하지 않으면 지금은 하위 모듈을 제거하더라도 나머지 .git/modules/the_submodule 폴더는 동일한 하위 모듈이 나중에 다시 추가되거나 교체되는 것을 방지합니다 . 또한 @VonC가 언급했듯이 git rm 은 하위 모듈에서 대부분의 작업을 수행합니다.

--업데이트(2017년 7월 5일)--

명확히 the_submodule 은 프로젝트 내부의 하위 모듈의 상대 경로입니다. 예를 들어, 하위 모듈이 하위 디렉토리 subdir subdir/my_submodule 입니다.

주석 및 기타 답변 에서 올바르게 지적했듯이 두 명령(하위 모듈을 제거하기에 기능적으로 충분하지만) .git/config (2017년 7월 기준) [submodule "the_submodule"] 섹션에 흔적을 남깁니다. 세 번째 명령을 사용하여 제거할 수 있습니다.

 git config -f .git/config --remove-section submodule.the_submodule 2> /dev/null

tinlyx

간단한 단계

1. 구성 항목 제거:
   git config -f .git/config --remove-section submodule.$submodulename
git config -f .gitmodules --remove-section submodule.$submodulename
2. 색인에서 디렉토리 제거:
   git rm --cached $submodulepath
   
3. 저 지르다
4. 사용하지 않는 파일 삭제:
   rm -rf $submodulepath
rm -rf .git/modules/$submodulename

참고: $submodulepath 는 선행 또는 후행 슬래시를 포함하지 않습니다.

배경

git submodule add .gitmodules 에만 추가되지만 git submodule init .git/config 추가됩니다.

따라서 모듈을 제거하고 싶지만 빠르게 복원할 수 있다면 다음을 수행하십시오.

 git rm --cached $submodulepath git config -f .git/config --remove-section submodule.$submodulepath

이것을 스크립트에 넣으면 git rebase HEAD 먼저 git commit 을 수행하는 것이 좋습니다.

또한 Git 하위 모듈을 채울 수 있습니까? 에 대한 답변을 살펴보십시오. .

Community Wiki

권장 사항 외에도 rm -Rf .git/modules/path/to/submodule 해야 했습니다(제 경우에는 포크를 원본으로 교체했습니다)

Mark Cheverton

다음을 사용하여 추가된 하위 모듈을 제거하려면:

 git submodule add blah@blah.com:repos/blah.git lib/blah

운영:

 git rm lib/blah

그게 다야

git의 이전 버전(약 ~1.8.5)의 경우 다음을 사용하십시오.

 git submodule deinit lib/blah git rm lib/blah git config -f .gitmodules --remove-section submodule.lib/blah

Doug

.gitmodules 및 .git/config 에서 항목을 제거하고 기록에서 모듈 디렉토리를 제거해야 합니다.

 git rm --cached path/to/submodule

당신이 git의 메일링 리스트에 글을 쓴다면 아마도 누군가가 당신을 위해 쉘 스크립트를 만들어줄 것입니다.

Carmine Paolino

요약하면 다음과 같습니다.

1. path_to_submodule var 설정(후행 슬래시 없음):

   path_to_submodule=path/to/submodule

2. .gitmodules 파일에서 관련 줄을 삭제합니다.

   git config -f .gitmodules --remove-section submodule.$path_to_submodule

3. .git/config에서 관련 섹션을 삭제합니다.

   git config -f .git/config --remove-section submodule.$path_to_submodule

4. 인덱스에서만 $path_to_submodule을 준비 해제하고 제거합니다(정보 손실 방지).

   git rm --cached $path_to_submodule

5. .gitmodules에 대한 변경 사항 추적

   git add .gitmodules

6. 슈퍼 프로젝트 커밋

   git commit -m "Remove submodule submodule_name"

7. 현재 추적되지 않는 하위 모듈 파일 삭제

   rm -rf $path_to_submodule

   rm -rf .git/modules/$path_to_submodule

luissquall

별칭을 사용하여 다른 사람이 제공한 솔루션을 자동화할 수 있습니다.

 [alias] rms = "!f(){ git rm --cached \"$1\";rm -r \"$1\";git config -f .gitmodules --remove-section \"submodule.$1\";git config -f .git/config --remove-section \"submodule.$1\";git add .gitmodules; }; f"

git config에 넣으면 다음과 같이 할 수 있습니다. git rms path/to/submodule

Charles

.git 포함)였던 폴더를 추가, 커밋 및 푸시했기 때문에 하위 모듈이 실수로 추가된 경우 편집할 .gitmodules .git/config 파일이 없습니다. 이 경우 필요한 것은 다음과 같습니다.

 git rm --cached subfolder git add subfolder git commit -m "Enter message here" git push

FWIW , 나는 또한 git add 를 수행하기 전에 .git 폴더를 제거했습니다.

Oli Studholme

deinit 가 나에게 잘 작동한다는 것을 발견했습니다.

 git submodule deinit <submodule-name> git rm <submodule-name>

자식 문서에서 :

초기화

주어진 하위 모듈의 등록을 취소합니다. 즉, 작업 트리와 함께 .git/config에서 submodule.$name

Damjan Pavlica

이 사이트에서 모든 다양한 답변을 실험한 후 이 솔루션을 찾았습니다.

 #!/bin/sh path="$1" if [ ! -f "$path/.git" ]; then echo "$path is no valid git submodule" exit 1 fi git submodule deinit -f $path && git rm --cached $path && rm -rf .git/modules/$path && rm -rf $path && git reset HEAD .gitmodules && git config -f .gitmodules --remove-section submodule.$path

그러면 하위 모듈을 추가하기 전과 똑같은 상태로 복원됩니다. 여기에 있는 대부분의 답변으로는 불가능했던 하위 모듈을 즉시 다시 추가할 수 있습니다.

 git submodule add $giturl test aboveScript test

이렇게 하면 커밋할 변경 사항이 없는 깨끗한 체크아웃이 가능합니다.

이것은 다음으로 테스트되었습니다.

 $ git --version git version 1.9.3 (Apple Git-50)

udondan

2012년 12월 현재 하고 있는 일(대부분의 답변 결합):

 oldPath="vendor/example" git config -f .git/config --remove-section "submodule.${oldPath}" git config -f .gitmodules --remove-section "submodule.${oldPath}" git rm --cached "${oldPath}" rm -rf "${oldPath}" ## remove src (optional) rm -rf ".git/modules/${oldPath}" ## cleanup gitdir (optional housekeeping) git add .gitmodules git commit -m "Removed ${oldPath}"

Lance Rushing

1. git submodule deinit <path to submodule>
2. .gitmodules 에서 섹션 제거
3. 호출: git rm <path to submodule>
4. 프로젝트에서 제거해야 하는 모듈 파일을 삭제합니다.
5. 삭제된 파일을 git에 추가하고 git add .gitmodules
6. 커밋 및 푸시

Black

내가 한 일은 다음과 같습니다.

1.) .gitmodules 파일에서 해당 섹션을 삭제합니다. 아래 명령을 사용할 수 있습니다.

 git config -f .gitmodules --remove-section "submodule.submodule_name"

2.) .gitmodules 변경 사항 준비

 git add .gitmodules

.git/config 에서 해당 섹션을 삭제합니다. 아래 명령을 사용할 수 있습니다.

 git submodule deinit -f "submodule_name"

4.) gitlink를 제거합니다(후행 슬래시 없음):

 git rm --cached path_to_submodule

5.) .git/modules 정리:

 rm -rf .git/modules/path_to_submodule

6.) 커밋:

 git commit -m "Removed submodule <name>"

7.) 현재 추적되지 않는 하위 모듈 파일 삭제

 rm -rf path_to_submodule

Ishan Liyanage

나는 최근에 많은 유용한 git 관련 명령을 포함하는 git 프로젝트를 찾았습니다. https://github.com/visionmedia/git-extras

설치하고 다음을 입력하십시오.

 git-delete-submodule submodule

그런 다음 일이 완료됩니다. 하위 모듈 디렉토리는 저장소에서 제거되고 여전히 파일 시스템에 존재합니다. git commit -am "Remove the submodule" 과 같이 변경 사항을 커밋할 수 있습니다.

Chien-Wei Huang

나는 한 걸음 더 나아가 요한 Douthat의 조치를 취할하고 있었다 cd 서브 모듈의 디렉토리에 다음 Git 저장소를 제거합니다 :

 cd submodule rm -fr .git

그런 다음 하위 모듈에 대한 이전 참조 없이 상위 Git 리포지토리의 일부로 파일을 커밋할 수 있습니다.

Kyle Clegg

다음은 내가 필요하거나 유용하다고 생각한 4단계입니다(중요한 단계부터).

 git rm -f the_submodule rm -rf .git/modules/the_submodule git config -f .git/config --remove-section submodule.the_submodule git commit -m "..."

이론적으로 1단계의 git rm 이 처리해야 합니다. 바라건대, OP 질문의 두 번째 부분은 언젠가 긍정적으로 대답될 수 있습니다(이것은 하나의 명령으로 수행될 수 있음).

그러나 2017년 7월 현재 .git/modules/ 에서 데이터를 제거하려면 2단계 가 필요합니다. 그렇지 않으면 나중에 하위 모듈을 다시 추가할 수 없습니다.

git submodule 명령이 작동하는 것처럼 보이 므로 tinlyx의 답변에서 언급했듯이 git 1.8.5+에 대해 위의 두 단계를 수행할 수 있습니다.

.git/config 파일에서 the_submodule 섹션을 제거합니다. 이것은 완전성을 위해 수행되어야 합니다. (항목은 이전 git 버전에서 문제를 일으킬 수 있지만 테스트할 항목이 없습니다.)

이를 위해 대부분의 답변은 git submodule deinit 사용을 제안합니다. git config -f .git/config --remove-section 을 사용하는 것이 더 명확하고 덜 혼란스럽다는 것을 알았습니다. git-submodule 문서 에 따르면 git deinit :

주어진 하위 모듈을 등록 해제하십시오 ... 저장소에서 하위 모듈을 제거하고 커밋하려면 대신 git-rm[1] 을 사용하십시오 .

마지막으로 git commit git submodule summary (git 2.7 기준)를 수행할 때 오류가 발생할 수 있습니다.

 fatal: Not a git repository: 'the_submodule/.git' * the_submodule 73f0d1d...0000000:

이것은 2단계 또는 3단계를 수행하는지 여부와 관계가 없습니다.

laser

독자의 이익을 위해 여기에서 요약하고 일이 예상대로 작동하지 않는 경우 수행하는 방법에 대한 단계별 가이드를 제공하려고 합니다. 다음은 git 버전 2.17 이상 에서 하위 모듈을 제거 하는 테스트되고 안전한 방법 입니다.

 submodule="path/to/sub" # no trailing slash! git submodule deinit -- "$submodule" git rm -- "$submodule"

• 이것이 당신을 위해 작동하지 않으면 아래를 참조하십시오.
• 옵션이 없습니다. 위험한 것은 없습니다. 그리고 더 많은 일을 할 생각조차 하지 마십시오!
• Debian Buster 2.20.1 및 Ubuntu 18.04 2.17.1 테스트되었습니다.
• "$submodule" 은 이름을 어디에 둘 것인지를 강조하기 위한 것으로, 공백 등의 주의가 필요합니다.
• Windows의 경우 첫 번째 줄을 무시하고 "$submodule" 을 하위 모듈에 대한 적절하게 지정된 경로의 Windows 방식으로 바꿉니다. (나는 윈도우가 아니다)

경고!

.git 디렉토리 내부를 직접 만지지 마십시오! .git 내부에서 편집하면 어두운 면에 들어갑니다. 무슨 수를 써서라도 떨어져!

그리고 예, 과거에는 git 에 많은 편리한 기능이 git 때문에 이에 대해 git을 비난할 수 있습니다. 하위 모듈을 다시 제거하는 적절한 방법과 같습니다.

git submodule 문서에 매우 위험한 부분이 있다고 생각합니다. $GIT_DIR/modules/<name>/ 직접 제거하는 것이 좋습니다. 내가 이해하기로는 이것은 명백한 잘못일 뿐만 아니라 극도로 위험하고 미래에 큰 골칫거리를 유발합니다! 아래를 참조하십시오.

참고

 git module deinit

에 대한 직접 역이다.

 git module init

하지만

 git submodule deinit -- module git rm -- module

도 상당히 반대입니다

 git submodule add -- URL module git submodule update --init --recursive -- module

일부 명령은 기본적으로 한 가지 이상의 작업을 수행해야 하기 때문입니다.

• git submodule deinit -- module
  • (1) .git/config
• git rm
  • (2) 모듈의 파일을 제거합니다.
  • (3) 따라서 하위 모듈의 하위 모듈을 재귀적으로 제거합니다.
  • (4) .gitmodules
• git submodule add
  • .git/modules/NAME/ 데이터를 가져옵니다.
  • (1) git submodule init 을 수행하므로 .git/config
  • (2) git submodule update 수행하므로 모듈을 비재귀적으로 체크아웃합니다.
  • (4) .gitmodules
• git submodule update --init --recursive -- module
  • 필요한 경우 추가 데이터를 가져옵니다.
  • (3) 서브모듈의 서브모듈을 재귀적으로 체크아웃

엄격하게 대칭을 유지하는 것은 의미가 없기 때문에 이것은 완전히 대칭이 될 수 없습니다. 단순히 두 개 이상의 명령이 필요하지 않습니다. 또한 "데이터 가져오기"는 필요하기 때문에 암시적이지만 캐시된 정보를 제거하는 것은 전혀 필요하지 않고 소중한 데이터를 지울 수 있기 때문에 수행되지 않습니다.

이것은 참으로 새로운 사람들에게 어리둥절하지만 기본적으로 좋은 점입니다. git 은 분명히 하는 일을 하고 올바르게 하며 더 많은 일을 하려고 하지도 않습니다. git 은 또 다른 "Eierlegende Wollmilchsau"("Eierlegende Wollmilchsau"는 "스위스 군용 칼의 사악한 버전"으로 번역됨)가 아닌 신뢰할 수 있는 작업을 수행해야 하는 도구입니다.

나는 "왜하지 않는 말하는 사람들의 불만, 이해 그래서 git 나를 위해 확실한 것을". 여기서의 "명백한"은 관점에 따라 다르기 때문입니다. 각각의 모든 상황에서 신뢰성이 훨씬 더 중요합니다. 따라서 가능한 모든 기술 상황에서 당신에게 분명한 것이 종종 옳은 것은 아닙니다. AFAICS git 은 사회적 경로가 아닌 기술 경로를 따릅니다. (따라서 영리한 이름: git)

이것이 실패하면

위의 명령은 다음으로 인해 실패할 수 있습니다.

• git 이 너무 늙었습니다. 그런 다음 최신 git 사용하십시오. (아래 방법을 참고하세요.)
• 커밋되지 않은 데이터가 있으며 데이터가 손실될 수 있습니다. 그런 다음 먼저 커밋하는 것이 좋습니다.
• git clean 의미에서 깨끗하지 않습니다. 그런 다음 먼저 해당 명령을 사용하여 하위 모듈을 정리합니다. (아래 참조.)
• git 지원하지 않는 작업을 수행했습니다. 그러면 당신은 어두운 면에 있게 되고 일이 추하고 복잡해집니다. (아마도 다른 기계를 사용하면 해결될 것입니다.)
• 아마도 내가 알지 못하는 실패하는 더 많은 방법이있을 것입니다 (나는 단지 일부 git power-user입니다.)

가능한 수정 사항은 다음과 같습니다.

최신 git

머신이 너무 오래된 경우 git submodule deinit 이 없습니다. git 업데이트를 원하지 않거나 업데이트할 수 git 이 있는 다른 시스템을 사용하십시오! git 은 완전히 배포되도록 되어 있으므로 다른 git 을 사용하여 작업을 완료할 수 있습니다.

• workhorse:~/path/to/worktree$ git status --porcelain 은 아무 것도 출력하지 않아야 합니다! 그렇다면 먼저 물건을 정리하십시오!
• workhorse:~/path/to/worktree$ ssh account@othermachine
• othermachine:~$ git clone --recursive me@workhorse path/to/worktree/.git TMPWORK && cd TMPWORK
• 이제 하위 모듈 작업을 수행하십시오.
• othermachine:~/TMPWORK$ git commit . -m . && exit
• workhorse:~/path/to/worktree$ git fetch account@othermachine:TMPWORK/.git
• workhorse:~/path/to/worktree$ git merge --ff-only FETCH_HEAD . 이것이 작동하지 않으면 git reset --soft FETCH_HEAD
• git status 가 다시 깨끗해질 때까지 정리하십시오. 첫 번째 단계 덕분에 이전에 청소를 했으므로 그렇게 할 수 있습니다.

이 othermachine 은 VM이 될 수도 있고 Windows에서 Ubuntu WSL이 될 수도 있습니다. chroot 조차도 (하지만 나는 당신이 루트가 아니라고 가정합니다. 왜냐하면 당신이 root git 으로 업데이트하는 것이 더 쉬워야 하기 때문입니다).

ssh 에 연결할 수 없는 경우 git 저장소를 전송하는 방법이 무궁무진합니다. .git 디렉토리 포함)에 작업 트리를 복사하고 스틱에서 복제할 수 있습니다. 복사본을 복제하여 깨끗한 방식으로 다시 가져옵니다. 하위 모듈이 다른 시스템에서 직접 액세스할 수 없는 경우 PITA일 수 있습니다. 그러나 이에 대한 해결책도 있습니다.

 git config --add url.NEWURLPREFIX.insteadOf ORIGINALURLPREFIX

이 곱셈을 사용할 수 있으며 이는 $HOME/.gitconfig 저장됩니다. 같은 것

 git config --add 'url./mnt/usb/repo/.insteadof' https://github.com/

다음과 같은 URL을 다시 작성합니다.

 https://github.com/XXX/YYY.git

~ 안으로

 /mnt/usb/repo/XXX/YYY.git

이와 같은 git 기능에 익숙해지기 시작하면 쉽습니다.

먼저 물건을 정리하십시오

수동으로 정리하는 것이 좋습니다. 이렇게 하면 잊어버린 일부를 감지할 수 있기 때문입니다.

• git이 저장되지 않은 항목에 대해 불평하면 커밋하고 안전한 곳으로 푸시합니다.
• git이 남은 음식에 대해 불평하면 git git status 및 git clean -ixfd 가 친구입니다.
• rm 및 deinit 옵션을 삼가십시오. git 에 대한 옵션(예: -f )이 좋습니다. 그러나 여기에 왔을 때, 당신은 아마도 submodule 영역에서 그렇게 경험이 많지 않을 것입니다. 그래서 미안한 것보다 안전한 것이 좋습니다.

예시:

 $ git status --porcelain M two $ git submodule deinit two error: the following file has local modifications: two (use --cached to keep the file, or -f to force removal) fatal: Submodule work tree 'two' contains local modifications; use '-f' to discard them $ cd two $ git submodule deinit --all error: the following file has local modifications: md5chk (use --cached to keep the file, or -f to force removal) fatal: Submodule work tree 'md5chk' contains local modifications; use '-f' to discard them $ cd md5chk $ git submodule deinit --all error: the following file has local modifications: tino (use --cached to keep the file, or -f to force removal) fatal: Submodule work tree 'tino' contains local modifications; use '-f' to discard them $ cd tino $ git status --porcelain ?? NEW $ git clean -i -f -d Would remove the following item: NEW *** Commands *** 1: clean 2: filter by pattern 3: select by numbers 4: ask each 5: quit 6: help What now> 1 Removing NEW $ cd ../../.. $ git status --porcelain $ git submodule deinit two Cleared directory 'two' Submodule 'someunusedname' (https://github.com/hilbix/src.git) unregistered for path 'two'

submodule deinit -f 필요하지 않습니다. 물건이 깨끗하다면 git clean 의미에서. 또한 git clean -x 는 필요하지 않습니다. git submodule deinit 이 무시되는 추적되지 않은 파일을 무조건 제거한다는 것을 의미합니다. 이것은 일반적으로 원하는 것이지만 잊지 마십시오. 때로는 다시 계산하는 데 몇 시간에서 며칠이 걸리는 캐시된 데이터와 같이 무시된 파일이 소중할 수 있습니다.

$GIT_DIR/modules/<name>/ 제거하지 않는 이유는 무엇입니까?

아마도 사람들은 나중에 문제가 발생할 것을 두려워하기 때문에 캐시된 저장소를 제거하기를 원할 것입니다. 이것은 사실이지만 그 "문제"에 부딪치는 것이 그것을 해결하는 올바른 방법입니다! 수정이 쉽고 올바르게 수행되기 때문에 오래오래 행복하게 살 수 있습니다. 이렇게 하면 데이터를 직접 제거할 때보다 더 번거로운 문제를 피할 수 있습니다.

예시:

 mkdir tmptest && cd tmptest && git init && git submodule add https://github.com/hilbix/empty.git two && git commit -m . && git submodule deinit two && git rm two && git commit -m . && git submodule add https://github.com/hilbix/src.git two

마지막 줄은 다음 오류를 출력합니다.

 A git directory for 'two' is found locally with remote(s): origin https://github.com/hilbix/empty.git If you want to reuse this local git directory instead of cloning again from https://github.com/hilbix/src.git use the '--force' option. If the local git directory is not the correct repo or you are unsure what this means choose another name with the '--name' option.

왜 이 오류가 발생합니까? 때문에 .git/modules/two/ 이전부터 채워했다 https://github.com/hilbix/empty.git 지금은 다른 일에서 다시 채워해야한다, 즉 https://github.com/hilbix/src.git . https://github.com/hilbix/empty.git 에서 다시 채우면 이것을 볼 수 없습니다.

지금 무엇을 할까요? 글쎄, 말한대로 정확히하십시오! --name someunusedname 사용

 git submodule add --name someunusedname https://github.com/hilbix/src.git two

.gitmodules 다음과 같습니다.

 [submodule "someunusedname"] path = two url = https://github.com/hilbix/src.git

ls -1p .git/modules/ 제공

 someunusedname/ two/

당신이 가지를 전환 할 수 있습니다 미래에이 방법 / 앞뒤로 커밋으로 인해 다시 어떤 문제에 얻을하지 않습니다 two/ 두 개의 서로 다른 (그리고 아마도 호환되지 않는) 상류 저장소를 가진. 그리고 가장 좋은 점은 둘 다 로컬로 캐시에 보관할 수 있다는 것입니다.

• 이것은 당신에게만 해당되는 것이 아닙니다. 저장소를 사용하는 다른 모든 사람들에게도 마찬가지입니다.
• 그리고 당신은 역사를 잃지 않습니다. 이전 하위 모듈의 최신 버전을 푸시하는 것을 잊은 경우 로컬 복사본을 입력하고 나중에 할 수 있습니다. 누군가가 일부 하위 모듈을 푸시하는 것을 잊는 것은 매우 일반적입니다(이것은 신규 사용자를 위한 PITA이기 때문에 git 익숙해질 때까지).

--name 옵션을 사용하지 않기 때문에 두 개의 다른 체크아웃이 서로 비틀거릴 것입니다. 그렇죠? 따라서 체크아웃을 할 때마다 .git/modules/<module>/ 디렉토리를 계속해서 제거해야 할 수도 있습니다. git bisect 같은 것을 사용하기 어렵게 만듭니다.

따라서 이 모듈 디렉토리를 자리 표시자로 유지해야 하는 매우 기술적인 이유가 있습니다. .git/modules/ 아래의 항목을 제거하도록 권장하는 사람들은 더 잘 알지 못하거나 이러한 하위 모듈 비호환성을 가로지르는 경우 git bisect 와 같은 강력한 기능을 사용하는 것이 거의 불가능하게 만든다는 사실을 잊어버렸습니다.

추가 이유는 위에 나와 있습니다. ls 보세요. 거기에 무엇이 보이나요?

글쎄, 모듈 two/ .git/modules/two/ 아래에 있지 않고 .git/modules/someunusedname/ ! 그래서 git rm $module; rm -f .git/module/$module 이 완전히 잘못되었습니다! 제거할 올바른 항목을 찾으 module/.git 또는 .gitmodules 를 참조해야 합니다!

따라서 대부분의 다른 답변이 이 위험한 함정에 빠질 뿐만 아니라 매우 인기 있는 git 확장에도 이 버그가 있습니다 ( 현재 수정됨 )! 따라서 정확히 하지 않는 경우 .git/ 디렉토리를 계속 사용하는 것이 좋습니다.

그리고 철학적 관점에서 역사를 지우는 것은 항상 잘못된 것입니다! 평소와 같이 양자역학을 제외하고 는 완전히 다른 것입니다.

참고로 아마 짐작하셨겠지만 hilbix 는 제 GitHub 계정입니다.

Tino

방금 .submodule(정확한 이름을 잊어버렸음) 숨김 파일을 찾았습니다. 목록이 있습니다. 그런 식으로 개별적으로 지울 수 있습니다. 1개밖에 없어서 삭제했습니다. 간단하지만 하위 모듈에 연결된 것이 있는지 모르기 때문에 Git을 엉망으로 만들 수 있습니다. libetpan의 일반적인 업그레이드 문제를 제외하고 지금까지는 괜찮아 보이지만 (바라건대) 관련이 없습니다.

아무도 수동 지우기를 게시하지 않았으므로 추가됨

Stephen J

git 2.17 이상에서는 다음과 같습니다.

 git submodule deinit -f {module_name} git add {module_name} git commit

Albert Tobac

git v2.7.4에서는 간단한 3단계가 제대로 작동했습니다.

 git submodule deinit -f -- a/submodule git rm -fa/submodule git commit

Yuriy Pozniak

project dir: ~/foo_project/ submodule: ~/foo_project/lib/asubmodule - - - - - - - - - - - - - - - - - - - - - - - - - run: 1. cd ~/foo_project 2. git rm lib/asubmodule && rm .git/modules/lib/asubmodule && git submodule lib/asubmodule deinit --recursive --force

user257319

방금 하위 모듈을 추가했는데 예를 들어 단순히 잘못된 하위 모듈을 추가했거나 잘못된 위치에 추가했다면 git stash 한 다음 폴더를 삭제하면 됩니다. 이것은 하위 모듈을 추가하는 것이 최근 저장소에서 수행한 유일한 작업이라고 가정합니다.

botbot

요약하면 다음과 같습니다.

path_to_submodule var 설정(후행 슬래시 없음):

 path_to_submodule=path/to/submodule

.gitmodules 파일에서 관련 줄을 삭제합니다.

 git config -f .gitmodules --remove-section submodule.$path_to_submodule

.git/config에서 관련 섹션을 삭제합니다.

 git config -f .git/config --remove-section submodule.$path_to_submodule

인덱스에서만 $path_to_submodule을 준비 해제하고 제거합니다(정보 손실 방지).

 git rm --cached $path_to_submodule

.gitmodules에 대한 변경 사항 추적

 git add .gitmodules

슈퍼 프로젝트 커밋

 git commit -m "Remove submodule submodule_name"

현재 추적되지 않는 하위 모듈 파일 삭제

 rm -rf $path_to_submodule rm -rf .git/modules/$path_to_submodule

참조: 대체 가이드 라인

Rahul Dapke

제거 프로세스를 쉽게 하기 위해 bash 스크립트를 만들었습니다. 또한 저장소에 저장되지 않은 변경 사항이 있는지 확인하고 확인을 요청합니다. os x 에서 테스트되었으며 일반적인 Linux 배포판에서도 작동하는지 여부를 아는 것이 흥미로울 것입니다.

https://gist.github.com/fabifrank/cdc7e67fd194333760b060835ac0172f

Techradar

아래와 같이 bash 스크립트를 사용하여 한 줄 명령 으로 수행해야 하는 경우:

$ cd /path/to/your/repo && /bin/bash $HOME/remove_submodule.sh /path/to/the/submodule

ie remove_submodule.sh $HOME 디렉토리에 bash 스크립트 파일을 만듭니다.

 #!/bin/bash git config -f .gitmodules --remove-section submodule.$1 git config -f .git/config --remove-section submodule.$1 git rm --cached $1 git add .gitmodules git commit -m "Remove submodule in $1" rm -rf $1 rm -rf .git/modules/$1 git push origin $(git rev-parse --abbrev-ref HEAD) --force --quiet

Chetabahana

이것은 나를 위해 일했습니다. 위의 답변은 터미널에서 이것을 보여 주었고 다른 일은 일어나지 않았습니다.

 'fatal: not removing 'demolibapp' recursively without -r'

1. demolibapp 은 제거하려는 내 하위 모듈 이름입니다.
2. git 하위 모듈 deinit demolibapp
3. 자식 rm --캐시된 데모리앱 -r
4. rm -rf .git/modules/demolibapp
5. 자식 추가 --all
6. git commit -m "추가 하위 모듈 제거"
7. 자식 푸시
8. rm -rf 데모리앱

Pooja

최신 git에서는 git 하위 모듈을 제거하는 데 4번의 작업만 필요합니다.

• .gitmodules 에서 해당 항목 제거
• 단계 변경 git add .gitmodules
• 하위 모듈 디렉토리 제거 git rm --cached <path_to_submodule>
• 커밋 git commit -m "Removed submodule xxx"

rashok

출처 : 여기를 클릭하세요

출처 : http:www.stackoverflow.com/questions/1260748/how-do-i-remove-a-submodule