2.따라하기 실습

2-1.실습 준비

어떤 툴이든 처음 배울 때는 그대로 따라해 보는 작전이 효율적이다. 실습을 하다 보면 큰 줄기를 익힐 수 있고 뭘 더 공부해야알지 목록을 파악할 수 있다. 간단한 모의 프로젝트를 수행하며 깃으로 소스를 관리하는 절차와 기본 개념을 익혀 보자.

여기서는 간단한 슈팅 게임을 만들어 보되 진짜 코딩을 하지는 않고 흉내만 낸다. 갤러그, 인베이더같은 고전 게임처럼 위에서 내려오는 적을 쏘아 떨어뜨리는 게임이다. 게임은 필요한 기능을 직관적으로 이해하기 쉽고 적당히 브랜치도 해 볼 수 있다.

실습을 위해 C 드라이브의 루트에 StudyGit 폴더를 만든다. 실습 위치를 강좌와 일치시켜야 혼란이 덜하지만 상황에 따라 다른 폴더를 사용해도 상관은 없다. 단, 너무 깊은 곳은 경로가 길어 불편하며 한글이 포함된 경로는 피하는 것이 좋다. 이 안에 프로젝트를 수행할 game 폴더를 또 만든다. 명령행에서 다음 명령을 순차적으로 실행한다.

soen@SoenDesk MINGW64 ~

$ cd c:/

soen@SoenDesk MINGW64 /c

$ mkdir StudyGit

soen@SoenDesk MINGW64 /c

$ cd StudyGit

soen@SoenDesk MINGW64 /c/StudyGit

$ mkdir game

soen@SoenDesk MINGW64 /c/StudyGit

$ cd game

soen@SoenDesk MINGW64 /c/StudyGit/game

폴더 만들고 안으로 들어가 또 폴더를 만드는 명령이다. gitCMD에서 작업하고 있다면 mkdir 명령 대신 md 명령을 사용하면 된다. 명령행에서 작업하는게 귀찮거나 익숙하지 않다면 탐색기에서 폴더를 만들어도 상관 없다. 이 경우 명령행에서 cd /c/StudyGit/game 명령으로 폴더 안으로 들어간다. 현재 다음과 같이 폴더를 구성하고 game 폴더 안으로 들어와 있는 상태이다.

game 폴더 안에 프로젝트를 만들고 깃으로 관리하는 실습을 진행한다. 모든 정보가 이 폴더 안에 저장되므로 만약 중간에 실습을 잘못했거나 처음부터 다시 해 보고 싶다면 game 폴더를 싹 지워버리고 새로 만든 후 처음부터 다시 하면 된다.

명령어는 애써 외우고 차이점을 정확히 알고 있어야 한다. 깃은 이해 과목이 아닌 암기 과목이다. 명령어를 레퍼런스 뒤지고 있으면 실수할 위험이 높다. 명령어와 명령의 효과가 머리속에 완벽하게 정리되어 있어야 한다. 대충 읽지 말고 꼭 실습을 해 봐야 한다.

2-2.동작 방식

프로젝트 폴더인 game을 워킹트리(Working Tree)라고 부른다. 여기서 코딩 작업을 하며 프로젝트 폴더 안에는 Debug, Release, res, lib 등의 서브 폴더가 계층을 이루므로 트리라는 용어를 쓴다. 워킹트리라는 말을 어렵게 생각할 필요없이 그냥 프로젝트 폴더라고 생각하면 된다.

워킹트리는 프로젝트의 현재 상태이며 항상 최신 소스를 가지며 시시각각으로 변한다. 이 안의 소스를 시점별로 백업하고 필요시 이전 버전을 참조하는 것이 버전관리툴이 하는 일이다. 깃은 워킹트리의 소스를 3단계로 관리한다.

소스를 백업하는 곳을 리파지토리(Repository)라고 하는데 말이 기니 저장소로 짧게 번역한다. 이 안에 소스를 버전별로 저장하는데 버전 하나를 저장소로 올리는 동작을 커밋(Commit)이라고 한다. 프로젝트를 시작했을 때부터 최신 버전까지 중간 소스가 다 저장된다. 프로젝트 기간이 길어지면 이 안의 용량이 어마어마해질 것이다.

