3.소스 관리

3-1.실습 폴더 백업

아직 프로젝트를 많이 진행하지는 않았지만 버전 관리 이력이 쌓이기 시작했다. 깃이 일을 잘 하고 있는지 .git 폴더를 들여다 보면 초기화때 20K였던 것이 28K로 약간 늘어났다. 이 안에 주인공 늘리기 전후의 소스, 사운드 추가 전후의 소스 등이 모두 들어 있다. 소스만 소폭 수정해서 많이 늘어나지 않았지만 앞으로는 더 급격하게 늘어날 것이다.

이후 몇 가지 커밋을 더 해 보고 버전끼리 비교, 취소, 수정하는 다양한 실습까지 해 볼 것이다. 이런 실습이 원활하려면 정확히 앞 단계와 같이 만들어야 하는데 이게 번거롭다. 실습 중이니 당연히 실수할 수 있고 성공했더라도 같은 실습을 여러번 반복해 볼 필요도 있다. 학습의 기본은 반복 실습이다. 그런데 한번 커밋하면 취소하더라도 전 상태와 완전히 같지는 않아 초기화부터 다시 실습해 와야 한다.

워킹트리를 특정 상태대로 보존해 두려면 따로 사본을 떠 두는 것이 간편하다. 깃은 워킹트리내의 소스를 관리할 뿐 폴더 자체를 관리하지는 않으니 이때는 전통적인 복사 방법을 사용해야 한다. game 폴더는 용량이 작아 굳이 압축할 필요는 없고 game_bak(또는 game-복사본)으로 사본 폴더를 만든다.

현 상태 그대로 박제를 떠 두는 작전이다. 실습을 잘못했거나 이전 단계를 한번 더 반복하고 싶으면 game 폴더 안쪽을 완전히 지우고 game_bak 폴더를 복사한 후 다시 실습하면 된다. 이때 숨겨진 폴더인 .git안에 중요한 정보가 다 들어 있으므로 반드시 같이 복사해야 한다. 이 작전이 잘 통하는지 테스트해 보자. sound.cpp 파일을 마음대로 편집하여 엉망으로 만들어 본다.

배경음악재생() {

동해물과 백두산이 마르고 닳도록...

}

효과음재생() {

얄리얄라 얄라셩 얄라리 얄라.

}

이래 놓고 git commit -am "세상은 요지경"으로 커밋한다. 소스 수정 후 커밋했으니 당연히 저장소에 기록하고 커밋 로그도 추가한다. 요걸 개판치기 전의 상태로 되돌리고 싶으면 game_bak 폴더를 통째로 game 폴더로 복사해 넣으면 된다.

원상 복구 후 로그를 출력해 보면 이전 상태로 깔끔하게 돌아와 있으며 "세상은 요지경" 로그는 보이지 않는다. 손이 좀 가지만 전통적이고 상식적인 방법이라 이해하기 쉽다. 실습 단계별로 백업을 떠 두고 싶으면 game_1, game_2 식으로 번호를 붙여 두고 돌아가고 싶은 단계로 복구한 후 실습을 반복하면 된다.

실무에서는 깃이 소스를 잘 관리해 주므로 이런 수동 백업 방법을 쓸 필요는 없다. 그러나 현상태 그대로 작업로그까지 "얼음" 상태로 백업해 두고 싶다면 워킹트리 자체를 사본으로 떠 두면 된다. 깃 자체를 실습할 때, 특히 브랜치처럼 상황을 의도적으로 만들어 효과를 살펴볼 때는 이 방법이 의외로 효율적이다.

3-2.소스 비교

세번 수정하여 커밋했고 워킹트리는 깨끗한 상태이다. 이번에는 소스를 수정한 후 이전 버전과 비교하는 실습을 해 보자. 잔챙이만 나오니 게임이 단조로운 감이 있는데 가끔 무시무시한 대장이 나와 레이저를 쏘도록 하여 긴장도를 높여 보자.루프 안쪽에 대장을 만들고 등장시키는 코드를 작성한다.

소개 화면 표시하고 키 누를 때까지 대기

for (1~3) {

배경음악 재생 시작

while (죽을 때까지) {

주인공 이동

적군 이동

총알 발사 및 충돌 점검

적군 죽으면 효과음

가끔 대장 등장, 레이저 발사

}

배경음악 재생 정지

}

컴파일 후 테스트해 보니 난이도가 적당하고 재미도 있어 괜찮아 보인다. 스테이지에 올려 놓되 완전히 확정한 것은 아니어서 커밋은 잠시 보류한다. 상태를 찍어 보면 수정한 파일이 커밋 대기 상태라고 나온다.

$ git add game.cpp

soen@SoenDesk MINGW64 /c/StudyGit/game (main)

$ git status

On branch main

Changes to be committed:

(use "git restore --staged <file>..." to unstage)

modified: game.cpp

