노초코의 주경야독

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

Section 51.1: git reflog 를 이용해서 문제를 발생시킨 rebase 복구하기

아래와 같이 대화형 (interactive) rebase 를 수행하는 상황을 가정해 보자:

git rebase --interactive HEAD~20

이러한 상황에서, 실수로 몇개의 커밋을 squash 하거나 누락 (drop) 시켜 의도치 않게 커밋이 유실된 상태로 rebase 작업이 종료될 수 있다. 이러한 상태에서 복구를 하고자 한다면, git reflog 를 실행한다. 실행 결과로 아래와 유사한 화면이 나타날 것이다:

aaaaaaa HEAD@{0} rebase -i (finish): returning to refs/head/master
bbbbbbb HEAD@{1} rebase -i (squash): Fix parse error
...
ccccccc HEAD@{n} rebase -i (start): checkout HEAD~20
ddddddd HEAD@{n+1} ...
...

이 경우, 가장 아래 표시된 커밋인 ddddddd (혹은 HEAD@{n+1}) 가 rebase 수행 전 브랜치의 마지막 상태를 가리키고 있음을 확인할 수 있다. 따라서, 해당 커밋을 다시 복구하기 위해서는 (실수로 squash 혹은 drop 된 커밋들을 포함한 모든 부모 커밋들까지), 아래와 같이 입력한다:

$ git checkout HEAD@{n+1}

이제 사용자는 해당 커밋으로부터 새로운 브랜치를 git checkout -b [branch] 명령을 통해 생성할 수 있을 것이다. 이와 관련된 더 상세한 정보는 Branching 항목을 참고하라.

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

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

Section 50.2: 기타 GUI 도구들

역주: 아래 항목들은 모두 개별 섹션을 가지고 있었으나 본 게시글에서는 한 페이지에 모두 포함하였습니다.

GitHub Desktop

• 주소: https://desktop.github.com
• 가격: free

Git Kraken

• 주소:https://www.gitkraken.com
• 가격: $60/년 (오픈소스, 교육용, 비영리, 스타트업 혹은 개인적 사용 목적인 경우 무료)
• 플랫폼: Linux, OS X, Windows
• 개발사: Axosoft

SourceTree

• 주소: https://www.sourcetreeapp.com
• 가격: 무료 (계정 등록 필요)
• 플랫폼: OS X 와 Windows
• 개발사: Atlassian

Git Extensions

• 주소: https://gitextensions.github.io
• 가격: 무료
• 플랫폼: Windows

SmartGit

• 주소: http://www.syntevo.com/smartgit/
• 가격: 비 상업용에 한해 무료, 종신 라이센스 99 USD
• 플랫폼: Linux, OS X, Windows
• 개발사: syntevo

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

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

Section 50.1: gitk 와 git-gui

대부분의 경우, Git 설치시에 시각적 도구 (visual tool) 인 gitk 와 git-gui 가 함께 설치될 것이다.

gitk 는 그래픽화된 이력 표시기 (graphical history viewer) 이다. 이 도구는 git log 와 git grep 를 활용하는 강력한 GUI shell 로 생각할 수 있다. 사용자는 이 도구를 이용하여 과거에 있었던 일들을 검색하거나, 프로젝트의 이력을 시각적으로 표시하는 등의 작업을 수행할 수 있다.

Gitk 는 커맨드라인으로부터 실행하는 것이 가장 간단하다. git 저장소 디렉토리로 이동한 이후, 다음과 같이 입력한다:

$ gitk [git log options]

Gitk 는 다양한 커맨드라인상의 옵션들을 받게 되어 있는데, 대부분의 옵션은 툴의 근간이 되는 git log 에 해당하는 동작 수행을 위해 전달되게 되어 있다. 가장 유용하게 사용되는 옵션은 아마도 비단 HEAD 에서만이 아닌 모든 ref 들로부터 접근 가능한 (reachable) 모든 커밋을 표시하게 해주는 --all 옵션일 것이다. Gitk 의 인터페이스는 아래와 같다:

상단에는 git log --graph 의 출력 결과와 유사한 형태가 표시되어 있다; 각 점은 커밋을 나타내며, 점들을 잇는 선은 부모와의 관계를 표현해 주며, ref 들은 색이 들어간 네모로 표시되어 있다. 노란 점은 HEAD 를 나타내며, 빨간 점은 아직 커밋으로 만들어지지 않은 수정사항들을 나타낸다. 화면 하단에는 선택된 커밋에 대한 정보가 표시되어 있다; 주석 (comment) 과 패치 내용이 화면 왼쪽에, 그리고 요약 정보가 오른쪽에 나타나 있다. 상단과 하단 사이에는 history 검색에 사용되는 조작 장치 (control) 들이 배치되어 있다.

브랜치 이름 혹은 커밋 메시지를 마우스 포인터가 가리키는 상황에서 마우스 오른쪽 클릭을 통해 여러가지 git 관련 기능들을 사용할 수 있다. 여를 들어 다른 브랜치를 checkout 하거나 특정 커밋을 cherry-pick 하는 등의 작업은 클릭 한번만으로 간단히 수행할 수 있다.

git-gui 은 반면에, 커밋을 생성하는 데에 초점을 둔 툴이라고 할 수 있다. 이 툴 역시, 커맨드라인으로부터 실행하는 것이 가장 간단하다:

$ git gui

실행시 다음과 같은 화면이 나타날 것이다:

