Adjust `makeover` to handle newer AsciiDoc output.

[gitmagic.git] / ko / branch.txt

== 브랜칭 마법 ==

Git의 끝내주는 기능들 중에는 즉석으로 브랜칭 (brancing) 및 병합 (merging)이 가능하다는 것입니다.

*예시*: 외부적인 요소들은 가끔 불가피하게 당신이 하던 일을 그만두게 합니다. 예를 들어, 치명적인 버그가 경고없이 퍼져나가게 생겼습니다. 프로그램에 새로 넣어야 할 기능이 있는데 데드라인은 가까워져 옵니다. 당신이 도움을 요청하고자 했던 개발자는 퇴사할려고 하니 도움을 요청할 수도 없고요. 시간이 촉박한 만큼 하던 일을 멈추고 버그를 고치는 데에 올인을 해야겠지요.

위의 예시와 같이 하던 일을 갑자기 멈추는 것은 일의 생산성을 치명적으로 떨어트립니다. 특히나 지금까지 하던 일과 정 상관없는 부분의 프로그램을 건들어야 할 때 말이죠. 이럴 때, 중앙관리식 VCS를 사용하는 경우엔 버그없는 버전의 프로그램을 새로 다시받아야 할껍니다. 분산관리식 VCS일 경우에는 원하는 버전만 로컬 컴퓨터로 받아내면 되죠.

하지만 클로닝은 작업 중인 디렉토리 포함 그 디렉토리의 히스토리를 어느 선까지는 같이 다운로드 받게 합니다. Git은 최대한 효율성있게 시스템이 디자인되어 있긴하지만, 클로닝 명령어를 쓴다면 프로젝트 파일들이 (비효율적으로) 현재 작업 중인 디렉토리에 전부 다시 생성될 것입니다.

*해답*: Git은 이런 상황에서 좀 더 빠르고 공간적으로 효율성있게 클로닝을 할 수 있는 명령어를 가지고 있습니다: *git branch*

이런 환상적인 명령어를 이용하여 디렉토리에 있는 파일들은 탈바꿈을 감행해 이 버전과 저 버전을 넘나들 수 있습니다. 이 변형기법은 버전 사이를 넘나드는 것 외에도 더 많은 것을 할 수 있습니다. 당신의 프로젝트는 브랜칭을 통해 구버전에서 임시버전, 개발버전, 친구들이 보유하고 있는 버전 등으로 아무렇게나 변형할 수 있습니다.

=== 일하는 척 하기 버튼 ===

버튼 하나만 누르면 ("일하는 척 하기 버튼") 게임화면이 최소화되고 엑셀파일이 화면상에 나타나는 기능을 보신 적이 있을겁니다. 이 기능을 활용하면 직장상사의 눈을 속이고 일하던 척 할 수 있지요?

어떤 디렉토리에서:

 $ echo "I'm smarter than my boss" > myfile.txt # 난 내 상사보다 똑똑하다
 $ git init
 $ git add .
 $ git commit -m "Initial commit"

우리는 "난 내 상사보다 똑똑하다"라는 내용을 가진 텍스트파일을 Git repository에 만들었습니다. 그리고:

 $ git checkout -b boss  # 이 명령어를 사용한 후엔 아무것도 바뀌지 않은 것처럼 보일겁니다.
 $ echo "My boss is smarter than me" > myfile.txt 
 $ git commit -a -m "Another commit"

겉으로 보기에는 그 텍스트파일을 새로운 문장으로 덮어씌우고  commit을 한 것처럼 보일겁니다. 그러나 그건 착각입니다. 다음 명령어를 입력해보세요:
 
 $ git checkout master  # 처음 버전으로 돌아가기

자! 그럼 처음 생성했던 텍스트파일이 돌아왔을 겁니다. 만약에 그 상사가 이 사실을 알아채고 당신의 디렉토리를 살펴본다고 할 때는:
 
 $ git checkout boss  # 아까 두 번째로 만들어놓은 "상사는 나보다 똑똑합니다"라는 메세지를 담은 myfile.txt 파일로 돌아갑니다.

이런 식으로 두 가지 다른버전의 파일 사이를 오갈 수 있습니다. 그리고 각각 따로 commit을 할 수 있지요.
 
=== 힘든 작업 ===

[[branch]]
당신이 어떤 작업을하고 있다고 가정합니다. 작업 도중에 세 버전 전으로 돌아가서 새로운 print 라인을 넣고 테스팅 해보고 싶다는 생각이 들었습니다. 그럴 때엔:

 $ git commit -a
 $ git checkout HEAD~3

