4.브랜치

4-1.브랜치

프로젝트 진행은 보통 직선적이며 기획서 지시대로 코드 작성하고 테스트하고 수정하는 과정의 연속이다. 상황이나 환경에 따라 약간씩 달라지는 부분은 조건부 컴파일 등으로 처리해 가며 여러 가지 시도를 해 보기도 한다.

그러나 기존 구조를 완전히 뜯어 고쳐야 할 정도로 획기적인 기능을 도입해야 할 때도 있고 동시에 두 가지 이상의 환경을 지원하도록 입체적인 개발을 병행하기도 한다. 진행 방식이 복잡해지면 프로젝트 코드에 충격이 가해지는데 몇 가지 예를 들어 보자.

1.덩치 큰 시범적인 기능을 테스트한다. 게임 캐릭터에 애니메이션을 넣는다거나 시점을 바꿀 수 있는 3차원 효과를 넣을 때는 기존 코드와 대판 달라진다. 이 기능이 좋은지 아닌지 만들어 봐야 평가할 수 있어 테스트 후 적용하거나 아니면 아예 폐기할 수도 있다.

2.다른 구조를 도입하여 새로운 게임을 만든다. 정지 화면에서 캐릭터만 움직이는 방식에 비해 스크롤을 하면 배경이 같이 움직여야 한다. 기존 게임은 그대로 개발하고 이 코드를 기반으로 스크롤 게임을 새로 만들 수 있다.

3.이 게임이 굉장히 히트를 쳤고 엔진의 성능이 입증되어 다른 회사에서 군침을 질질 흘린다면 엔진만 따로 팔 수도 있다. 고객사마다 3차원으로 해 달라거나 모바일용으로 제작해 달라는 요구를 할 것이다. 각 요구에 대해 새로운 딴 살림을 차리면 된다.

시범적인 기능이나 과격한 변화도 시도해 볼 필요가 있고 수요가 있다면 완전히 다른 제품을 만들어 팔 수도 있다. 기존 프로젝트를 기반으로 하더라도 꼭 원본을 파괴해야 하는 것은 아니다. 원본은 원래 진행하던 개발을 계속 하고 이 원본을 기준으로 새로운 개발을 시작하면 된다.

이처럼 잘 진행되던 흐름에서 방향을 틀어 새로운 프로젝트를 하나 더 만드는 것을 브랜치(branch)라고 한다. 뿌리에서 줄기가 나와 위로 뻗다가 적당한 높이가 되면 가지를 뻗는 것처럼 기존 프로젝트를 기반으로 새로운 프로젝트를 만드는 것이다. 가지의 개수는 제한이 없고 필요할 때 얼마든지 만들 수 있다.

브랜치는 원래 프로젝트와는 별개의 흐름을 가진다. 아예 갈라섰기 때문에 원본 브랜치에는 영향을 미치지 않고 독립적인 개발을 자유롭게 진행할 수 있다. 브랜치를 진행해 본 결과 마음에 들면 원본 브랜치와 합칠 수도 있고 영 시원찮으면 폐기할 수도 있다.

버전관리툴은 대부분 브랜치를 지원하며 프로젝트 관리의 핵심 기능이다. 브랜치는 흐름을 분리하여 원본을 유지한 채로 자유로운 시도를 해 볼 수 있는 멋진 기능이다. 원리만 알면 부담없이 활용할 수 있다. A, B, C 세 가지 방법을 모두 구현하여 테스트해 보고 싶다면 각각 브랜치를 만들어 돌려 보고 그 중에 마음에 드는 하나를 선택하면 된다.

4-2.scroll 브랜치

지금까지 개발한 game 프로젝트를 기반으로 스크롤 기능을 추가한 새로운 브랜치를 만들어 보자. 이는 game 프로젝트를 수정하여 스크롤 기능을 추가하는 것과는 다르다. 기존의 game은 그대로 놔두고 브랜치로 사본을 뜬 후 여기에 스크롤을 추가한다.

두개의 개발 가지가 생기며 스크롤 기능을 어떻게 구현하더라도 game이 영향을 받지는 않는다. 전통적인 프로젝트 관리 방법으로는 game 프로젝트 폴더를 복사하여 scroll 폴더에 사본을 뜨고 여기서 개발하는 것과 비슷하다.