수동으로 1월2일자.zip, 김대리작업본.zip 등으로 압축하여 외장하드에 저장한다면 이때 외장하드에 해당하는 곳이 저장소이다. 다만 최소한의 바뀐 부분만 저장하여 용량을 절약하고 검색, 비교가 빠르다는 면에서 외장하드와는 질적으로 수준이 다르다.

깃은 다른 버전관리툴에 비해 워킹트리와 저장소 사이에 스테이지라는 단계를 하나 더 거친다는 점이 독특하다. 스테이지는 저장소에 백업하기 전에 거치는 임시적인 대기 장소이다. 중간에 한 단계를 더 거치면 안전하고 더 유연한 관리가 가능해진다.

▶ 최종 저장할 파일을 스테이지에서 선별할 수 있다. 아직 미결정된 파일은 잠시 제외해 놓고 나머지만 버전에 반영할 수 있다.

▶ 여러 기능을 동시에 구현했더라도 논리적인 묶음을 나누어 올릴 수 있다. 예를 들어 기능을 추가하던 중 버그도 발견하여 수정했다면 두 묶음을 따로 올리면 된다.

▶ 스테이지에 올려 놓은 파일과 워킹트리의 파일을 비교하여 최후 커밋 후의 상태와 비교하기 쉽다. 한단계 더 거쳐 신중하게 작업할 수 있고 실수를 방지한다.

뭐든지 한 단계를 더 거치면 할 수 있는 일이 더 많아지고 섬세해진다. 반면 작업 절차가 길어져 불편한 면이 있고 복잡도가 증가하는 단점이 있다. 비교나 복원 작업시 그 대상이 워킹트리인지 스테이지인제 잘 구분해야 한다. 저장소로 커밋하기 전에 스테이지에 먼저 올려야 하는 번거로움이 있지만 한꺼번에 처리하는 옵션도 제공한다.

2-3.저장소 초기화

실습 편의상 프로젝트 폴더인 game은 직접 만들었지만 실제 개발에서는 비주얼 스튜디오나 이클립스같은 툴이 만들어 준다. 이 폴더에는 프로젝트 수행에 필요한 모든 것이 갖추어져 있지만 아직 깃이 인식하는 워킹트리는 아니다.

깃으로 관리하려면 워킹트리 뿐만 아니라 스테이지나 저장소까지 갖추어야 한다. 이 작업을 초기화라고 하며 git init 명령을 사용한다. 초기화할 디렉토리 안으로 이동하여 명령을 내리면 저장소를 만든다는 메시지를 표시하며 금방 초기화가 완료된다.

soen@SoenDesk MINGW64 /c/StudyGit/game

$ git init

Initialized empty Git repository in C:/StudyGit/game/.git/

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

game 디렉토리를 먼저 만들어 놓고 그 안에서 git init를 실행했는데 이 두 동작을 한꺼번에 처리할 수 있다. StudyGit 디렉토리에서 다음 명령을 실행하면 디렉토리를 만들면서 바로 초기화까지 해 준다.

soen@SoenDesk MINGW64 /c/StudyGit

$ git init game

Initialized empty Git repository in C:/StudyGit/game/.git/

두번 작업할 것을 한번에 해 준다는 면에서 편리하다. 그러나 완전히 같지는 않아서 디렉토리 안으로 들어가는 것까지는 해 주지 않는다. 생성 및 초기화 후 cd game 명령으로 안으로 들어가야 완전히 같아진다.

init 명령에 의해 많은 변화가 발생한다. 탐색기로 game 폴더를 보면 .git이라는 숨김 폴더가 생성되어 있으며 그 안에도 복잡한 서브폴더가 구성되어 있다. 기본 상태에서는 안 보일 수도 있는데 탐색기의 보기탭에서 "숨긴 항목"을 체크하면 보인다. 어떻게 생겼는지 구경이나 해 보자.