이제 테스팅하고 싶었던 파일에 더하고 싶은 것을 걱정없이 마구 넣어도 됩니다. 이 미친 짓(?)을 commit 해놓을 수도 있습니다. 작업이 다 끝났다면,
 
 $ git checkout master

를 사용해 아까 미친 짓을 하기 전의 작업상태로 돌아올 수 있습니다. Commit하지 않았던 작업들이 같이 딸려 왔다는 것을 확인 (조심!)할 수 있을 겁니다.
 
아까 그 임시작업 (미친 짓)을 세이브하고 싶다면 어떻게 해야할까요? 쉽습니다:
 
 $ git checkout -b dirty

를 실행하여 그 나뭇가지 (branch) 에서 마스터 나뭇가지로 돌아오기 전에 commit을 하면 됩니다. 그런 후 다시 미친 짓을 할 때의 상태로 돌아가고 싶다면:

 $ git checkout dirty

우리는 이 체크아웃이라는 명령어를 전에도 설명했었죠. 여기서는 이 명령어가 어떻게 예전 버전들을 불러오는 지 살펴볼 수 있었습니다: 파일을 원하는 버전으로 돌아가게 할 수 있으나, master 나뭇가지를 우선 벗어나야 하지요. 벗어난 후의 commit은 master 나뭇가지와는 다른 길을 걷게 될 것입니다. 그 길을 나중에 이름도 지어줄 수 있지요.
 
다시 말하면, 예전 상태 (state)에서 벗어나면 Git은 자동으로 이름이 없는 새로운 나뭇가지로 이동시켜 줍니다. 이 나뭇가지는 *git checkout -b*로 이름을 바꿔 저장해줄 수 있죠.

=== 빠른 코드수정 ===

작업 중에 갑자기 하던 일을 멈추고 '1b6d...'commit에 있는 버그를 고치라고 부탁을 받았다고 생각해 봅시다:

 $ git commit -a
 $ git checkout -b fixes 1b6d

버그를 다 고친 후에:
 
 $ git commit -a -m "Bug fixed"
 $ git checkout master

이제 아까 잠시 중단했던 작업으로 돌아갈 수 있습니다. 버그가 고쳐진 파일도 병합해올 수 있죠:

 $ git merge fixes

=== 병합 (Merging) ===

Git을 제외한 다른 VCS들을 이용할 땐 나뭇가지 (branch)들을 만드는 것은 쉽지만 
나뭇가지들을 병합하기는 어려웠습니다. Git에서는 병합작업이 정말 쉽고
병합이 진행되고 있는 중인지 우리도 모르는 사이에 끝날 것입니다.

병합은 전에도 소개했었습니다. '당겨오기 (pull)' 명령어는 
commit들을 가져와 지금 머물고있는 branch에 병합하여 줍니다. 로컬에서 아무런 
작업을 진행하지 않았더라면 *pull*은 현 branch를 '빨리 감기' 하여 
중앙 서버에서 가장 최근의 정보를 가져와 병합합니다. 로컬에서 작업을 한
기록이 있었다면, Git은 자동으로 병합을 시도할 것이고, 병합 중에 버전간의 차질이 있다면 당신에게 친절히 알려줄 것 입니다.

Commit은 보통 하나의 '부모 commit'이 (과거의 commit) 있습니다. 그러나 병합을 하게 된다면
하나의 commit이 적어도 '아버지 commit'와 '어머니 commit' 이 있다고 생각할 수 있는 것이죠.
그럼 'HEAD~10'은 어떤 commit을 가르키는 걸까요? 부모 commit 두 개 이상이라면
어떤 commit을 받아 순조롭게 작업을 계속 진행할 수 있을까요?

Git은 먼저 시간적으로 제일 먼저 commit되었던 부모를 따르게 설정되어 있습니다. 현재 작업중인
branch가 병합이 실행될 경우 이 branch 자체가 첫번째 부모가 되기때문에 당연한 겁니다:
당신은 언제나 현 나뭇가지에서 가장 최근에 한 작업에만 관심이 있을 가능성이 크기 때문이지요.
다른 나뭇가지에서 한 작업은 다음 일입니다.

탈자 기호 (^)를 이용하서 부모를 수동으로 정해줄 수도 있습니다. 예를 들어
두번째 부모의 기록을 조회하고 싶다면:

 $ git log HEAD^2

첫번째 부모의 기록을 조회할 때는 탈자기호 이후의 번호는 생략해도 됩니다. 
굳이 보여드리자면:

 $ git diff HEAD^

이 표기법은 다른 형식의 표기법과도 병행해서 사용할 수 있습니다:
 
 $ git checkout 1b6d^^2~10 -b ancient

