노초코의 주경야독

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

Section 10.3: 커밋 수정(amend) 하기

사용자의 가장 마지막 커밋이 아직 발행되지 않았다면 (아직 upstream 저장소에 push 하지 않았다면) 해당 커밋을 수정(amend) 할 수 있다.

git commit --amend

위 명령어는 현재 stage 된 변경사항들을 이전 커밋에 추가해 준다.

Note: 이 방법은 잘못 작성된 커밋 메시지를 수정할 때에도 주로 사용된다. 위 명령어 수행시 기본 편집기가 실행되어 (주로 vi / vim / emacs) 이전 커밋 메시지를 변경할 수 있도록 해준다.

커밋 메시지를 명령줄에서 직접 기술하려면:

git commit --amend -m "New commit message"

혹은, 이전 커밋 메시지를 변경 없이 그대로 이용할 수도 있다:

git commit --amend --no-edit

amend 수행시 커밋 날짜는 업데이트 되지만, 작성 날짜 (author date) 는 변경하지 않는다. 이 날짜 정보까지 갱신하기를 원한다면 아래와 같이 입력한다.

git commit --amend --reset-author

커밋의 작성자 (author) 역시 amend 시에 변경 가능하다:

git commit --amend --author "New Author <email@address.com>"

Note: 마지막 커밋을 amend 한다는 것은 이전 커밋을 새로운 커밋으로 완전히 대체하는 작업으로써, 이전 커밋은 브랜치의 history 에서 아예 제거되게 된다. 이러한 특성은 공개된 (public) 저장소와 다른 협력자 (collaborator) 들과 함게하는 브랜치에서 작업할 때 항상 염두에 두어야 한다.

이러한 특성으로 인해, 이미 push 된 커밋을 amend 하게 된다면 이후 push 시에 --force 옵션 기술이 필요하게 된다.

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

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

Section 10.2: 커밋 메시지 잘 작성하기

git log 내역을 살펴보는 사람에게 있어, 각각의 커밋의 목적이나 내용을 쉽게 파악할 수 있는지의 여부는 굉장히 중요하다.

좋은 커밋 메시지는 일반적으로 작업 (task) 이나 문제점 (issue) 관리 시스템상의 번호와 함께 무엇을 어떤 이유로, 어떻게 작업하였는지에 대한 간략한 설명을 포함하게 된다.

다음과 같은 메시지들은 좋은 커밋 메시지의 한 예라고 할 수 있다:

TASK-123: Implement login through OAuth
TASK-124: Add auto minification of JS/CSS files
TASK-125: Fix minifier error when name > 200 chars

반면에, 아래와 같은 메시지들은 그다지 유용한 정보를 포함하고 있지 않다:

fix // 무엇을 고쳤는가?
just a bit of a change // 무엇을 변경하였는가?
TASK-371 // 다른 설명이 전혀 포함되어 있지 않아, 직접 이슈 관리 시스템을 확인해 보아야 커밋 내용에 대한 정보를 얻을 수 있다
Implemented IFoo in IBar // 이러한 수정사항이 왜 필요한가?

커밋 메시지가 적절한 방향으로 작성되었는지를 판단할 수 있는 한가지 방법으로는 아래 문장의 밑줄 부분에 작성한 커밋 메시지를 대입 가능한지 확인해 보는 것이다:

If I add this commit, I will ___ to my repository.

훌륭한 커밋 메시지를 작성하기 위한 7가지 규칙

1. 주제를 기술한 라인과 본문을 작성한 부분 사이에 빈 줄을 하나 배치하여 두 부분을 분리시킨다
2. 주제 기술 라인의 내용이 50자를 넘지 않도록 한다
3. 주제 기술 라인의 첫 글자는 대문자로 표시한다
4. 주제 기술 라인의 끝에 마침표를 찍지 않는다
5. 주제 기술 라인은 명령법 (imperative mood) 을 사용하여 작성한다
6. 본문의 각 라인의 내용은 72자를 기준으로 개행하도록 한다
7. 본문에 기술하는 내용은 "어떻게" 보다는 "무엇을" "왜" 작업하였는지에 초점을 맞추도록 한다