.git 폴더 안에 스테이지와 저장소가 있으며 버전 관리에 필요한 모든 정보가 저장된다. 워킹트리 안에 백업용 폴더를 만들어 살짝 숨겨 놨다고 보면 된다. 초기 용량은 20K로 아주 작지만 프로젝트를 진행하면 이 안에 정보가 점점 늘어난다. 이전 버전의 백업이 모두 이 안에 들어가며 누가 언제 어떻게 바꾸었는지 낱낱이 기록한다.

내부 구조는 굳이 몰라도 되며 깃이 알아서 관리한다. 압축되어 있는 정보라 사실 들여다 봐도 뭐가 뭔지 분간하기 어렵다. 오히려 함부로 건드리면 정교한 저장 구조가 손상되므로 깃에게 그냥 맡겨두는 것이 좋다.

프롬프트에도 변화가 있는데 경로 끝에 (main)이라는 브랜치 이름이 표시되어 있다. 여기에는 현재 브랜치를 표시하는데 나중에 브랜치를 바꿔 가며 작업할 때는 다른 브랜치 이름이 표시된다. 프롬프트에 지금 작업중인 위치와 브랜치를 명확히 표시하여 헷갈리지 않도록 해 준다.

초기화를 완료하면 깃은 버전 관리를 시작한다. 소스는 개발이 진행됨에 따라 수시로 바뀐다. 개발자는 매일 또는 주요 기능을 완성할 때마다 저장소로 커밋하여 백업을 남긴다. 명령 하나만 내리면 변경된 내용을 찾아 저장소에 고이 백업해 둔다. 저장소의 저장 대상은 프로젝트 진행 단계마다 생성되는 버전이며 각 버전의 내용은 다 다르다.

워킹트리에는 프로젝트에 대한 모든 것이 다 들어 있다. 프로젝트의 현재 소스는 물론이고 이전 작업 기록까지 온전히 그 안에 품고 있다. 이런 독립적인 상태를 스스로 완결(Self Contained)이라고 표현한다. game 폴더를 딴 위치로 옮겨도 모든 정보가 같이 이동하며 압축해서 전달하면 이력까지 그대로 남아 있다.

2-4.스테이징

이제 실제 프로젝트를 진행해 보자. 개발툴로 소스를 만들고 컴파일한 후 실행해 보고 결과를 확인해 봐야겠지만 지금은 실습중이므로 평이한 텍스트로 소스를 만드는 척 흉내만 내 보기로 한다. 지금은 변경된 소스를 어떻게 관리할 것인가만 실습하면 되니 내용이 중요한건 아니다.

여기서는 메모장을 사용했는데 VSCode나 NotePad++ 같은 즐겨 쓰는 편집기를 사용해도 상관없으며 어쨌거나 관리 대상인 파일을 생성하여 프로젝트를 진행하는 척만 하면 된다. 메인 소스 파일인 game.cpp 파일을 만들고 이 안에 다음 소스를 작성한다. 게임을 진행하는 코드를 의사 코드로 표현했다. while은 조건이 만족할 때까지 반복하는 제어문이며 주인공이 살아 있는 동안 게임을 진행한다.

편집기를 따로 실행하는게 귀찮으면 명령행 안에서 vim game.cpp 명령으로 스크린 편집기를 열고 바로 편집할 수도 있다. vim은 관리 모드로 열리므로 i나 a를 누르고 입력을 시작하며 저장할 때는 Esc를 누르고 :wq를 입력하면 된다.

bash에 통합되어 있는 편집기여서 명령행을 떠나지 않고 편집할 수 있어 편리하다. 그러나 단축키가 복잡해 배우기 어려우며 한글 환경과도 잘 맞지 않다. 메모장은 개행이 CR/LF인데 비해 vim은 개행이 LF만으로 되어 있어 크기가 약간 작다. 내용상의 차이는 없지만 윈도우 환경에서는 개행 코드를 바꾸겠다는 귀찮은 경고가 발생할 수 있다. 웬만하면 손에 익은 편집기를 쓰는 것이 무난하다.