(집중하십시오) 새로운 나뭇가지인 "ancient"를 시작하고 두번째 부모의 첫번째 부모 나뭇가지에서 
1b6d로 시작하는 commit과 그 commit 전 10개의 commit을 불러와 줄 것입니다.

=== 방해받지 않는 작업진행 ===

하드웨어 관련작업을 하다보면 현재 작업중인 단계가 완료되어야만 다음 단계 진행이 가능할 것입니다. 자동차를 예로들면 외부로부터 오기로했던 부품들이 도착해야 비로소 수리에 들어갈 수 있겠지요. 프로토타입들은 칩들이 가공되어야 건축이 가능해 지겠죠.

소프트웨어 관련작업도 비슷합니다. 다음 작업이 진행될려면 
현재 작업이 이미 발표 및 테스트가 되어있어야 할 겁니다. 어떤 작업들은
당신의 코드가 받아 들여지기 전 검토부터 되어야 겠지요. 그래서 당신은 그 검토가
끌날 때까지는 다음 작업으로 진행하지 못 할것입니다.

하지만 나뭇가지와 병합기능 덕분에 이 규칙을 깨고 파트 1이 완료되기도 전에
파트 2에서 미리 작업을 진행하고 있을 수 있습니다. 파트 1을 commit하고 
검토를 위해 어디론가 보냈다고 생각해봅시다. 만약 당신이 Master 나뭇가지에서 작업하고 있었다면,
그 branch에서 다른 branch로 갈아타야합니다:

 $ git checkout -b part2

그리곤 파트 2에서 commit을 하며 작업을 계속 진행하세요. 인간은 실수를 많이하는 동물이기에
파트 1으로 다시 돌아가서 무엇인가 고치고 싶을지도 모릅니다.
만약에 당신이 천재적인 프로그래머라면 다음 명령어를 사용할 일은 없겠지요.

 $ git checkout master  # 파트 1로 돌아갑니다.
 $ fix_problem # 수정 작업
 $ git commit -a        # 수정 작업을 commit합니다.
 $ git checkout part2   # 파트 2로 다시 갑니다.
 $ git merge master     # 아까 파트 1의 수정을 파트 2로 병합합니다.

이 때 즈음이면 이미 파트 1은 허가 받았겠지요.
 
 $ git checkout master  # 파트 1로 돌아갑니다.
 $ submit files         # 파일 배포!
 $ git merge part2      # 파트 2도 파트 1으로 병합.
 $ git branch -d part2  # 파트 2 나뭇가지 삭제.

이제 파트 2의 모든 것과 함께 업데이트 된 master 나뭇가지로 돌아왔습니다.
 
 branch는 갯수의 제한 없이 원하는 만큼 생성할 수 있습니다. 역순으로 branch를 만들 수도
 있죠: 만약에 7번의 commit전에 나뭇가지를 하나 만들어 놓았어야 함을
 늦게 깨닫았을 때, 다음 명령어를 이용해 보세요:

 $ git branch -m master part2  # master 나뭇가지의 이름을 part2로 바꿉니다.
 $ git branch master HEAD~7    # 7 commit 전의 상황에서 master 나뭇가지를 새로 만듭니다.

Master 나뭇가지는 이제 part 1만 들어있고, 나머지는 모두 part 2에 들어가게 되었습니다.
그리고 우리는 지금 part 2에서 작업을 하고 있는 중이겠지요; master를 만들면서 master로는
현재 옮겨간 상태가 아닙니다. 처음 보시죠? 여태까지 설명한 예제들에서는
나뭇가지를 만들면서 곧바로 작업공간도 같이 옮겨갔었는데 말이죠. 이런 식으로요:
 
 $ git checkout HEAD~7 -b master  # 나뭇가지를 만들고 바로 작업공간도 그 나뭇가지로 옮긴다.

=== 메들리의 재정리 ===

하나의 branch에서 모든 작업을 끝내고 싶을 수도 있습니다. 작업중인 일들은 혼자만 알고 중요한 commit들만 다른사람들에게 보여주고 싶을 수 있습니다. 그럴경우엔 두 개의 branch를 우선 만드세요:

  $ git branch sanitized    # 정돈된 commit을 보여주기 위한 나뭇가지를 만듭니다.
  $ git checkout -b medley  # 작업을 하게 될 "메들리" 나뭇가지를 만들어 이동합니다.

버그를 고치던, 어떤 기능을 더하던, 임시코드를 더하던 작업을 진행합니다. 물론 commit을 해가면서 말이죠. 그리고:
  
  $ git checkout sanitized
  $ git cherry-pick medley^^