화면 왼쪽 에는 index 에 대한 정보가 나타나 있다; stage 되지 않은 변경사항들은 상단에, stage 된 변경사항들은 하단에 표시되게 된다. 각 파일들 아이콘을 클릭하여 파일 전체를 두 상태간 이동시킬 수도 있고, 파알 이름을 클릭하여 내용 확인을 할 수도 있다.

상단 오른쪽에는 diff view 가 위치되어 있어, 이곳에서 현재 선택된 파일 내의 변경사항들을 확인할 수 있다. 개별 변경사항 조각 (혹은 개별 코드 라인) 들을 이 영역에서 마우스 오른쪽 클릭함으로써 stage 시킬 수 있다.

하단 오른쪽은 메시지 및 실행 영역이다. 텍스트 상자에 메시지를 작성한 후 “Commit” 버튼을 클릭하여 git commit 작업을 수행하는 등의 일들을 처리할 수 있다. “Amend” 라디오 버튼을 선택하여 가장 마지막 커밋을 수정(amend) 할 수도 있는데, 이 경우 “Staged Changes” 영역을 마지막 커밋의 내용으로 갱신하게 된다. 이후 변경사항들을 stage / unstage 하고, 커밋 메시지를 변경한 후, “Commit” 버튼을 눌러 예전 커밋의 내용을 새로운 내용으로 변경할 수 있다.

gitk 와 git-gui 는 작업 지향 (task-oriented) 도구의 좋은 예이다. 각 도구는 특정 목적 (각각 history 확인 및 커밋 작성을 위한) 에 특화되어 만들어 졌으며 해당 목적에 필수적이지 않은 기능들은 모두 생략된 형태를 취하고 있다.

출처: https://git-scm.com/book/en/v2/Git-in-Other-Environments-Graphical-Interfaces

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

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

Section 49.3: 이메일을 통해 패치 발송하기

하나의 프로젝트에 대해 다수의 커밋을 작성한 후 패치셋들을 메일링 리스트 devel@netfilter.org 로 보내고 싶은 경우를 가정해 보자 (여기서는 공식 브랜치명이 git-svn 인 ulogd2 를 예로 든다) . 이러한 경우, 커맨드라인에서 git 저장소 내의 최상위 디렉토리로 이동한 후 아래와 같이 입력한다:

git format-patch --stat -p --raw --signoff --subject-prefix="ULOGD PATCH" -o /tmp/ulogd2/ -n git-svn

git send-email --compose --no-chain-reply-to --to devel@netfilter.org /tmp/ulogd2/

첫번째 명령어는 패치들로부터 /tmp/ulogd2/ 에 변화량 보고가 포함된 일련의 메일들을 생성해 줄 것이며, 두번째 명령어는 해당 패치셋에 대한 메일 서문 (introduction) 작성을 위한 편집기를 실행시켜줄 것이다. 메일 스레드 내에서의 연속된 회신 메일 생성을 피하기 위해서는 아래와 같은 설정을 할 수 있다:

git config sendemail.chainreplyto false

출처

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

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

Section 49.2: git send-email 작성하기

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

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

Section 49.1: Gmail 계정을 통해 git send-email 사용하기

배경설명: 리눅스 커널과 같은 프로젝트에 참여하고자 하는 경우, 커밋을 제출하고 리뷰를 받는 작업은 Pull request 를 생성하는 등의 과정을 거치는 것이 아닌, listserv 에 메일을 보내는 작업을 통해 이루어진다. 이 섹션에서는 Gmail 을 이용하여 git-send email 을 사용하는 방법을 설명한다.

아래의 내용을 사용자의 .gitconfig 파일에 추가한다:

[sendemail]
 smtpserver = smtp.googlemail.com
 smtpencryption = tls
 smtpserverport = 587
 smtpuser = name@gmail.com

그런 이후, 웹 브라우저에서 다음과 같이 실행한다: Google 접속 -> My Account -> Connected Apps & Sites -> Allow less secure apps -> Switch ON

패치셋을 생성하려면 다음과 같이 수행한다:

git format-patch HEAD~~~~ --subject-prefix="PATCH <project-name>"

그런 후, 패치들을 listserv 로 발송한다:

git send-email --annotate --to project-developers-list@listserve.example.com 00*.patch

해당 패치의 업데이트된 버전을 (이 예제에서는 version 2) 생성하고 발송하려면 아래와 같이 수행한다:

git format-patch -v 2 HEAD~~~~ ......
git send-email --to project-developers-list@listserve.example.com v2-00*.patch

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

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

Section 48.8: 작성자별 커밋 갯수의 총 합 출력하기

각 개발자나 기여자들이 특정 저장소에 있어 작성한 커밋들의 총 갯수를 출력하고자 한다면, 간단히 git shortlog 명령을 사용할 수 있다:

git shortlog -s

위 명령 실행 시, 각 작성자의 이름과 해당 작성자의 커밋 수가 표시될 것이다.

추가적으로, 모든 브랜치에 대해 계산된 결과를 확인하고자 하는 경우에는, 명령어에 -all 파라미터를 추가할 수 있다:

git shortlog -s --all

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

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

Section 48.7: 컴퓨터 내에 존재하는 모든 로컬 git 저장소 검색하기

사용자의 컴퓨터 내에 존재하는 모든 git 저장소들의 위치를 나열하고자 한다면 아래와 같은 명령어를 사용할 수 있다.

find $HOME -type d -name ".git"

locate 가 사용 가능한 환경이라면, 아래 명령어가 훨씬 빠른 결과를 출력해 줄 것이다:

locate .git |grep git$

만약 gnu locate 나 mlocate 를 사용중이라면, 아래 명령어는 git 디렉토리에 대한 결과만 출력해 줄 것이다:

locate -ber \\.git$

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