소스 내용은 주인공과 적군이 총알을 주고 받으며 게임을 진행하는 절차를 글로 대충 적은 것인데 실제 코드를 작성했다고 치자. game.cpp 소스 파일을 만들기만 했지 아직 백업하지는 않았으므로 버전은 아니다. 현재 상태가 어떤지 status 명령으로 확인해 보자. 메시지가 영문으로 나오는데다 축약적이라 잘 읽어야 한다.

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

$ git status

On branch main

No commits yet

Untracked files:

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

game.cpp

nothing added to commit but untracked files present (use "git add" to track)

현재 main 브랜치에서 작업중이며 아직 커밋할 게 없다. 대신 untracked 파일이 하나 발견되었는데 game.cpp는 워킹트리에는 존재하지만 깃이 추적하고 있지 않은 상태이다. 괄호안에는 짧지만 핵심적인 도움말이 표시되어 있다.

백업하려면 먼저 add 명령으로 스테이지에 올려야 한다. add 명령 자체는 별 출력이 없으므로 실행 후 status로 상태를 다시 확인해 봐야 한다. 배시는 이전에 내렸던 명령을 기억하고 있으므로 위쪽 화살표를 눌러 git status 명령을 재실행하면 된다.

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

$ git add game.cpp

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

$ git status

On branch main

No commits yet

Changes to be committed:

(use "git rm --cached <file>..." to unstage)

new file: game.cpp

메시지가 어떻게 바뀌었는지 보자. Changes to be committed는 커밋할 변화가 생겼다는 뜻이다. Untracked 였던 game.cpp가 커밋 대기 상태로 바뀌었다.

파일을 스테이지에 올리면 이후 깃은 이 파일의 변화를 추적하며 커밋 대상인이 아닌지 판단한다. 즉, 항상 상태를 추적한다.

2-5.커밋

파일을 스테이지에 올리는 것은 관리 대상으로 지정한다는 뜻이지 아직 저장소로 올린 것은 아니다. 스테이지에 있는 파일을 저장소에 올릴 때는 commit 명령을 사용한다. commit은 확정이라는 뜻인데 프로젝트 중간에 백업이 필요할만큼 기능을 완성했을 때 버전으로 확정하여 저장하라는 명령이다.

commit 명령을 내릴 때는 -m 옵션으로 커밋 내용을 설명하는 메시지를 작성한다. 이 메지시는 어떤 변경을 했는지 요약적으로 설명하는데 다른 개발자가 참고할 수 있도록 가급적 상세히 붙이는 것이 좋다. -m 옵션을 생략하면 기본 편집기인 메모장이 따로 열리며 메시지 입력을 요구한다.

여기에 메지지를 입력하고 저장 후 닫아야 커밋이 완료된다. 편집기를 열면 여러 줄도 된 더 상세한 메시지를 남길 수 있다. 메시지를 작성하지 않으면 커밋은 취소된다. 즉, 메시지없이는 커밋할 수 없도록 되어 있다. 편집기를 열고 닫는게 귀찮으면 -m 옵션을 꼭 붙이자.

메시지는 한글로도 작성할 수 있고 길이 제한도 없다. 국제적인 프로젝트라면 가급적 영문으로 작성하는게 바람직하지만 실습중에 일일이 그럴 수는 없고 영어로 변경 내용을 정확히 기술하기도 어려우니 한글로 작성하자. 메시지는 공백이나 특수문자도 쓸 수 있으므로 반드시 따옴표로 감싸야 한다.

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

$ git commit -m "프로젝트 시작"

[main (root-commit) 8b8c594] 프로젝트 시작

1 file changed, 6 insertions(+)

create mode 100644 game.cpp

1개의 파일이 바뀌었으며 6줄이 삽입되었다는 뜻이다. game.cpp가 드디어 스테이지에 올라가고 저장소에도 백업되어 첫 버전이 되었다.

파일을 만들어 스테이지에 등록하고 커밋까지 했으니 현재는 워킹트리, 스테이지, 저장소의 상태가 모두 같다. 과연 그런지 상태를 확인해 보자.

$ git status

On branch main

nothing to commit, working tree clean