위의 명령어들을 차례로 사용한다면 "메들리" 나뭇가지의 commit들을 "sanitzed" 나뭇가지에 붙입니다. "cherry-pick"명령어를 잘 사용한다면 마지막 결과물에만 첨부된 코드들이 들어있는 branch를 만들 수 있습니다. 잡다한 commit들도 잘 정리되어 있을겁니다.

=== Branch 관리하기 ===

여태까지 프로젝트에서 생성한 나뭇가지들을 보려면:

 $ git branch

기본적으로 "master" 나뭇가지에서 작업을 시작하는 것이 디폴트로 지정되어 있습니다. 그러나 어떤 개발자들은 "master" 나뭇가지는 그대로 냅두고 새로운 나뭇가지를 만들어서 그 곳에서 작업하는 것을 선호합니다.

*-d*와 *-m* 옵션들은 각각 branch들을 지우거나 branch 이름을 바꿔줄 수 있는 파라메터들 입니다.
*git help branch*를 보시면 더욱 자세히 설명되어 있을겁니다 (번역 주: 어차피 영어입니다)

"master" 나뭇가지는 관례적인 이름의 branch일 뿐입니다. 다른 개발자들은
당신의 저장소에 당연히 "master"라는 이름을 가진 branch가 있을 것이라고 생각하겠지요. 그리고 
그 branch는 모든 공식적인 자료들이 들어있다고 넘겨짚을 것입니다. 물론 당신은 "master"를 없에거나 새로운 이름을 지정해줄 수 있으나, "master" 나뭇가지를 쓰는 관례를 따르는 것을 추천합니다.

=== 임시 branch ===

Git을 사용하다보면 당신은 쓸모없는 하루살이 같은 쓸때없는 branch들을 많이 만들고 있다는 사실을
깨달을 것입니다. 이유는 다음과 같겠지요: 그 많은 branch들은 작업의 경과를
저장하기 위해 임시로 만들어놓고 무엇인가 고칠 것이 있을 때 빨리 돌가가기 위해서
쌓아두기만 하고있는 거겠죠.

다른 TV채널에서 무얼하나 확인할 때 잠시 채널을 바꾸는 것과 같은 아이디어입니다.
그러나 리모콘 버튼 몇 개 누르면 되는 것과는 달리, 많은 나뭇가지를 만들고, 설정하고, 병합하고,
나중에 다쓰면 지워야합니다. 다행히도 Git에서는 TV 리모트와 비슷하게 
지름길이 있습니다:

 $ git stash

이 명령어는 현 버전을 임시저장소 (stash)에 저장해 주고 작업하기 전의 상태로
돌아갑니다. 작업중인 디렉토리는 작업 (편집, 버그고침 등) 하기 전의 상태로 돌아가겠지요.
그리고 임시 (stash)로 돌아가고 싶다면:
 
 $ git stash apply  # 에러 (version conflict)가 날지도 몰라요. 수동적으로 해결하세요.

물론 여러개의 임시저장소 (stash)를 만들수도 있습니다. *git help stash*에 설명이 되어있으니
읽어보세요. 눈치챘을지 모르겠지만, Git은 올바른 임시저장소 (stash) 기능을 쓰게 해주기 위해서 자체적으로 임의 생성된 branch들을 몰래 이용한답니다.

=== 내 방식대로 작업하기 ===

Branch를 이용하는 것이 꼭 필요한지 생각할지도 모르겠습니다. 파일들을
클로닝하는게 제일 빠르고 *cd*를 이용해 디렉토리를 바꿈으로써 branch 사용을
대체하고 싶을지도 모릅니다.

웹브라우저의 예를 들어보겠습니다. 여러개의 창 아니면 여러개의 탭을 지원하는 이유는 무엇일까요?
여러 이용자들의 작업방식을 존중하여 주기 위해서랍니다. 어떤 이용자들은
웹브라우저 창 하나만 열고 여러 탭을 열어서 작업하는 방식을 추구합니다. 다른 이용자들은
반대의 형식으로 작업하는 것을 추구할지도 모르죠: 여러개의 창을 만들고 탭이 없이 작업하는 것을 말이죠.
또 어떤 이용자들은 이 두 방법들을 섞어서 작업하는 걸 선호할지도 모릅니다.

Branch들은 마치 작업중인 디렉토리의 탭과 같습니다. 클로닝은 새로운 브라우저 창을
여는 것과 같은 것이죠. 이 두가지 방법은 모두 빠르고 로컬에서 진행됩니다. 그러니
당신에게 맞는 방법을 찾아보는 건 어떨까요? Git은 당신이 원하는 대로 일하게 
도와줄 것입니다.