스테이지에 올려 놓고 다시 테스트해 보니 적군은 강해졌는데 주인공은 레이저 피하느라 바빠졌다. 균형을 맞추기 위해 주인공은 왼쪽 끝에서 오른쪽 끝으로 순간 이동하는 워프 기능을 넣어 주기로 한다.

소개 화면 표시하고 키 누를 때까지 대기

for (1~3) {

배경음악 재생 시작

while (죽을 때까지) {

주인공 이동 - 좌우워프

적군 이동

총알 발사 및 충돌 점검

적군 죽으면 효과음

가끔 대장 등장, 레이저 발사

}

배경음악 재생 정지

}

소스를 저장한 후 테스트만 해 보고 스테이지로는 올리지 않았다. 이 상태를 찍어 보면 커밋할 것도 있고 스테이지로 올릴 것도 있다.

$ git status

On branch main

Changes to be committed:

(use "git restore --staged <file>..." to unstage)

modified: game.cpp

Changes not staged for commit:

(use "git add <file>..." to update what will be committed)

(use "git restore <file>..." to discard changes in working directory)

modified: game.cpp

이러면 워킹트리, 스테이지, 저장소의 상태가 모두 다르다. 정신없이 개발하다 보면 저장소의 확정 버전, 스테이지의 임시 수정본, 워킹트리의 현재 작업본이 모두 다른 상황이 될 수 있다. while 안쪽만 비교해 보자.

주인공 이동 - 좌우워프 적군 이동 총알 발사 및 충돌 점검 적군 죽으면 효과음 가끔 대장 등장, 레이저 발사	주인공 이동 적군 이동 총알 발사 및 충돌 점검 적군 죽으면 효과음 가끔 대장 등장, 레이저 발사	주인공 이동 적군 이동 총알 발사 및 충돌 점검 적군 죽으면 효과음
워킹트리	스테이지	저장소

이 상황에서 뭘 바꿨는지 확인하려면 워킹트리의 작업중인 소스와 이전의 소스를 비교해야 한다. 필요 없을 거 같아 지워 버렸는데 다시 필요해졌다거나 수치를 바꿨는데 이전값이 뭔지 알아야 하는 경우이다. 이럴 때는 diff 명령으로 이전 상태와 비교한다.

$ git diff

diff --git a/game.cpp b/game.cpp

index 167a5cc..f4bd4f5 100644

--- a/game.cpp

+++ b/game.cpp

@@ -2,7 +2,7 @@