그러나 깃은 브랜치로 나눈 후 브랜치끼리 비교하거나 병합을 지원한다는 면에서 수준이 더 높다. 브랜치는 변화를 잘 관찰해야 개념을 파악할 수 있으므로 이후의 실습은 꼭 직접 해 봐야 한다. 눈으로만 봐서는 확실히 알기 어렵다. 현재 브랜치 상태를 확인할 때는 다음 명령을 사용한다.

$ git branch

* main

현재 main 브랜치 하나밖에 없고 이 브랜치가 활성화되어 있다는 의미로 * 표시가 붙어 있다. main은 git init로 초기화할 때 만들어진 기본 브랜치이며 모든 편집은 이 브랜치를 대상으로 한다. 새로운 브랜치를 만들 때는 branch 명령 다음에 새 브랜치의 이름을 지정한다. scroll 브랜치를 만들어 보자.

$ git branch scroll

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

$ git switch scroll

Switched to branch 'scroll'

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

$ git branch

main

* scroll

브랜치를 만들었다고 해서 당장 큰 변화가 발생하지는 않으며 현재 브랜치는 여전히 main이다. switch 명령으로 활성 브랜치를 scroll로 변경한다. 이제 브랜치 상태를 확인해 보면 두 개의 브랜치가 있고 활성 브랜치에 *가 표시되어 있다. 프롬프트에 현재 브랜치가 (scroll)임을 표시한다.

이후부터 소스에 가해지는 모든 변화는 활성 브랜치를 대상으로 한다. 기존 브랜치의 소스를 그대로 물려만 받았으니 이 상태에서 git status를 찍어 보면 아무 것도 커밋할게 없다. game.cpp에 다음 코드를 작성하자.

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

for (1~3) {

경쾌한 배경음악 재생 시작

while (죽을 때까지) {

주인공 이동 - 추진 불꽃 그림

적군 이동

총알 발사 및 충돌 점검

적군 죽으면 효과음

가끔 대장 등장, 폭탄 발사

배경 화면 아래로 이동

}

배경음악 재생 정지

}

세 가지가 바뀌었다. 루프 끝에 배경 화면을 이동하는 처리를 추가하여 세로로 스크롤하도록 했다. 주인공이 계속 전진하는 상황이므로 꼬랑지에 추진 불꽃을 표시하고 배경 음악도 더 신나는 걸로 바꾸었다. 커밋한다.

$ git commit -am "배경 화면 스크롤"

[scroll ac1f9ee] 배경 화면 스크롤

1 file changed, 3 insertions(+), 2 deletions(-)

이 커밋은 활성 브랜치인 scroll 브랜치에 기록된다. 로그를 찍어 보고 커밋 해시 다음에 괄호 안에 있는 정보를 유심히 보자.

$ git log

commit 5ca5be5655f0a07b4354260ac701cce0e5ad3b58 (HEAD -> scroll)

Author: soen <soenmaster@naver.com>

Date: Mon Oct 28 00:04:52 2024 +0900

배경 화면 스크롤

commit 1569140a27464e362604e7849ad55c086938af08 (main)

Author: soen <soenmaster@naver.com>

Date: Sun Oct 27 23:46:06 2024 +0900

무시할 파일 등록

무시할 파일을 등록한 것까지는 main 브랜치에 대한 변경이다. 배경 화면을 스크롤하는 기능은 scroll 브랜치에 기록되며 HEAD -> scroll은 현재 작업 위치가 scroll 브랜치임을 표시한다. 그렇다면 이 상태에서 main의 상태는 어떤지 스위칭해 보자.

$ git switch main

Switched to branch 'main'

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

$ git branch

* main

scroll

활성 브랜치가 main으로 바뀌고 프롬프트에도 표시된다. main 브랜치는 개발이 끝난게 아니고 scroll과는 별도로 계속 진행중이다. 깃은 스위칭한 브랜치의 마지막 버전을 워킹트리로 복사한다. 스위칭한 후 워킹트리의 game.cpp를 보면 스크롤 기능을 작성하기 전의 상태로 돌아온다.

브랜치끼리는 독립적이어서 다른 브랜치에서 수정한 내역은 활성 브랜치에서는 보이지 않는다. main에는 대장을 죽일 때 주인공 옆에 졸개 둘을 붙여 업그레이드하는 기능을 넣어 보자. 그래야 단계가 올라갈 때마다 게임하는 맛이 난다.

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