더 이상 커밋할게 없으며 워킹트리는 깨끗하다. 즉, game.cpp는 저장소에 백업된 것과 완전히 같은 상태로 변화가 없다는 뜻이다. 다음은 저장소에 커밋해 놓은 목록을 확인해 보자. 이때는 log 명령을 사용한다.

$ git log

commit 8b8c594f3b8c8a6b78da50924e8a78fe340f2f81 (HEAD -> main)

Author: soen <soenmaster@naver.com>

Date: Sun Oct 27 02:27:51 2024 +0900

프로젝트 시작

커밋 하나에 대한 정보를 커밋 로그라고 하는데 지금은 하나밖에 없지만 프로젝트가 진행되면 점점 쌓여갈 것이다. 이 메시지는 읽기 어려운데 정확한 뜻을 다 이해해야 한다. 첫 줄부터 차례대로 알아보자.

▶커밋 해시 : 커밋 동작에 대한 유일한 ID이며 실제 숫자는 매번 달라진다. 8b8c594... 으로 시작하는 16진수 40자리로 표기한다. 무려 20바이트(=160비트)나 되는 무지막지하게 큰 수이며 전세계에서 수만명의 개발자가 수시로 커밋해도 절대 중복되지 않는 수이다. 너무 길어 불편한데 실제로 쓸 때는 7자리까지만 쓰면 된다.

▶ HEAD : 헤드는 현재 수정중인 버전이라는 뜻인데 프로젝트 수행 흐름상의 커서라고 생각하면 된다. HEAD -> main은 현재 메인의 최상단에서 작업중이라는 뜻이다. 나중에 브랜치가 생기면 어디에서 작업중인지 헷갈릴 수 있어 작업 위치를 보여준다.

▶ Author : 누가 변경했는지 표기한다. 이 정보를 기록하기 위해 초기에 사용자 등록을 한 것이다. 이름과 메일 주소가 같이 표기된다. 여러 사람이 참여하는 프로젝트라면 이를 보고 커밋한 사람에게 메시지를 보내거나 궁금한 사항을 질문할 수 있다.

▶Date : 변경한 시간이다. 지역 시간으로 표시되며 우리나라 시간은 GMT에서 9시간 더 빨라 이 정보도 같이 표기한다. 국제적인 프로젝트에서는 지역까지 알아야 정확한 시간을 알 수 있다.

▶메시지 : 이 커밋에서 어떤 동작을 했는지 개발자가 남긴 메시지를 보여 준다. 소스를 일일이 보지 않아도 메시지를 보면 변경 사항을 대충 알 수 있다. 그래서 커밋 메시지를 상세하게 작성해야 한다.

비록 소스는 하나밖에 없지만 프로젝트 전체를 저장소에 안전하게 버전으로 만들어 두었으므로 이제 워킹트리가 어찌되어도 상관없다. 언제든지 저장소에 보관해둔 버전을 다시 가져오거나 원상 복구할 수 있다.

2-6.스테이징 후 커밋

게임의 첫 버전을 만들어 커밋까지 완료했다. 이제 기능을 계속 확장해 보자. 현재 소스는 주인공이 딱 하나만 나오고 죽으면 끝나 버린다. 이러면 너무 시시한데 3번 정도는 기회를 줘야 한다. for 루프로 감싸 주인공 3대가 죽을 때까지 게임을 반복한다.

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

for (1~3) {

while (죽을 때까지) {

주인공 이동

적군 이동

총알 발사 및 충돌 점검

}

}

실제로는 주인공이 폭파되는 그래픽 처리와 실감나는 사운드도 나와야 하지만 반복만 하도록 했다. 중요한 변화가 생겼으므로 버전으로 커밋하자. 이 파일을 저장하면 워킹트리의 소스는 바뀌고 스테이지와 저장소의 소스는 이전 상태 그대로이다.

워킹트리의 game.cpp를 수정했는데 스테이지의 game.cpp는 수정한 이전 버전이다. 따라서 add 명령으로 스테이지에 먼저 올린 후 저장소로 커밋해야 한다. 원칙적으로는 다음 두 명령을 순차적으로 내려야 한다.

$ git add game.cpp

