노초코의 주경야독

본 문서는 Git Notes for Professionals (라이센스:CC-BY-SA) 를 한글로 번역한 문서입니다. 번역상 오류가 있을 수 있으므로 정확한 내용은 원본 문서를 참고하세요.

Section 9.6: submodule 제거하기

Version > 1.8

아래 명령어를 통해 특정 submodule (예: the_submodule) 을 제거할 수 있다:

$ git submodule deinit the_submodule
$ git rm the_submodule

• git submodule deinit the_submodule 명령은 the_submodule 항목을 .git/config 항목에서 삭제하게 된다. 이는 the_submodule 을 git submodule update 및 git submodule sync, git submodule foreach 명령의 수행 대상에서 제외시키며 로컬의 내용물들을 모두 삭제하게 된다. 또한, 이는 부모 저장소에 있어 변경사항으로 표시되지 않게 된다. git submodule init 과 git submodule update 명령어 수행시 마찬가지로 부모 저장소에 있어 커밋 가능한 변경사항을 야기하지 않으면서도 submodule 내용을 원복시킬 수 있다.
• git rm the_submodule 명령은 work tree 에서 submodule 을 제거해 준다. submodule 의 파일들 뿐만 아니라 .gitmodules 파일에서의 해당 submodule 항목 역시 삭제될 것이다. 만약 git rm the_submodule 명령만이 수행된다면 (git submodule deinit the_submodule 명령 수행 없이), .git/config 파일 내의 submodule 항목은 유지될 것이다.

Version < 1.8

이곳 에서 발췌됨:

1. .gitmodules 파일에서 삭제할 submodule 관련 부분을 삭제한다.
2. git add .gitmodules 명령을 통해 .gitmodules 변경사항을 stage 시킨다
3. .git/config 파일에서 관련 부분을 삭제한다.
4. git rm --cached path_to_submodule (맨 끝에 / 붙이지 않음에 유의) 를 수행한다.
5. rm -rf .git/modules/path_to_submodule 을 수행한다
6. git commit -m "Removed submodule <name>" 명령어로 커밋을 수행한다
7. git 에 의해 추적되지 않도록 (untracked) 변경된 파일들을 삭제한다
8. rm -rf path_to_submodule 을 수행한다

[출처] https://books.goalkicker.com/GitBook/ (CC BY-SA)

본 문서는 Git Notes for Professionals (라이센스:CC-BY-SA) 를 한글로 번역한 문서입니다. 번역상 오류가 있을 수 있으므로 정확한 내용은 원본 문서를 참고하세요.

Section 9.5: submodule 위치 변경하기

Version > 1.8

다음과 같이 수행한다:

$ git mv old/path/to/module new/path/to/module

Version ≤ 1.8

1. .gitmodules 파일을 수정하여 submodule 의 경로를 적절하게 변경한 후, git add .gitmodules 명령어를 통해 index 에 추가한다.

2. 필요한 경우, submodule 이 위치할 새로운 경로의 부모 디렉토리를 생성한다 (mkdir -p new/path/to).

3. 기존 디렉토리 내의 모든 내용물들을 새로운 디렉토리로 이동시킨다 (mv -vi old/path/to/module new/path/to/module).

4. Git 이 새로운 디렉토리를 추적하도록 설정한다 (git add new/path/to).

5. 기존 디렉토리를 git rm --cached old/path/to/module 명령어를 이용해 삭제한다.

6. .git/modules/old/path/to/module 디렉토리를 모든 내용물들과 함께 .git/modules/new/path/to/module 로 이동시킨다.

7. .git/modules/new/path/to/config 파일을 수정하여, 파일 내의 worktree 항목이 새로운 위치를 정확히 가리키고 있는지를 확인한다. 이 예제에서는 worktree = ../../../../../new/path/to/module 이 되어야 할 것이다. 일반적으로 해당 모듈 위치의 깊이에서 두개의 .. 가 추가될 것이다. new/path/to/module/.git 파일도 수정하여, 메인 프로젝트의 새로운 .git 폴더 위치를 정확히 참조하도록 한다. 이 예제에서는 gitdir: ../../../.git/modules/new/path/to/module 이 되어야 할 것이다. 이 시점에서 git status 명령어의 결과는 다음과 같을 것이다:

   # On branch master
   # Changes to be committed:
   # (use "git reset HEAD <file>..." to unstage)
   #
   # modified: .gitmodules
   # renamed: old/path/to/module -> new/path/to/module
   #
   