for (1~3) {

배경음악 재생 시작

while (죽을 때까지) {

- 주인공 이동

+ 주인공 이동 - 좌우워프

적군 이동

총알 발사 및 충돌 점검

적군 죽으면 효과음

diff 명령은 워킹트리의 현재 소스와 스테이지에 올려 놓은 소스를 비교한다. 앞에 -가 붙은 것은 지워졌다는 뜻이고 +가 붙은 건 새로 추가했다는 뜻인데 한 줄 내에서 수정한 경우는 그 줄을 지우고 새로 작성한 것으로 표시한다. 이 비교결과를 통해 스테이지에 올린 후 주인공을 좌우워프하는 기능을 더 추가했음을 알 수 있다.

소스 관리 기능을 사용하지 않으면 수정했거나 지워 버린 코드를 다시 볼 방법이 없다. 바로 직전의 코드라면 Undo로 취소해서 잠시 볼 수 있지만 그러다가 키 한번 잘못 누르면 수정한 소스를 잃어 버릴 위험이 있다. 수동 백업해 놓았더라도 이전 소스를 나란히 열어 놓고 눈깔 빠지게 비교해 봐야 하는 곤란함이 있다.

깃은 모든 이력을 다 가지고 있으므로 diff 명령 하나로 깔끔하게 비교해 준다. --staged (또는 cached)옵션을 사용하면 스테이지와 저장소의 소스를 비교하여 최후 커밋 이후 스테이지의 소스가 어떻게 바뀌었는지 비교한다. 대장이 등장하고 레이저를 발사하는 코드를 추가했음을 알 수 있다.

$ git diff --staged

diff --git a/game.cpp b/game.cpp

index 6d257fa..167a5cc 100644

--- a/game.cpp

+++ b/game.cpp

@@ -6,6 +6,7 @@ for (1~3) {

적군 이동

총알 발사 및 충돌 점검

적군 죽으면 효과음

+ 가끔 대장 등장, 레이저 발사

}

배경음악 재생 정지

}

diff 명령은 변경된 모든 파일을 보여 주는데 특정 파일만 보려면 파일명을 지정한다. 위 실습에서 우리는 game.cpp를 수정했음을 명확히 알고 있어 생략했지만 git diff가 이 경우는 git diff game.cpp와 같은 명령이다. git diff sound.cpp 명령을 내리면 수정한 게 없으므로 아무 출력도 나오지 않는다. 같다고 메시지라도 출력해 주지 좀 무심하다.

프로젝트의 진행 상황을 점검할 때는 이미 커밋한 버전끼리 비교한다. 이때는 두 커밋의 해시값을 인수로 전달한다. 해시는 로그에서 복사하는데 너무 길어서 불편하니 전체 자리수를 다 쓰지 않고 7자리만 쓴다. 이것도 외워서 쓰기는 어려우므로 log --oneline 명령으로 목록을 조사한 후 해시값을 복사해 사용하는 것이 편리하다.

$ git log --oneline

eb4622b (HEAD -> main) 배경음악 및 효과음 추가

7a9c088 주인공 3대로 늘림

8b8c594 프로젝트 시작

이 목록에서 주인공을 늘린 후(7a9c088)와 사운드를 추가한 후(eb4622b)의 상태를 비교해 보자. 이때 순서에 주의해야 하는데 앞쪽 커밋을 기준으로 뒤쪽 커밋의 변화를 조사하는 식이라 더 빠른 커밋이 앞에 와야 한다. 마지막 커밋과 그 직전 커밋을 비교해 봤다. 사운드 재생 기능이 들어갔음을 알 수 있다.

$ git diff 7a9c088 eb4622b

diff --git a/game.cpp b/game.cpp

index f676b43..6d257fa 100644

--- a/game.cpp

+++ b/game.cpp

@@ -1,8 +1,11 @@

소개 화면 표시하고 키 누를 때까지 대기

for (1~3) {

+ 배경음악 재생 시작

while (죽을 때까지) {

주인공 이동

적군 이동

총알 발사 및 충돌 점검

+ 적군 죽으면 효과음

}

+ 배경음악 재생 정지

}

diff --git a/sound.cpp b/sound.cpp

new file mode 100644

index 0000000..bfcffeb

--- /dev/null

+++ b/sound.cpp

@@ -0,0 +1,7 @@

+배경음악재생() {

+ 띠리리리리~~~

+}

+

+효과음재생() {

+ 쾅쾅

+}

해시를 쓰는게 귀찮으면 현재 위치인 HEAD와 이전 커밋을 비교한다. HEAD~n은 마지막 커밋에서 n번째 앞을 의미한다. 위 명령은 git diff HEAD~1 HEAD로 간단히 쓸 수 있다. 더 앞쪽의 변화를 보고 싶으면 git diff HEAD~2 HEAD~1 명령을 내리고 git diff HEAD~2 HEAD는 두 단계 커밋을 한꺼번에 비교한다.

새로운 기능을 작성할 때 덤벙거리지 말고 이전 코드를 항상 참고하여 작업해야 한다. 너무 급하게 작업하다 보면 버그를 수정하다가 더 큰 버그를 만들어 놓는 실수를 하기도 한다. 다 작성한 후에도 뭘 바꿨는지, 불피요하게 잘못 수정한 건 없는지 면밀히 비교하여 제대로 수정했음을 확인한 후 커밋해야 한다.

이 실습은 예제 코드가 짧아 한 눈에 차이를 알 수 있지만 아주 긴 소스는 텍스트 환경에서 빠르게 살펴 보기 어렵다. 비교는 잘 하지만 텍스트 환경의 한계가 있어 결과를 보여 주는 방식이 눈에 쏙 들어오지 않는다. 이럴 때는 그래픽 환경의 비교툴이 필요하다. 다음은 그래픽 비교툴의 예이다.

좌우의 패널을 나눠 놓고 삽입, 삭제된 내용을 나란히 보여 주므로 어디가 어떻게 바뀌었는지 알아 보기 쉽다. 그래픽 환경의 툴은 다음에 배워 보기로 하고 지금은 깃이 비교를 위한 모든 준비를 다 해 놓았다는 것만 알아 두자.

3-3.변경 취소

소스를 저장소에 일일이 백업하는 이유는 뭔가 실수를 했거나 사고가 발생하면 다시 가져 오기 위해서이다. 앞에서 만든 대장 등장과 워프 기능이 마음에 안든다고 가정하고 이전 소스로 복원하는 실습을 해 보자. 신나게 코딩했어도 결과적으로 삽질이었던 경우가 많다. 현 상태를 다시 조사해 보자.

$ git status

On branch main

Changes to be committed:

(use "git restore --staged <file>..." to unstage)

modified: game.cpp

Changes not staged for commit:

(use "git add <file>..." to update what will be committed)

(use "git restore <file>..." to discard changes in working directory)

modified: game.cpp

위쪽 메시지는 스테이지의 소스가 커밋한 것과 다르다는 뜻이고 아래쪽 메시지는 워킹트리의 소스가 스테이지와 다르다는 뜻이다. 괄호안에 간략한 도움말도 잘 설명되어 있다. 테스트해 보니 새로 추가한 기능에 문제가 많아 아예 이전 상태로 돌아가기로 했다. 이럴 때는 restore 명령을 사용하며 복구할 파일을 지정한다.

$ git restore game.cpp

soen@SoenDesk MINGW64 /c/StudyGit/game (main)

$ git status

On branch main

Changes to be committed:

(use "git restore --staged <file>..." to unstage)

modified: game.cpp

이 명령은 스테이지에 올린 마지막 상태로 워킹트리의 소스를 복구한다. 복구 후 game.cpp 소스를 보면 좌우워프 기능이 사라졌다. 그러나 아직 스테이지의 소스는 커밋한 상태와는 다르다. 이것까지 취소하려면 --staged 옵션을 준다.

$ git restore --staged game.cpp

soen@SoenDesk MINGW64 /c/StudyGit/game (main)

$ git status

On branch main

Changes not staged for commit:

(use "git add <file>..." to update what will be committed)

(use "git restore <file>..." to discard changes in working directory)

modified: game.cpp

no changes added to commit (use "git add" and/or "git commit -a")

이러면 최종 커밋한 내용을 스테이지로 다시 가져온다. 스테이지의 내용이 바뀌었으니 워킹트리의 소스와 달라졌다. 다시 한번 restore 명령으로 워킹트리의 소스를 복구한다. 이러면 세 소스가 모두 같아지며 최종 커밋한 걸 완벽하게 복구한 것이다.

$ git restore game.cpp

soen@SoenDesk MINGW64 /c/StudyGit/game (main)

$ git status

On branch main

nothing to commit, working tree clean

중간 중간의 상태를 점검해 보기 위해 원상 복구를 세 번에 걸쳐 했는데 restore --staged로 스테이지를 먼저 복구하고 restore 명령을 내리면 두 번에 완료할 수 있다. 중간에 스테이지가 끼어 있어 명령문이 복잡해 보이는데 정리하자면 다음과 같다.

diff, restore 명령은 워킹트리와 스테이지를 비교, 복원하는 것이며 --staged 옵션을 붙이면 스테이지와 저장소를 비교, 복원하는 것이다. 두 동작 모두 중간의 스테이지를 경유하는 것이 안전하다. 만약 워킹트리와 저장소를 직접 비교, 복원하려면 다음 두 명령을 사용한다.

비교 : git diff HEAD game.cpp

복원 : git restore --source=HEAD game.cpp

비교는 읽기만 하는 동작이라 스테이지를 빼도 별 문제 없다. 그러나 스테이지를 건너뛰고 저장소의 내용을 직접 워킹트리로 복원하는 것은 여러모로 혼란스러운 문제를 야기할 수 있어 바람직하지 않다. 저장소에는 여러 버전이 같이 들어 있어 복원하고 싶은 정확한 버전을 지정해야 한다.

프로젝트를 하다 보면 엉뚱한 기획을 할 때도 있고 무리한 시도를 해 볼 수도 있다. 아무리 소스를 많이 뜯어 고쳤더라도, 황당한 실수를 했더라도 스테이지에 임시 버전이 있어 워킹트리의 변경은 즉시 취소할 수 있다. 또 저장소에도 모든 버전이 고스란히 보존되어 있으므로 언제든지 원하는 시점으로 돌아올 수 있다.

앞에서 해 본 시도는 다 마음에 들지 않았음을 확실히 알게 되었고 심기일전하여 코드를 제대로 다시 작성한다. 좌우워프는 총알을 피하기 너무 쉬우니 가속도를 적용하여 움직임에 변화를 준다. 레이저는 피하기 어려워 폭탄을 던지는 걸로 바꿨다.

소개 화면 표시하고 키 누를 때까지 대기

for (1~3) {

배경음악 재생 시작

while (죽을 때까지) {

주인공 이동 - 가속도 적용

적군 이동

총알 발사 및 충돌 점검

적군 죽으면 효과음

가끔 대장 등장, 폭탄 발사

}

배경음악 재생 정지

}

의사코드라 별반 다를 것은 없지만 실제 코드에서는 구현 코드가 상당히 다를 것이다. 여기까지 작업한 후 커밋하자.

$ git commit -am "대장등장, 가속도이동"

이제 4번 커밋했으며 저장소에는 모든 버전이 고스란히 보관되어 있다. 커밋했다는 것은 영구적으로 저장할 버전 하나를 만들었다는 것이다. 좌우워프와 레이저는 중간 테스트 단계로 시도해 봤지만 저장소에는 커밋한 적이 없다.

3-4.커밋 취소

앞 실습은 워킹트리와 스테이지의 상태를 복구하는 것이었다. 커밋하기 전에 실수를 발견했으면 스테이지와 잘 비교해 가며 워킹트리에서 다시 작업하면 된다. 그러나 커밋까지 다 해 버린 후에 실수를 발견하는 경우도 있다. 이때는 수정하여 다시 커밋하는 방법도 있지만 커밋 자체를 취소하는 것도 가능하다.

어느날 김대리가 회식 후 갑자기 코딩이 하고 싶은 이상야릇한 욕구에 사로잡혀 회사로 다시 출근해 알코올 코딩을 했다고 하자. 게임 논리를 마음대로 바꾸고 이상한 메시지 집어 넣고 낄낄거리며 신나게 코딩 놀이를 했다.

멋진 사진 표시하고 키 누를 때까지 대기

for (1~9) {

배경음악 재생 시작

while (무적 모드) {

주인공 이동 - 가속도 적용

적군 이동 - 느릿느릿

총알 발사 및 충돌 점검

적군 죽으면 "사장님 짠돌이" 메시지 출력

가끔 대장 등장, 장렬히 자폭

}

배경음악 재생 정지

}

이 코드로 게임을 해 보니 스트레스 해소도 되고 게임도 쉬워 마음에 들었다. 심신미약 상태에서 과하게 용감해져 커밋까지 해 버렸다. 한마디로 개판을 쳐 놓은 것이다.

$ git commit -am "무적 모드, 냐하하"

커밋로그를 찍어 보면 기록이 선명하게 남아 있고 아무나 기록을 살펴볼 수 있다. 다음날 아침 문득 정신을 차려 보니 뭔가 대형 사고를 친 거 같은데 사장님이 보기 전에 빨리 흔적을 지워야 한다. 과감한 시도를 하다 보면 아예 없던 일로 만들고 싶을 때가 있다.

$ git log

commit 4a1bce7f1d2741c4e8142596f0836988fbc2ad8b (HEAD -> main)

Author: soen <soenmaster@naver.com>

Date: Sun Oct 27 20:54:45 2024 +0900

무적 모드, 냐하하

커밋한 작업을 취소할 때는 reset 명령을 사용하는데 저장소를 조작한다는 면에서 굉장히 위험하며 잘못 사용하면 더 엉망이 될 수도 있어 꼭 필요할 때만 정확한 방법으로 사용해야 한다. 리셋하는 범위에 따라 세 가지 모드가 있다.

옵션	설명
--soft	커밋만 삭제하고 스테이지와 워킹트리는 건드리지 않는다. 소스는 그대로 보존되어 있으므로 다시 커밋할 수도 있다.
--hard	커밋뿐만 아니라 스테이지와 워킹트리까지 완전히 삭제한다. 모든 기록이 커밋 이전으로 돌아가 버려 복구할 수 없다.
--mixed	커밋과 스테이지까지만 복구하고 워킹트리는 건드리지 않는다. 스테이지로 올린 후 다시 커밋할 수 있다. 이 모드가 디폴트이다.

리셋 대상은 주로 최근 커밋인데 HEAD~n으로 표기한다. HEAD~1이 제일 위의 커밋, HEAD~2가 그 아래의 커밋인 식이다. HEAD~1이 마지막 커밋이며 HEAD^도 미세하게 의미가 다르지만 일반적인 상황에서는 최신 커밋을 의미한다.

이 경우는 모든 기록을 지워 완전범죄를 달성해야 하므로 하드 리셋이 마땅하다. 아니면 기본 모드로 리셋한 후 워킹트리만 다시 복구해도 되는데 실습중이므로 두 단계로 나눠 취소해 보자. 먼저 인수없이 리셋만 한다.

$ git reset HEAD^

Unstaged changes after reset:

M game.cpp

soen@SoenDesk MINGW64 /c/StudyGit/game (main)

$ git status

On branch main

Changes not staged for commit:

(use "git add <file>..." to update what will be committed)

(use "git restore <file>..." to discard changes in working directory)

modified: game.cpp

no changes added to commit (use "git add" and/or "git commit -a")

디폴트인 --mixed 옵션을 적용하여 커밋과 스테이지를 취소한다. 그러나 워킹트리는 복구하지 않으므로 변경된 상태 그대로 남아 있다. 워킹트리까지 취소하려면 다음 명령으로 스테이지의 소스를 가져온다.

$ git restore game.cpp

이러면 워킹트리까지 이전 상태로 완벽하게 돌아온다. 잘 취소되었는지 로그를 출력해 보면 로그도 사라지고 없다. 알코올 코딩의 흔적이 깔끔하게 사라지고 이전 상태로 완벽하게 돌아왔다. 고의든 실수든 뭔가 사고를 쳤을 때 원래 상태로 돌아갈 수 있다는 점에서 버전 관리툴의 진가가 발휘된다.

3-5.특정 커밋으로 이동

이번에는 저장소의 특정 버전으로 돌아가는 실습을 해 보자. 프로젝트를 한참 진행하며 커밋을 여러 번 했는데 점점 엉망이 되어 가고 있다고 하자. 애초에 기획을 잘못했다면 깨끗하게 기획 이전 상태로 돌아가는게 좋다. 이럴 때는 reset 명령을 사용하며 로그의 커밋 해시값을 지정한다.

$ git reset --hard 7a9c088d2b57d0b86eefffda86baeca7f11d4374

HEAD is now at 7a9c088 주인공 3대로 늘림

실습중이라면 여러분의 로그에 나온 해시값을 복사하여 사용하되 7자리만 적어도 된다. 주인공을 3대로 늘린 직후의 커밋 해시를 지정하면 지정한 커밋 상태로 돌아가며 모든 파일의 변경 내역이 사라진다. game.cpp는 초기 버전으로 바뀌며 sound.cpp는 아예 사라져 존재하지도 않는다. 배경음악, 보스 등장 등의 기능도 모두 사라져 버렸다.

그렇다면 정말 사라진걸까? 로그에도 없고 파일도 사라졌지만 저장소에 기록은 남아 있다. 깃은 이전 내역을 삭제하는 것이 아니라 취소했다는 내용을 기록해 놓는다. 그래야 실수로 지운것까지도 살려 낼 수 있다. 문제는 이전 커밋의 해시값을 log로는 확인할 수 없다는 점인데 지워진 커밋까지 보려면 reflog 명령을 사용한다.

$ git reflog

7a9c088 (HEAD -> main) HEAD@{0}: reset: moving to 7a9c088d2b57d0b86eefffda86baec

a7f11d4374

fd86941 HEAD@{1}: reset: moving to HEAD^

4a1bce7 HEAD@{2}: commit: 무적 모드, 냐하하

fd86941 HEAD@{3}: commit: 대장등장, 가속도이동

eb4622b HEAD@{4}: commit: 배경음악 및 효과음 추가

7a9c088 (HEAD -> main) HEAD@{5}: commit: 주인공 3대로 늘림

8b8c594 HEAD@{6}: commit (initial): 프로젝트 시작

reflog 명령은 HEAD가 이동한 기록을 보유하며 커밋 뿐만 아니라 취소, 삭제 기록까지 다 가지고 있다. 커밋한 순서대로 HEAD@{n}으로 번호를 붙이는데 제일 위의 HEAD@{0}는 리셋한 기록이므로 그 직전 상태인 HEAD@{1}로 돌아가면 된다. 이 커밋의 해시값 7자리를 복사해 두고 다음 명령을 실행한다.

$ git reset --hard fd86941

HEAD is now at fd86941 대장등장, 가속도이동

이러면 작업한 모든 기록이 복원된다. 물론 알코올 코딩한 기록만 빼고 말이다. 모든걸 다 기록하기 때문에 사장님이 이 목록을 보고 리셋해 보면 사고친 흔적을 확인할 수도 있다. 물론 사장님은 바빠서 그럴 시간이 없겠지만 말이다.

3-6.revert

사운드 재생하느라 게임 속도가 느려지는 문제가 발견되어 사운드 기능을 별도의 스레드로 분리하기로 했다. 멀티 스레드는 속도에는 유리하지만 구조가 복잡해 제대로 만들기는 쉽지 않다. 다음과 같이 코드를 완성했다.

소개 화면 표시하고 키 누를 때까지 대기

for (1~3) {

배경음악 스레드에서 재생 시작

while (죽을 때까지) {

주인공 이동 - 가속도 적용

적군 이동

총알 발사 및 충돌 점검

적군 죽으면 효과음

가끔 대장 등장, 폭탄 발사

}

배경음악 재생 스레드 정지

}

실행해 보니 사운드도 잘 나오고 이전보다 게임 속도가 빨라져 만족스럽다. 이 코드를 쓰기로 하고 커밋한다.

$ git commit -am "배경음악 스레드로 재생"

커밋까지 해 놓고 다시 점검해 보니 스레드 동기화가 잘 안되어 게임이 끝나도 음악이 즉시 중지되지 않는 민감한 문제가 발견되었다. 스레드를 쓰면 원래 없던 문제가 생기기도 하며 원인 파악도 어렵다. 의욕적으로 도입했는데 장시간 테스트해 보니 미처 예상하지 못한 문제가 드러나는 경우가 허다하다.

일단 문제를 발견했으니 원래 코드로 돌아가되 이 코드 자체를 버리고 싶지 않고 다음에라도 개선해 보고 싶다. 커밋 이전 상태로 돌아가되 커밋한 코드 자체는 기록으로 남겨야 하며 이때는 revert 명령을 사용한다. 인수로는 돌아갈 커밋 해시가 아닌 취소할 커밋 해시를 지정한다. 이 경우 스레드를 도입한 해시를 지정하면 된다.

$ git revert 84bdb72

hint: Waiting for your editor to close the file... unix2dos: converting file C:/StudyGit/game/.git/COMMIT_EDITMSG to DOS format...

revert 명령을 실행하면 기본 편집기인 메모장이 열리며 커밋 메시지를 입력하라고 요구한다. 뭔가를 되돌리는 것은 대단히 큰 작업이며 상세한 설명이 필요하므로 아예 편집기를 열어 주는 것이다. 다 작성하고 저장 후 종료하면 리버트 완료된다.

소스 파일은 스레드를 도입하기 전의 상태로 돌아간다. 로그를 찍어보면 스레드를 도입했을 때의 커밋과 이 커밋을 취소하고 원래 상태로 복귀한 커밋이 모두 남아 있다.

$ git log

commit 83ec0ca870238c90858f1a1ebc3bf6120b95226d (HEAD -> main)

Author: soen <soenmaster@naver.com>

Date: Sun Oct 27 23:38:56 2024 +0900

Revert "배경음악 스레드로 재생"

기술적인 문제로 스레드 도입 잠시 보류함.

This reverts commit 84bdb7207793c96015f03c154fa4a33dbdd9998a.

commit 84bdb7207793c96015f03c154fa4a33dbdd9998a

Author: soen <soenmaster@naver.com>

Date: Sun Oct 27 23:37:48 2024 +0900

배경음악 스레드로 재생

commit fd869410c9505b59f4c39d50b7be5627956fa52c

Author: soen <soenmaster@naver.com>

Date: Sun Oct 27 20:50:08 2024 +0900

대장등장, 가속도이동

revert는 reset과는 달리 잠시 보류한 것이지 지운 것은 아니다. 필요할 때 스레드를 사용한 커밋으로 돌아가 코드를 다시 참조하거나 보완하면 된다. 간단한 코드라면 해당 기능을 주석으로 묶어두는 더 간편한 방법도 있지만 여기 저기 구조가 많이 바뀌었다면 주석으로 일일이 감싸기도 번거롭고 다음에 정확히 되돌리기도 어렵다.

3-7.메시지 수정

커밋 로그에 남기는 메시지는 이력을 관리하는데 큰 역할을 한다. 다른 개발자는 물론이고 나 스스로도 시간이 지난 후에 어떤 작업을 했는지 일일이 소스를 보고 알아낼 수는 없으므로 메시지에 작업 기록을 잘 남겨야 한다. 모든 작업 내용을 빠짐없이 기록하고 그러면서도 요약적으로 써야 하는데다 어떤 경우는 영어로 써야 하니 작문을 잘 해야 한다.

그러나 막상 커밋할 때는 바빠서 메시지를 대충 써 놓게 되는데 다음에라도 메시지를 정성스럽게 수정해 놓는 것이 좋다. 또 오타나 잘못된 내용을 발견했을 때 즉시 바로 잡아 두어야 이후의 혼란을 방지할 수 있다. 메시지 수정은 주로 최후 커밋에 대해 수행하는 경우가 많은데 --amend -m 옵션을 사용한다.

$ git commit --amend -m "스레드 함부로 쓰지 말것"

이러면 마지막 커밋의 메시지가 바뀐다. 수정 명령어가 edit나 modify이면 쉬울텐데 잘 사용하지 않는 amend여서 영어에 익숙하지 않은 사람에게는 생소하다. 더 상세하게 기록하고 싶으면 -m 옵션을 생략하여 편집기를 연 후 메시지를 작성한다.

#으로 시작하는 줄은 주석이며 커밋 로그에는 나타나지 않는다. 편집기는 커서를 상하좌우로 이동할 수 있어 여러 줄의 메시지를 작성하고 이동하며 편집할 수 있다. 과연 메시지가 잘 바뀌었는지 로그를 출력해 보자.

commit c7691258911cf5f30a1c595bdf229934254c9df9 (HEAD -> master)

Author: soen <soenmaster@naver.com>

Date: Wed Oct 9 22:09:09 2024 +0900

스레드 함부로 쓰지 말것. 게임 화면과 동기화 맞추기 어려움

동기화 문제는 수정중이나 스레드가 즉시 응답하지 않는 문제가 있다.

Win32 스레드에 대해서는 Windows API 정복을 참고한다.

잘 바뀌기는 했는데 이러면 민감한 부작용이 있다. 메시지만 편집했어도 커밋을 새로 하는 것과 같아 커밋 해시값도 바뀐다. ID가 바뀌면 이 ID를 참조하는 곳이 영향을 받을 위험이 있다. 로컬에서 작업할 때는 별 문제가 안되지만 원격 저장소를 변경한 경우는 추가적인 조치가 더 필요할 수도 있다.

최후 커밋이 아닌 이전 커밋의 메시지를 변경하는 것도 가능은 하지만 복잡하고 번거롭다. 명령행은 뭔가를 선택하 하기에는 적절치 않은 환경이라 단계를 거쳐야 한다. 다음 명령으로 최근 몇 개까지의 커밋을 편집할 것인지 지정한다. 최근부터 3개까지만 불러와 보자.

$ git rebase -i HEAD~3

이 명령은 최근 3개의 커밋 메시지를 읽어와 기본 편집기로 보여 준다. 여기서 편집할 대상을 선택하는데 명령행은 체크박스 같은 편리한 장치가 없으니 편집기에 목록을 표시하고 고르도록 한다.

여기서 pick이라고 표시된 것은 읽어왔다는 뜻이다. 수정하려는 메시지의 pick을 reword로 바꾸어 편집할 대상을 지정한다. 가운데 메시지의 pick을 reword로 변경 후 저장, 종료하면 수정 대상에 대해 새로운 편집기를 열어 준다. 여기서 메시지를 편집한다.

배경음악 스레드로 재생했으나 문제가 있어 보류함

저장 후 편집기를 종료하면 메시지 수정이 완료된다. 선택을 위해 한번, 편집을 위해 한번 편집기가 따로 열리는 점을 주의하자. 로그를 찍어 보면 메시지가 수정되어 있으며 이때도 커밋 해시는 바뀐다.

선택, 편집의 두 단계를 거치더라도 어쨌거나 메시지를 수정할 방법을 제공하는 것은 고마운 일이다. 그러나 보다시피 직관적이지 않고 절차도 복잡하다. 그래서 처음 커밋할 때 잘 작성하는게 최선이고 부득이하게 그러지 못했으면 다른 커밋을 올리기 전에 미리 편집해 두어야 한다. 그나마 최후 커밋 메시지를 수정하는 것은 쉬운 편이다.

3-8.추적 제외

깃은 워킹트리에 있는 모든 파일과 서브 디렉토리를 추적 대상으로 인식하며 스테이지를 거쳐 저장소에 보관한다. 물론 add 명령으로 추적을 하라고 지시한 이후부터이지만 수많은 파일을 개별적으로 지정하기는 어렵고 디렉토리 단위로 스테이지에 올리므로 폴더내의 모든 파일이 추적 대상이다.

그러나 프로젝트에 속하더라도 추적할 필요가 없는 파일도 많다. 컴파일중에 생성되는 obj 파일, 컴파일 결과로 만들어진 exe 파일은 소스만 있으면 언제든지 새로 만들 수 있으므로 굳이 백업할 필요가 없다. 또 bak나 tmp 등 특정 확장자의 파일이나 Debug, Release 같은 폴더도 백업 대상이 아니다.

일반적으로 사람이 만든 것은 보관이 필요하지만 기계가 생성했거나 외부에서 받은 파일은 언제든지 다시 구할 수 있어 추적할 필요없다. 추적에서 제외할 파일의 조건을 .gitignore 파일에 작성해 놓으면 이 조건에 해당하는 파일은 스테이지에 올리지 않으며 추적도 하지 않는다. 제외할 파일이나 폴더, 특정 확장자 등을 기록해 놓으면 된다. 워킹트리에 .gitignore 파일을 생성하고 다음 조건을 기록해 두자.

# 무시할 파일 목록

memo.txt

Debug/

Release/

*.obj

*.exe

!model.obj

#으로 시작하면 주석이다. 특정 파일 이름을 완전히 적으면 이 파일은 추적 대상에서 제외된다. /로 끝나는건 디렉토리이다. 패턴은 와일드 카드를 쓰되 주로 특정 확장자를 지정한다. 제외한 것중에 예외를 둘 때는 ! 기호를 사용하는데 확장자가 obj인 파일은 추적 대상에서 제외하지만 model.obj는 예외적으로 추적 대상으로 포함하라는 뜻이다.

.gitignore는 추적에서 제외할 파일을 지정하지만 이 파일 자체는 추적 대상이다. 왜냐하면 제외 대상 조건도 수시로 바뀔 수 있어 버전의 설정 정보에 해당하기 때문이다. 이 파일에 작성한 조건이 효과를 발휘하려면 스테이지에 올리고 커밋까지 해야 한다.

$ git add .gitignore

$ git commit -m "무시할 파일 등록"

.gitignore를 커밋한 후부터 이 파일내의 조건에 해당하는 파일은 더 이상 스테이지로 올리지 않는다. 단, 이미 스테이지에 올라가 있는 파일까지 내려 주지는 않으므로 이런건 수동으로 직접 내려야 한다. 애초에 프로젝트를 시작할 때부터 제외 대상을 미리 지정해 두는 것이 이상적이다.

깃허브는 언어별로 추적 제외파일 목록을 잘 만들어 놓은 템플릿을 제공한다. C++이나 Java 등 많이 쓰는 언어의 중간 파일 목록이 뻔해 누가 만들어도 비슷할 수밖에 없다. 예상보다 목록이 길고 복잡하므로 템플릿을 가져온 후 용도에 맞게 수정해서 사용하자.