노초코의 주경야독

본 문서는 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)

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

Section 8.4: Merge 를 커밋을 생성하여 수행하기

가능한 경우, merge 의 기본 동작은 별도의 커밋을 생성하지 않고 브랜치의 포인터만 업데이트 하는 방식인 fast-forward 를 수행하게 되어 있다. 항상 merge 커밋을 생성하도록 강제하고 싶다면 --no-ff 옵션을 사용한다.

git merge <branch_name> --no-ff -m "<commit message>"

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

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

Section 8.3: 진행중이던 merge 작업 취소하기

merge 작업을 시작한 이후, 진행하고 있던 merge 작업을 중지하고 모든 파일들을 merge 직전의 (pre-merge) 상태로 되돌리고 싶을 수 있다. 이러한 경우에는 --abort 옵션을 사용한다:

git merge --abort

역주: 위 옵션은 merge 가 완료된 이후에는 수행할 수 없으며, merge 시도를 하였지만 merge conflict 이 발생하였을 때 이용하면 편리합니다.

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

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

Section 8.2: 이미 merge 완료된 원격 브랜치들 찾기

이따금씩 모든 변경사항들이 이미 master 브랜치에 merge 되었지만 정리되지 않고 남아있는 브랜치들을 발견할 수 있다.

아래 명령어는 origin 의 master 브랜치가 아니면서 로컬의 master 브랜치와 비교했을 때 merge 되지 않은 고유한 커밋을 가지고 있지 않은 모든 원격 브랜치들을 검색한다.

이는 PR (pull request) 가 이미 master 로 merge 된 이후 원격에서 삭제되지 않은 브랜치들을 검색할 때에 편리하게 이용할 수 있다.

for branch in $(git branch -r) ; do
[ "${branch}" != "origin/master" ] && [ "${branch}" != "->" ] && [ $(git diff master...${branch} | wc -l) -eq 0 ] && echo -e `git show --pretty=format:"%ci %cr" $branch | head -n 1`\\t$branch
done | sort -r

역주: '->' 검사 부분은 원문에는 없었으나 직접 테스트시 에러가 발생하는 것을 발견하여 임의로 추가하였습니다. 또한 현 상태로 실행할 경우 항상 origin/HEAD 도 검출 내역에 표시되나, 이 부분은 따로 수정하지 않았음을 유의하시기 바랍니다.

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

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

Section 8.1: 자동으로 머지가 완료되는 경우

두 브랜치의 커밋들이 서로 충돌하지 (conflict) 않는다면, Git 은 자동으로 두 브랜치를 merge 해줄 것이다:

~/Stack Overflow(branch:master) » git merge another_branch
Auto-merging file_a
Merge made by the 'recursive' strategy.
 file_a | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

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