$ git commit -m "주인공 3대로 늘림"

add에 의해 워킹트리의 소스가 스테이지로 복사되고 commit에 의해 스테이지의 소스가 저장소로 올라간다. 소스를 수정할 때마다 매번 두 명령을 반복하는 것은 너무 귀찮은 일이다. 그래서 두 명령을 하나로 합쳐 커밋하는 방법을 제공한다.

$ git commit -am "주인공 3대로 늘림"

[main 7a9c088] 주인공 3대로 늘림

1 file changed, 6 insertions(+), 4 deletions(-)

commit의 -am 옵션은 add 먼저 한 후 message 내용으로 커밋한다. 어차피 스테이지를 경유해야 커밋할 수 있으므로 두 동작을 한꺼번에 수행하는 것이 편리하다. 단, 이 명령은 스테이지에 이미 올린 파일에 대해서만 쓸 수 있으며 새로 만든 파일에는 적용할 수 없다. 미추적 상태의 파일은 일단 add를 먼저 해야 한다.

파일 하나가 변경되었고 7줄 삽입하고 6줄을 삭제했다고 보고한다. 실제 변화보다는 다소 과장되게 평가하는데 들여쓰기를 수정한 것도 바꾼 것으로 보기 때문이다. 커밋까지 한꺼번에 다 해 버렸으니 status를 찍어 보면 더 할게 없다고 나타난다. 로그에는 어떻게 기록되어 있는지 출력해 보자.

$ git log

commit 7a9c088d2b57d0b86eefffda86baeca7f11d4374 (HEAD -> main)

Author: soen <soenmaster@naver.com>

Date: Sun Oct 27 02:32:00 2024 +0900

주인공 3대로 늘림

commit 8b8c594f3b8c8a6b78da50924e8a78fe340f2f81

Author: soen <soenmaster@naver.com>

Date: Sun Oct 27 02:27:51 2024 +0900

프로젝트 시작

커밋 로그가 하나 더 늘어났다. 로그는 추가한 역순으로 표시하며 화면상의 제일 위에 있는 로그가 가장 최근에 실행한 커밋이다. 앞으로 계속 늘어날 것이다.

2-7.사운드 추가

게임은 모름지기 소리가 나야 재미있다. 이제 사운드 기능을 추가해 보자. 사운드는 별도의 기능이므로 메인 모듈에서 직접 하는 것보다는 sound.cpp 소스를 따로 만드는 것이 좋다. 메모장으로 새 파일을 만들고 다음 소스를 작성한다.

배경 음악을 재생하는 함수와 효과음을 내는 함수를 만들었다. 게임에서는 적절한 시점에 함수를 호출하여 소리를 출력하면 된다. game.cpp에 사운드를 재생하는 코드를 작성한다.

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

for (1~3) {

배경음악 재생 시작

while (죽을 때까지) {

주인공 이동

적군 이동

총알 발사 및 충돌 점검

적군 죽으면 효과음

}

배경음악 재생 정지

}

새 모듈에 필요한 함수를 작성하고 메인에서 이 함수를 호출하여 원하는 작업을 수행하는 예이다. 기능을 추가할 때마다 소스 파일도 계속 늘어난다. 여기까지 작업한 후 상태를 출력해 보자.

$ 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

Untracked files:

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

sound.cpp

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

game.cpp는 워킹트리에서 수정했지만 아직 스테이지에는 올리지 않아 커밋 준비가 안된 상태이다. sound.cpp는 새로 만든 파일이라 미추적 상태이다. 이 둘을 커밋하려면 먼저 스테이지에 올려야 한다.

$ git add game.cpp sound.cpp

add 명령의 인수로 스테이지로 올릴 파일을 나열한다. 원하는 파일만 선별적으로 지정할 수 있지만 개수가 많으면 일일이 적느라 불편하다. 이럴 때는 git add . 명령으로 현재 디렉토리의 모든 파일을 지정하면 된다. 두 파일을 스테이지로 올리고 상태를 확인해 보자.

$ git add .

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

new file: sound.cpp