for (1~3) {

배경음악 재생 시작

while (죽을 때까지) {

주인공 이동 - 가속도 적용

적군 이동

총알 발사 및 충돌 점검

적군 죽으면 효과음

가끔 대장 등장, 폭탄 발사

보스 사망시 주인공에 보조 비행체 합체

}

배경음악 재생 정지

}

잘 동작하는지 확인한 후 커밋한다. 브랜치를 나눈 후에도 main을 진행할 수 있는지 확인해 보는 것이다.

$ git commit -am "보조 비행체 합체"

이 변화는 현재 활성 브랜치인 main에 적용되며 scroll 브랜치와는 무관하다. 과연 그런지 로그를 찍어 보자.

$ git log

commit f16d1ac0b02cde45b71ba2521730585828a2c18a (HEAD -> main)

Author: soen <soenmaster@naver.com>

Date: Mon Oct 28 00:08:49 2024 +0900

보조 비행체 합체

commit 1569140a27464e362604e7849ad55c086938af08

Author: soen <soenmaster@naver.com>

Date: Sun Oct 27 23:46:06 2024 +0900

무시할 파일 등록

배경 화면 스크롤에 대한 로그는 보이지 않고 보조 비행체 합체까지만 보인다. scroll 브랜치로 스위칭하면 game.cpp에 배경 스크롤 코드가 다시 나타난다. 대신 main에서 작업했던 합체 기능은 보이지 않는다. 여기에 장애물을 등장시키는 처리를 추가해 보자.

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

for (1~3) {

경쾌한 배경음악 재생 시작

while (죽을 때까지) {

주인공 이동 - 추진 불꽃 그림

적군 이동

장애물 등장. 주인공과 충돌시 사망

총알 발사 및 충돌 점검

적군 죽으면 효과음

가끔 대장 등장, 폭탄 발사

배경 화면 아래로 이동

}

배경음악 재생 정지

}

스크롤 게임은 적군 뿐만 아니라 날라오는 돌맹이나 파편같은 장애물도 피해야 한다. scroll 브랜치에 커밋한다.

$ git commit -am "장애물 추가"

이런 식으로 각자의 브랜치에서 소스를 계속 수정하면 두 브랜치의 game.cpp는 점점 달라진다. 서로 영향을 미치지 않고 각자 갈 길을 가는 것이다.

4-3.브랜치 로그

main 브랜치만 있을 때는 로그가 시간의 역순으로 나열되므로 작업 현황을 쉽게 파악할 수 있다. 그러나 브랜치는 커밋이 나란히 진행되는데다 시간 순서가 뒤죽박죽이라 헷갈린다. 두 개만 해도 보기 어려운데 브랜치가 서너개쯤 되면 정신을 못 차릴 정도다. 그래서 로그를 잘 보는 방법부터 익혀야 한다.

git log 명령은 활성 브랜치의 커밋만 보여준다. 프로젝트를 총괄하는 입장에서는 각 브랜치가 어떤 식으로 진행되고 있는지 한눈에 볼 필요가 있다. --brancehs 옵션은 현재 브랜치 뿐만 아니라 브랜치별 커밋을 모두 보여준다. 전체 로그를 상세히 보면 너무 복잡하니 --oneline과 함께 쓰는 것이 좋다.

$ git log --oneline --branches

f052a4f (HEAD -> scroll) 장애물 추가

f16d1ac (main) 보조 비행체 합체

5ca5be5 배경 화면 스크롤

1569140 무시할 파일 등록

지금은 scroll 브랜치에서 작업중이지만 main에 커밋한 것도 같이 보여 준다. 이 목록을 보면 어느 브랜치에서 어떤 작업을 진행하고 있는지 시간역순으로 확인할 수 있다.

-- graph 옵션은 브랜치간의 커밋 관계를 그래프 형태로 보여준다. 어느 기능까지 구현하고 갈라졌는지, 이후에 어떤 순으로 진행했는지 볼 수 있다. 브랜치간의 관계를 보는 것이므로 --brancehs 옵션과 함께 사용해야 한다.

$ git log --branches --oneline --graph

* f052a4f (HEAD -> scroll) 장애물 추가

* 5ca5be5 배경 화면 스크롤

| * f16d1ac (main) 보조 비행체 합체

|/

* 1569140 무시할 파일 등록