8. 마지막으로, 변경 사항을 커밋한다.

위 예제는 Axel Beckert 의 Stack Overflow 예제에서 발췌되었다.

[출처] https://books.goalkicker.com/GitBook/ (CC BY-SA)

본 문서는 Git Notes for Professionals (라이센스:CC-BY-SA) 를 한글로 번역한 문서입니다. 번역상 오류가 있을 수 있으므로 정확한 내용은 원본 문서를 참고하세요.

Section 9.4: submodule 로 하여금 특정 브랜치를 추적 (follow) 하도록 하기

submodule 은 항상 특정 SHA1 기반의 커밋을 ("gitlink" 라고 하는, 부모 저장소 index 에 등록된 특별한 항목) check out 하게 되어 있다.

그러나 사용자는 submodule 으로 하여금 해당 submodule 의 원격 저장소의 특정 브랜치의 가장 최신 커밋으로 update 하도록 요청할 수도 있다.

각 submodule 디렉토리로 들어가서 , git checkout abranch --track origin/abranch 및 git pull 을 수행하는 대신, 아래와 같이 간단하게 입력할 수 있다 (부모 저장소에서 수행한다):

git submodule update --remote --recursive

위 명령어 수행시 해당 submodule 의 SHA1 값이 변경될 것이기 때문에, 아래와 같이 해당 값을 커밋하여야 한다:

git add .
git commit -m "update submodules"

이는 submodule 이 다음과 같이 설정되었다고 가정한다:

• 최초에 추적 (follow) 할 브랜치 정보와 함께 추가되었거나:

  git submodule add -b abranch -- /url/of/submodule/repo
  

• (기존에 존재하는 submodule 에 대해) 특정 브랜치를 추적 (follow) 하도록 이후에 설정된 경우:

  cd /path/to/parent/repo
  git config -f .gitmodules submodule.asubmodule.branch abranch
  

[출처] https://books.goalkicker.com/GitBook/ (CC BY-SA)

본 문서는 Git Notes for Professionals (라이센스:CC-BY-SA) 를 한글로 번역한 문서입니다. 번역상 오류가 있을 수 있으므로 정확한 내용은 원본 문서를 참고하세요.

Section 9.3: submodule 추가하기

submodule 을 이용하면 다른 git 저장소를 사용자의 프로젝트에 git 에 의해 추적 관리되는 (tracked) 하나의 폴더 형태로 포함시킬 수 있다:

$ git submodule add https://github.com/jquery/jquery.git

위 명령을 수행한 이후에는 새로이 작성된 .gitmodules 파일을 add 및 commit 하여야 한다; 이 파일을 통해 git은 git submodule update 명령어가 요청되었을 때 어떤 submodule 들을 clone 하여야 할지 알 수 있다.

[출처] https://books.goalkicker.com/GitBook/ (CC BY-SA)

본 문서는 Git Notes for Professionals (라이센스:CC-BY-SA) 를 한글로 번역한 문서입니다. 번역상 오류가 있을 수 있으므로 정확한 내용은 원본 문서를 참고하세요.

Section 9.2: submodule 갱신 (update) 하기

submodule 은 다른 저장소의 특정 커밋을 참조하게 되어있다. 모든 submodule 들에 대해 참조 중인 상태로의 checkout 을 수행하려면, 다음과 같은 명령어를 이용한다.

git submodule update --recursive

가끔씩은 submodule 이 참조 중인 상태를 이용하기보다 원격 저장소에서 가장 최신 상태를 update 해오고 싶을때가 있다. 하나의 명령어를 사용하여 모든 submodule 을 원격 저장소의 가장 최신 상태로 update 하려면 아래와 같이 수행한다.

git submodule foreach git pull <remote> <branch>

혹은, git pull 의 기본 인자를 사용할 수 있다

git submodule foreach git pull

유의할 점은, 위 명령어들은 사용자의 로컬 작업본만을 갱신할 것이라는 점이다. 만약 submodule 디렉토리의 내용이 이 명령으로 인해 변경되었다면, git status 명령으로 확인 시 수정된 것으로 (dirty) 표시될 것이다. 사용자의 저장소에서 새로운 상태를 참조하도록 업데이트 하려면, 현재의 변경사항을 커밋하는 작업이 필요하다:

git add <submodule_directory>
git commit

사용자 저장소의 변경 사항이 git pull 을 수행했을 때 merge conflict 을 유발하는 경우가 종종 있으므로, 많은 경우에 conflict 의 가능성을 줄여주는 git pull --rebase 를 통해 사용자의 변경사항이 가장 최신 커밋 이후에 반영되도록 한다.

git submodule foreach git pull --rebase

하나의 특정 submodule 에 대해서만 최신 상태로 update 하기 위해서는 아래와 같은 명령어를 수행할 수 있다:

git submodule update --remote <submodule_directory>

[출처] https://books.goalkicker.com/GitBook/ (CC BY-SA)

본 문서는 Git Notes for Professionals (라이센스:CC-BY-SA) 를 한글로 번역한 문서입니다. 번역상 오류가 있을 수 있으므로 정확한 내용은 원본 문서를 참고하세요.

Section 9.1: submodule 을 포함하는 git 저장소를 clone 하기

submodule 을 사용하는 저장소를 clone 하는 경우, init 과 함께 update 를 수행이 필요하다.

$ git clone --recursive https://github.com/username/repo.git

위 명령어를 사용하면 해당 저장소가 참조중인 submodule 들을 같이 clone 하여 적절한 경로에 위치시켜 줄 것이다 (submodule 을 포함하는 submodule 역시 함께 처리된다).

이러한 방법은 통상적인 방법으로 clone 을 수행한 직후 git submodule update --init --recursive 명령어를 실행하는 것과 동일한 효과를 갖는다.

[출처] https://books.goalkicker.com/GitBook/ (CC BY-SA)

본 문서는 Git Notes for Professionals (라이센스:CC-BY-SA) 를 한글로 번역한 문서입니다. 번역상 오류가 있을 수 있으므로 정확한 내용은 원본 문서를 참고하세요.

Section 8.6: 하나의 브랜치를 다른 브랜치로 merge 하기

git merge incomingBranch

위 명령어는 incomingBranch 라는 이름의 브랜치를 현재 작업 수행중인 브랜치에 merge 시킨다.

예를 들어, 현재 작업 수행중인 브랜치가 master 라고 한다면, incomingBranch 라는 이름의 브랜치의 내용이 master 브랜치에 merge 될 것이다.

merge 작업은 종종 충돌 (conflict) 을 야기할 수 있으며, 이러한 경우 자동 merge 가 실패했다는 메시지를 볼 수 있을 것이다; conflict 이 일어난 부분을 고친 후 결과를 커밋하도록 한다. 이를 위해서는 conflict 가 발생한 파일을 직접 수정을 해야 하며, 만약 merge 시도 자체를 취소하고 싶다면 아래와 같이 수행한다:

git merge --abort

[출처] https://books.goalkicker.com/GitBook/ (CC BY-SA)

본 문서는 Git Notes for Professionals (라이센스:CC-BY-SA) 를 한글로 번역한 문서입니다. 번역상 오류가 있을 수 있으므로 정확한 내용은 원본 문서를 참고하세요.

Section 8.5: merge 시에 특정 한쪽의 변경사항만 반영하기

merge 작업 중에, git checkout 명령어에 --ours 나 --theirs 옵션을 사용하여 merge 중인 두 브랜치 중 특정 파일에 대해 한 브랜치의 변경사항만을 반영할 수 있다.

$ git checkout --ours -- file1.txt # file1 에 대해 우리의 (ours - merge 를 실행하고 있는 브랜치) 버전을 사용하고, 그들의 (theirs - merge 의 대상이 되는 브랜치) 변경사항은 무효화한다 
$ git checkout --theirs -- file2.txt # file2 에 대해 그들의 (theirs) 버전을 사용하고, 우리의 (ours) 변경사항은 무효화한다

역주: 모든 파일들에 대해 merge 를 수행하되 conflict 이 나는 부분에 대해서만 한쪽의 변경사항을 우선적으로 적용하고 싶다면, git merge -X <ours/theirs> 를 이용할 수 있습니다.

[출처] https://books.goalkicker.com/GitBook/ (CC BY-SA)