Chris Beam의 블로그의 7가지 규칙 에서 발췌함.

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

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

Section 10.1: 변경사항을 stage 하고 커밋하기

기본 사항

소스 코드를 변경한 이후에 커밋을 하기 위해서는, 해당 변경 사항들을 stage 하여야 한다.

예를 들어, README.md 파일과 program.py 파일을 수정하였다면:

git add README.md program.py

위와 같은 명령을 통해 해당 파일들을 다음에 수행할 커밋에 포함되도록 추가할 수 있다.

그런 다음, stage 된 변경사항을 아래와 같이 커밋한다.

git commit

위 명령 수행시 텍스트 편집기가 실행되는데, 많은 경우 vim 편집기가 뜨게 된다. 만약 vim 사용에 익숙치 않다면, i 키를 눌러 텍스트 삽입 모드로 변경할 수 있으며, 커밋 메시지를 작성한 다음에는 Esc 를 누르고 :wq 를 입력하여 저장 및 종료할 수 있다는 정도만 기억하도록 한다.

텍스트 편집기 실행을 피하고 싶다면, -m 옵션과 함께 커밋 메시지를 직접 입력할 수도 있다.

git commit -m "Commit message here"

커밋 메시지는 종종 특정한 서식을 따르는 경우가 많으므로, 더 자세한 설명을 위해서는 "커밋 메시지 잘 작성하기" 섹션을 참고하도록 한다.

단축 옵션

만약 상당히 많은 수의 파일들을 변경하였다면, 각 파일들을 일일이 나열하는 대신에, 아래와 같이 수행할 수 있다:

git add --all # "git add -a" 와 동일하다

혹은 최상위 디렉토리에서부터 하위 디렉토리까지의 모든 변경사항들을 삭제된 파일들을 제외하고 추가하기를 원한다면 아래와 같이 수행한다:

git add .

혹은 현재 Git 에 의해 추적 (tracked) 되고 있는 파일들만 추가하기를 원한다면 ("update"):

git add -u

이후 만약 필요하다면, stage 된 변경사항들을 아래와 같이 확인한다:

git status # 변경된 파일들의 목록을 출력한다
git diff --cached # stage 된 파일들 내의 stage 된 변경사항들을 보여준다

최종적으로, 변경 사항들을 아래와 같이 커밋한다:

git commit -m "Commit message here"

다른 방법으로, 새로운 파일 생성 없이 기존 파일들에 대해 수정 혹은 삭제만 수행하였다고 하면, git add 와 git commit 을 한 명령어로 합쳐서 수행할 수 있다:

git commit -am "Commit message here"

이 방법은 git add --all 와 동일한 방법으로 변경된 파일들을 stage 시킨다는 점을 유의하라.

민감 정보 관련

커밋에는 비밀번호나 private key 등 어떠한 형태의 민감한 정보도 포함하여서는 안된다. 만약 이러한 일이 발생하여 해당 변경사항이 중앙 서버로 push 되었다면, 해당 민감 정보는 이미 유출외었다고 생각해야 할 것이다.

다른 측면에서는, 이후에 이러한 정보를 제거하는 것이 가능하기도 하다. 쉽고 빠른 방법중의 하나는 "BFG Repo-Cleaner" 를 이용하는 것이다: https://rtyley.github.io/bfg-repo-cleaner/.

bfg --replace-text passwords.txt my-repo.git 명령어 수행 시, passwords.txt 파일에서 암호들을 읽어 해당 암호들을 ***REMOVED*** 문자열로 치환시킨다. 이 작업은 전체 저장소 내의 모든 커밋들을 대상으로 한다.

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

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

Chapter 10: 커밋하기

Git 에서의 커밋은 매 코드상의 변경사항에 대해 작성자의 공헌 정보를 포함함으로써 책임 소재를 명확하게 하며, 특수성과 보안성을 위한 다양한 기능을 제공한다. 이 챕터에서는 Git 에서의 커밋 작업을 적절하게 수행하는 방법들을 설명하고 참고할 수 있는 예제를 제시한다.

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

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