비록 텍스트 화면에서 직선으로 표현하지만 브랜치간의 기능 추가 상황을 어느 정도 파악할 수 있다. 그래프 표현을 위해 커밋한 순서와는 약간 다르게 표시되는데 사실 브랜치간에는 커밋한 순서가 중요하지 않다.

main에서 무시할 파일 등록 이후 scroll 브랜치로 갈라져 스크롤 기능과 장애물 추가 기능이 들어갔고 main에는 합체 기능이 들어갔음을 알 수 있다. 그래픽으로 이 상항을 그려 보면 다음과 같다.

갈라진 이후에 두 브랜치는 각자 갈 길을 갈 것이며 서로 영향을 미치지 않는다. main에 다른 기능을 더 테스트해 보고 싶으면 브랜치를 또 나눌 수 있고 scroll도 마찬가지이다.

브랜치끼리 어떤 기능이 추가되었는지 비교할 때는 A..B 형식으로 두 브랜치를 비교한다. 순서가 중요한데 A를 기준으로 B 브랜치에 추가 작업한 내역을 표시한다.

$ git log --oneline main..scroll

f052a4f (HEAD -> scroll) 장애물 추가

5ca5be5 배경 화면 스크롤

main을 기준으로 scroll에는 배경화면 스크롤과 장애물 추가 기능이 더 들어갔음을 알 수 있다. 순서를 반대로 바꿔 보자.

$ git log --oneline scroll..main

f16d1ac (main) 보조 비행체 합체

scroll 브랜치를 기준으로 main에는 합체 기능이 더 들어갔다. 이렇게 비교해 보면 갈라진 후 추가한 작업 목록을 파악할 수 있다.

4-4.브랜치 시나리오

분리한 브랜치를 나중에 어떻게 처리할 것인가는 여러 가지 시나리오가 있다. 일단을 독립적으로 개발하되 원하는 목적을 달성한 후 진행 상황에 따라 자유롭게 판단해서 결정하면 된다. main에서 sub 브랜치로 분기한 경우 sub를 처리하는 몇 가지 예를 들어 보자.

1.sub를 시험삼아 만들어 보니 main과는 다르게 나름대로 활용성이 있어 따로 개발하기로 한다. 즉, 영원히 갈라서는 것인데 이런 예는 흔하다. mysql에서 mariadb가 갈라지고 open office에서 libre office가 갈라졌다. 이들은 한반 갈라선 후 다시 합치지 않는다. 대표적인 예가 리눅스 배포판인데 현재 수백개의 브랜치로 갈라져 각자 개발하고 있다.

2.sub를 테스트해 보니 택도 아닌 시도였음이 밝혀졌다. 될거 같아서 브랜치 따서 개발해 봤는데 득보다 실이 많다. 이 경우는 sub를 미련없이 폐기하면 된다. 택도 아닌 뻘짓을 했더라도 main에는 아무런 피해가 없다.

3.sub에서 테스트한 기능이 안정적이고 훌륭한 것으로 판명되었다. 이 기능이 과연 쓸만할까 반신반의하며 시도했는데 충분히 점검해 보니 쓸만하다. 이런 경우는 sub에서 완성한 기능을 다시 main에 합치는데 이를 병합이라고 한다.

4.특수한 예로 sub가 main보다 더 훌륭하고 괜찮은 경우도 있다. 반면 main은 갈수록 엉망이 되어 가고 있다면 아예 main을 폐기하고 이후 sub로 개발을 진행할 수도 있다. 이런 상황을 청출어람이라고 한다.

브랜치 처리의 가장 흔한 예는 병합이다. 사용하는 논리가 독특하거나 개발팀이 달라 브랜치를 분리했다가 브랜치에서 기능 점검을 마치고 다시 하나로 합친다. 예를 들어 게임의 그래픽 부분만 대폭 보강하기 위해 그래픽 전문가에 브랜치를 따 맡기고 그 와중에 게임은 운영 로직만 수정한다. 그래픽 브랜치가 핵심 기능을 훌륭하게 완성해 놓았으면 main에 합쳐 잘 써 먹으면 된다.

이러면 두 브랜치를 병렬로 돌릴 수 있어 개발 기간을 단축할 수 있고 서로 각자의 부분만 전담할 수 있는 이점이 있다.그러나 병합도 그리 간단한게 아니라 케이스별로 방법이 다르다. 이혼했다 재결합하는거니 어찌 간단하겠는가? 다음 절에서 케이스별로 하나씩 연구해 보자.