1. Git 이력 이용하기
1.1. Git 로그 살펴보기
$ git log |
Git 출력 결과는 less 를 이용해서 출력되므로, 화면에 보여줄 수 있는 양보다 내용이 많다면, 로그를 스크롤 해서 볼 수 있다.
화면 하단에 콜론(:)이 있다면 출력 결과가 더 남아 있음을 의미한다.
git log의 기본 출력은 4가지 정보를 보여주는데,
각각은 커밋명, 작성자, 날짜, 로그 메시지이다.
처음 3줄에 커밋명과 날짜, 로그 메시지가 표시된다.
다음 커밋명이 나올 때까지의 영역이 로그 메시지다.
-p 옵션을 추가하면 리비전이 생성될 때 변경된 내용을 비교해서 보여준다.
지정한 수의 커밋을 볼 수 있다.
git log -1 는 1개의 커밋만 보여주고,
git log -2 는 2개의 커밋을 보여준다.
git log -10 은 마지막 10개의 로그를 보여준다.
이런 식으로 숫자를 지정할 수 있다.
옵션으로 리비전(커밋명)을 전달하면 해당 리비전으로 시작하는 로그를 볼 수 있다.
$ git log 7b1558c |
전체 커밋명에 7자리의 짧은 커밋명을 사용햇다.
Git 은 사용자가 제공한 어떤 해시명이라도 일치시키려고 시도한다.
물론 커밋명은 고유해야 한다.
대개는 4자리나 5자리의 해시명을 지정해도 일치하지만, 7이나 8자리의 해시명을 이용하면 거의 고유하다고 생각해도 된다.
1.2. 리비전 범위 지정하기
보고자 하는 커밋만 필터링하는 유용한 방법.
지난 5시간 동안의 커밋만 보려면 –since=”5 hours”를 추가하면 된다.
$ git log –since=”5 hours” |
지난 5시간 동안의 커밋을 제외한 더 오래된 커밋만 볼 수도 있다.
$ git log –before=”5 hours”-1 |
--since와 --before 옵션에는, 날짜를 표현할 수 있는 영어식 표현을 지정할 수 있다.
Git은 –since=”24 hours”, --since=”1 minute”, --before=”2008-10.01”과 같은 형식을 모두 이해한다.
2008-10.01 처럼 하이픈(-)과 점(.)을 섞어서 사용해도 날짜를 파싱할 수 있다.
‘오래된-리비전 …최신-리비전’의 형식으로 범위를 지정할 수도 있다.
이때는 항상 오래된 리비전을 먼저 지정해야 Git가 이해한다.
$ git log 18f822e..0bb3dfb |
리비전 18f822e 에서 0bb3dfb 까지를 요청했는데 결과는 그렇지 않다.
이런 종류의 명령은 18f822e 도 포함하리라 생각하기 쉽지만,
Git은 그렇게 동작하지 않고, 18f822e 이후부터 0bb3dfb 까지의 모든 커밋이라고 해석한다.
HEAD는 저장소에서 현재 브랜치의 최신 리비전을 의미한다.
앞의 명령을 다음과 같이 변경할 수 있다.
$ git log 18f822e..HEAD |
Git은 마지막 값을 비워두면, HEAD를 의미한다고 판단하므로 HEAD를 생략해도 된다.
$ git log 18f822e.. |
범위를 입력할 때, 커밋명 대신, 태그명을 사용해도 된다.
태그명을 이용하면 특정 태그 이후에 어떤 변화가 있었는지 확인하거나,
두 태그 사이의 리비전 이력을 보려고 할 때 유용하다.
$ git log --pretty=format:”%h %s”1.0..HEAD |
format:”%h %s”옵션을 추가하면 짧은 해시와 커밋로그의 첫 번째 줄을 보여준다.
보통 커밋 로그의 첫번째 줄은 커밋에 대한 요약 정보다.
--pretty=oneline 은 짧은 해시가 아닌 전체 해시와 커밋 로그의 첫 번째 줄을 보여준다.
일반적으로 찾고자 하는 리비전은, 다른 리비전과의 관계를 통해 설명할 수 있다.
2가지 연산자를 사용할 수 있다.
(1) ^: 캐럿 문자는 -1로 취급한다. 18f822e^은 18f822e와 일치하는 리비전 바로 이전 리비전으로 해석한다.
여러 개의 캐럿 문자를 사용할 수도 있다.
18f822e^^은 18f822e의 2번째 앞 리비전을 나타낸다.
(2) ~N: ~기호와 숫자 연산자는 커밋명에서 N만큼 뺀다.
마지막 예를 다시 이용해보면, 18f822e~1은 18f822e 바로 이전 리비전을 나타내고, 18f822e~2는 18f822e의 2번째 앞 리비전을 나타낸다.
물론 2가지 연산자를 섞어서 사용할 수도 있다.
다음 4개의 명령어는 모두 동일한 리비전을 보여준다.
$ git log -1 HEAD^^^ … $ git log -1 HEAD^~2 … $ git log -1 HEAD~1^^ … $ git log -1 HEAD~3 … |
앞의 설명했던 범위도 ^과 ~를 이용하여 지정할 수 있다.
$ git log HEAD~10..HEAD |
1.3. 버전간의 차이점 자세히 보기
4.3 ‘변경된 내용 살펴보기’에서 git diff를 사용해 작업 복사본과 저장소간의 차이를 보는 방법을 배웠다.
저장소의 이력을 볼 때도 git diff를 사용할 수 있다.
$ git diff 18f822e |
리비전 범위와 범위 지정 연산자는 git log와 동일하다.
유일한 차이는 점진적으로 보여주는 대신에 모든 변경 사항들을 섞어서 한 번에 보여준다는 점이다.
git diff를 태그와 함께 이용하면, 릴리스 사이의 통계를 내는데 매우 유용하다.
git diff에 태그를 이용하면 얼마나 많은 줄이 변경되었고, 얼마나 많이 제거되었는지 알 수 있다.
git diff에는 정말 멋진 기능이 하나 더 있는데, 변경 사항에 대한 통계를 출력하는 기능이다.
--stat을 추가하면 된다.
$ git diff –stat 1.0 |
지난 주 또는 마지막 태그 이후에 수정된 코드가 얼마나 되는지 알 수 있는 훌륭한 방법이다.
태그를 하나만 지정했다. 2번째 리비전을 지정하지 않으면 HEAD와 비교한다.
1.4. 누구 책임인지 찾기
git blame은 파일의 각 줄 앞에 커밋명, 커밋한 사람, 시간 정보를 추가해서 보여준다.
$ git blame hello.html ^7b1558c index.html (Travis S. 2008-09-21 14:20:21 -0500 1) <html> a5dacabd index.html (Travis S. 2008-09-21 20:37:47 -0500 2) <html> |
git blame 출력 결과
(1) 처음 8자리 문자는 커밋 해시를 보여준다.
첫 줄에 ^이 있는 것은, 해당 커밋이 저장소에서 첫 번째 커밋임을 의미한다.
(2) 파일명이 index.html로 되어 있다.
처음에는 index.html 파일로 만들었다.
출력 결과에서 2번째 열에, 현재 파일과 다른 이름이 있다면, 다른 파일이었을 때 변경된 내용임을 나타낸다.
(3) 커밋한 사람의 이름과 커밋한 시간을 보여준다.
(4) 줄번호와 코드 한줄을 보여준다.
전체 파일에 대해서 이런 정보가 필요한 경우는 별로 없다.
따라서 파일의 일부분에서만 해당 정보를 볼 수 있도록 –L 옵션을 제공한다.
-L 옵션을 이용하면 특정 범위만 보여주도록 요청할 수 있다.
-L 옵션은 ‘<시작>, <끝>’의 매개변수 하나를 받는다.
시작과 끝은 숫자일 수 있다.
예를 들어 다음 명령어는 hello.html 파일의 12번째와 13번째 줄에 대한 정보를 보여준다.
$ git blame –L 12,13 hello.html ^7b1558c index.html (Travis S. 2008-09-21 14:20:21 -0500 12) </body> ^7b1558c index.html (Travis S. 2008-09-21 14:20:21 -0500 13) </html> |
끝나는 줄이 꼭 숫자일 필요는 없으며 +N이나 –N의 형식으로 범위를 지정할 수 있다.
다음 명령어는 이전 명령어와 출력 결과가 동일하다.
$ git blame –L 12,+2 hello.html ^7b1558c index.html (Travis S. 2008-09-21 14:20:21 -0500 12) </body> ^7b1558c index.html (Travis S. 2008-09-21 14:20:21 -0500 13) </html> |
-N 표기법을 사용하면 지정한 숫자만큼 뺀다.
파일의 12번째 줄과 11번째 줄을 보려면 –L 12,-2를 이용할 수 있다.
$ git blame –L 12,-2 hello.html 4333289e index.html (Travis S. 2008-09-22 07:54:28 -0500 11) </ul> ^7b1558c index.html (Travis S. 2008-09-21 14:20:21 -0500 13) </body> |
줄번호가 표시되는 편집기를 사용중이라면 파일에서 발생한 문제를 확인할 때 숫자를 사용하는 것이 편리하다. 하지만 Git은 시작과 끝을 지정하는 다른 방법도 제공한다.
바로 정규표현식이다. (Git은 POSIX 정규표현식을 사용한다)
이전 blame 명령어를 정규 표현식을 이용하면 다음과 같이 작성할 수 있다.
$ git blame –L “/<\/body>/”hello.html ^7b1558c index.html (Travis S. 2008-09-21 14:20:21 -0500 12) </body> ^7b1558c index.html (Travis S. 2008-09-21 14:20:21 -0500 13) </html> |
보고자하는 리비전을 지정하려면 6.2참고,
4333289e 커밋 이전의 hello.html 파일을 보려고 한다면 다음 명령을 이용할 수 있다.
$ git blame –L “/<\/body>/”,-2 4333289e^ -- hello.html |
옵션다음에 실제 파일명이 나오기 전에 -- 가 있음.
-- 은 파일명을 지정할 때 사용한다.
1.5. 내용 따라가기
Git은 파일 안에서 내용이 이동했거나, 다른 파일로 옮겨갔어도 추적할 수 있다. 이 기능은 몇 줄의 코드에 대한 원본 커밋과 커밋한 사람을 추적해 갈 때 유용하다.
C 언어의 닫는 중괄호나 파이선의 단순한 생성자도 일치시킬 수 있도록, Git은 복사해서 붙여 넣은 코드를 감지하려고 할 때 적어도 3줄 이상을 일치시키려고 시도한다.
original.txt
This is the first line. This happens to be the second line. And this, it is the third and final line. |
새로운 파일을 저장하고, 저장소에 추가하고 커밋하자. $ git add original.txt $ git commit –m “commit of original text file” … |
파일을 다시 열어 전체 내용을 중복시킨다. 단순히 처음 3줄을 복사해서 다음 줄에 붙여 넣고 저장 |
Git이 내용을 알 수 있도록 변경사항을 커밋하고, git blame으로 파일의 각 줄의 이력을 볼 수 있다.
line1 $ git blame original.txt - b87524b7 (…1) This is the first line. - b87524b7 (…2) This happens to be the second line. - b87524b7 (…3) And this, it is the third and final line. 5 222cb821 (…4) This is the first line. - 222cb821 (…5) This happens to be the second line. - 222cb821 (…6) And this, it is the third and final line. |
출력결과는 이보다는 많을 것이다.
출력결과에서 …부분은 커밋한 사람과 시간정보이다.
처음 8자리는 커밋명의 짧은 이름이다.
내용 앞의 숫자는 텍스트의 줄 번호이다.
2~4줄과 5~7은 같은 이름을 가지고 있다. 이는 지금까지 2번 커밋했음을 의미한다.
-M 매개변수를 추가하고 명령을 다시 해보자.
-M 은 git blame이 이동했거나 같은 파일에서 복사된 내용을 찾는다.
$ git blame –M original.txt b87524b7 (…1) This is the first line. b87524b7 (…2) This happens to be the second line. b87524b7 (…3) And this, it is the third and final line. b87524b7 (…4) This is the first line. b87524b7 (…5) This happens to be the second line. b87524b7 (…6) And this, it is the third and final line. |
이제 모든 커밋명이 동일해졌다. Git은 내용을 추적하므로 반복되는 패턴을 발견하면 동일한 내용이 있다고 판단한다.
Git은 파일간에 복사한 경우도 추적할 수 있다.
original.txt를 새로운 파일인 copy.txt 파일로 복사하자.
파일 간에 복사한 경우를 확인하려면 git blame 명령어에 –C -C 를 추가하면 된다.
$ git blame –C –C copy.txt b87524b7 original.txt (…1) This is the first line. b87524b7 original.txt (…2) This happens to be the second line. b87524b7 original.txt (…3) And this, it is the third and final line. b87524b7 original.txt (…4) This is the first line. b87524b7 original.txt (…5) This happens to be the second line. b87524b7 original.txt (…6) And this, it is the third and final line. |
Git은 원본 커밋명인 b87524b7을 보여줄 뿐 아니라, 원본 파일명인 original.txt도 보여준다.
git log에도 동일하게 –C –C 매개변수를 지정하면 전체 파일이 복사됐음을 보여준다.
git log 명령어에서 복사한 내용을 찾을 때는 –p 옵션을 추가해야 한다. 기존의 로그 정보 외에도 각 커밋의 변경 사항을 보여준다.
$ git log –C –C -1 –p commit … Author: … Date: …
copy original to show cross-file blame
diff –git a/original.txt b/copy.txt similarity index 100% copy from original.txt copy to copy.txt |
copy.txt 파일이 original.txt 파일과 100% 일치하는 것을 알 수 있다.
'형상관리 > Git' 카테고리의 다른 글
| Git, 분산버전 관리시스템(11) - Git으로 옮겨가기 (0) | 2012.04.23 |
|---|---|
| Git, 분산버전 관리시스템(10) – 기본을 넘어서 (0) | 2012.04.23 |
| Git, 분산버전 관리시스템(9) - 저장소 조직하기 (0) | 2012.04.23 |
| Git, 분산버전 관리시스템(8) - 원격 저장소를 이용하여 작업하기 (0) | 2012.04.23 |
| Git, 분산버전 관리시스템(7) - Git 이력 이용하기(2) – 변경 취소하기 (0) | 2012.04.23 |
| Git, 분산버전 관리시스템(5) - 브랜치 이해하고 활용하기 (0) | 2012.04.23 |
| Git, 분산버전 관리시스템(4) – Git 기초: 추가하고 커밋하기 (0) | 2012.04.23 |
| Git, 분산버전 관리시스템(3) – 첫 프로젝트 만들기 (0) | 2012.04.23 |
| Git, 분산버전 관리시스템(2) - Git 설정하기 (0) | 2012.04.23 |
| Git, 분산버전 관리시스템(1) - Git 방식으로 버전 관리하기 (0) | 2012.04.23 |