지금은 소스 파일이 2개 밖에 없으니 개별 파일을 올리나 디렉토리를 통째로 올리나 효과는 같다. 그러나 다른 파일이 더 있고 수정한 파일의 일부만 올린다면 이 둘은 달라지니 가급적이면 파일명을 구체적으로 명시하는게 안전하다.

game.cpp는 내용이 수정되었고 sound.cpp는 새로 만든 파일로 표시되어 있으며 둘 다 스테이지에 올렸으므로 커밋할 수 있는 상태이다. 커밋해 보자. 이때는 -am 옵션을 줄 필요는 없고 -m으로 메시지만 전달하면 된다.

$ git commit -m "배경음악 및 효과음 추가"

[main eb4622b] 배경음악 및 효과음 추가

2 files changed, 10 insertions(+)

create mode 100644 sound.cpp

2개의 파일이 바뀌었으며 10줄을 추가했다. 로그를 찍어 보면 방금 커밋한 것까지 3개의 커밋 로그가 나타난다.

$ git log

commit eb4622bb171021f99e1188f538ca0f117aedb6ca (HEAD -> main)

Author: soen <soenmaster@naver.com>

Date: Sun Oct 27 03:03:08 2024 +0900

배경음악 및 효과음 추가

...

커밋 로그의 메시지는 누가 어떤 작업을 했는지를 요약적으로 보여주며 이 로그를 통해 사운드 기능을 추가했음을 알 수 있다. 그러나 어떤 파일을 바꿨는지는 표시하지 않는데 왜냐하면 한번에 수십개의 파일을 바꿀 때 일일이 표시하자면 핵심 변경 내용이 잘 보이지 않기 때문이다.

더 상세한 변경 사항을 알고 싶다면 --stat 옵션을 사용한다. 어떤 파일을 어떻게 바꾸었는지까지 다 보여 주어 상세하지만 대신 목록이 길어지는 불편함이 있다. 고작 세번 커밋했는데도 양이 굉장이 많다.

$ git log --stat

commit eb4622bb171021f99e1188f538ca0f117aedb6ca (HEAD -> main)

Author: soen <soenmaster@naver.com>

Date: Sun Oct 27 03:03:08 2024 +0900

배경음악 및 효과음 추가

game.cpp | 3 +++

sound.cpp | 7 +++++++

2 files changed, 10 insertions(+)

commit 7a9c088d2b57d0b86eefffda86baeca7f11d4374

Author: soen <soenmaster@naver.com>

Date: Sun Oct 27 02:32:00 2024 +0900

주인공 3대로 늘림

game.cpp | 10 ++++++----

1 file changed, 6 insertions(+), 4 deletions(-)

commit 8b8c594f3b8c8a6b78da50924e8a78fe340f2f81

Author: soen <soenmaster@naver.com>

Date: Sun Oct 27 02:27:51 2024 +0900

프로젝트 시작

game.cpp | 6 ++++++

1 file changed, 6 insertions(+)

목록이 이렇게 길어지면 한 화면에 다 표시하지 못하고 스크롤해 가며 봐야 한다. 아래, 위 커서키나 PgUp, PgDn 키로 오르락 내리락 할 수 있다. 배시에 익숙하지 않은 사람은 스크롤 모드를 빠져 나오지 못해 당황해 하는데 Q키를 누르면 된다.

로그가 너무 길면 확실히 보기 불편해지며 한꺼번에 수십 개의 파일을 수정했다면 지저분하기까지 하다. 이럴 때는 --oneline 옵션으로 로그당 한줄씩만 표시하도록 한다. 작업자와 시간 등은 상세히 알 수 없지만 전체적인 흐름은 간략히 살펴볼 수 있다.

$ git log --oneline

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

7a9c088 주인공 3대로 늘림

8b8c594 프로젝트 시작

7자리의 짧은 커밋해시와 메시지만 표시한다. 시간순으로 어떤 작업을 진행했는지 요약적으로 파악할 수 있다. 로그가 많이 쌓여 있는 프로젝트는 구체적인 변경 내용보다는 커밋한 사람이 남겨 놓은 메시지로 진행 상황을 파악하는 것이 더 빠르다.