Git은 프로젝트나 파일 등을 관리할 때 빠져서는 안될 매우 중요한 시스템으로 자리잡았습니다. Git을 시작하기에 매우 쉽기도하지만 무엇보다도 다른 사람들과 협업을 해야할 때 진가를 발휘합니다.
Git 이전에는 svn이나 ftp 등을 이용해서 파일을 관리했습니다. 그러나 근본적으로 이런 시스템들과 Git은 차별점이 존재했죠. 오늘날 가장 많이 사용되는 VCS(Version Control System)가 Git 임에는 누구도 부인할 수 없을 것입니다.
VCS 사용 빈도 구글 트렌드 결과
구글 트렌드의 조사에 따르면, 2004년도부터 현재까지의 통계를 내보았을 때, 현재 가장 많이 사용되고 있는 VCS는 단연코 Git 입니다. 이 정도 수치면 시장 독점에 가까운 압도적인 비율이라고 볼 수 있겠네요.
전 세계의 수 많은 사람이 사용하고 있는 Git 이지만, 사용하기 전에, 혹은 지금 사용하고 있더라도 더 원활하게 사용하기 위해서 알아두어야 할 것들이 있습니다.
브랜치를 가급적 많이 만드는 연습하기
연습단계에서 브랜치는 다다익선입니다. 많으면 많을수록 좋죠. 제가 지금보다 Git 에 대해서 더 많이 몰랐을 때는 부끄러운 이야기지만 git pull, git push, git commit 밖에 사용하지 않았습니다. 이 얼마나 단조로운 구조인가.. 게다가 브랜치는 무조건 master 에서 작업했으니 지금 돌이켜보면 프로젝트가 터지지 않고 어떻게 잘 버텼나 모를 정도네요. 실제 프로젝트에서는 브랜치를 무한대로 생성하는 것이 항상 좋지는 않습니다. 주로 구현할 이슈별로 브랜치를 만들거나, hotfix 를 만들던지 등의 나름의 팀 마다 갖고 있는 운영 전략을 따르게 됩니다. 그러나 연습 때는 무조건 많이, 될 수 있는 한 많이 만들어보는 것을 추천합니다.
브랜치를 생성하는 습관은 다음과 같이 들이기를 개인적으로 추천합니다.
다른 기능과 겹치는 점이 없는 독립적인 구현을 기준으로 브랜치를 생성합니다.
브랜치 전략이 익숙하지 않은 상태에서 서로 공유하는 기능을 갖고 있는 이슈로 브랜치를 만들어버리면 관리하는데에 어려울 수 있습니다.
master 에서 뿐만이 아니라 나무에 가지가 이리저리 자라듯이 브랜치에서 브랜치를 만들고, 또 브랜치를 만드는 연습을 합니다. 어떤 기능을 담당하는 브랜치에서 작업을 하다가 추가로 다른 기능을 붙이고 싶은데, 그 기능은 실험적으로 시도해보고 싶습니다. 그러면 master 로 돌아가지 말고 해당 작업 브랜치에서 새롭게 가지치기를 해서 브랜치를 만들어 작업합니다. 그 새로운 실험이 끝나면 원래 브랜치로 돌아와서 다시 작업합니다.
master 에서 뿐만이 아니라 나무에 가지가 이리저리 자라듯이 브랜치에서 브랜치를 만들고, 또 브랜치를 만드는 연습을 합니다.
브랜치의 네이밍을 체계적으로 관리하기
브랜치를 만드는 연습이 좀 익숙해졌다면, 이제는 한 번쯤 자신이 어떤 패턴으로 브랜치들을 이름지었는지 돌아볼 필요가 있습니다. 좋은 브랜치는 그 이름마 보고도 어떤 작업을 진행 중인 브랜치인지 알 수 있어야 합니다.
Bootstrap에서 관리중인 브랜치 목록
가령, tab 기능을 구현중인 브랜치 이름을
tab 이라고 지었습니다. 그런데 작업을 진행중에 이 탭을 카드지갑 형식과 네비게이션 바 형식으로 만들어보고 싶은 생각에
tab-1 과
tab-2 라고 이름을 지어서 구분한다면, 시간이 흐른 뒤에 브랜치를 다시 봤을 때 어떤 브랜치인지 기억이 날까요?
tab-card,
tab-navbar 정도가 더 나을 것입니다.
부트스트랩에선 브랜치들을 알기 쉽게 이름을 지어서 구분하고 있습니다. 이렇게 이름으로 브랜치를 구분하는 것도 좋은 습관입니다.
Fetch 와 Pull 의 차이점 이해하기
Git 에서 가장 중요한 부분 중에 하나라고 저는 생각합니다. Git 에 입문한 초보자들이 가장 많이 사용하는 명령어 중 하나는 단연코 git pull 일텐데, 리모트 브랜치나 다른 브랜치의 것을 가져와서 합치고 싶을 때 간혹 충돌이 일어나는 경우가 있습니다. 이 때 git fetch 와 git pull 의 차이만 이해하고 있어도 어느정도의 충돌은 예방할 수 있습니다.
 git fetch를 했을 때 브랜치 상황 |  git pull을 했을 때 브랜치 상황 |
git fetch 명령어와 git pull 명령어의 차이는 위 사진으로 설명 가능합니다. git fetch 명령어는 remote 브랜치의 최신 HEAD 정보를 가지고 오지만 현재 브랜치의 HEAD를 이동시키진 않습니다. 즉, 정보 업데이트만 합니다. 반면에 git pull 명령어는 remote 브랜치의 최신 HEAD 정보를 가지고 오면서 동시에 현재 브랜치의 HEAD를 맨 앞으로 이동시킵니다.
이게 왜 충돌 예방 방지를 할 수 있냐면, 단순히 원격 저장소에 있는 최신 정보만 업데이트 한 상태로 작업하고 싶다면, git fetch 를 사용하면 됩니다. 이렇게되면 현재 브랜치의 HEAD는 이동하지 않은 상태이므로, 현재 HEAD에서 새롭게 임시 브랜치를 생성하고 그 브랜치 위에 가져온 remote 브랜치의 커밋들 중에서 원하는 것만 cherry-pick 을 한다던지 등의 선택지도 생깁니다. 그리고 잘못 가져온 정보라고 할지라도 현재 HEAD 는 아무런 움직임을 취하지 않았기때문에 충돌이나 잘못 병합될 가능성 조차 없어지는 것입니다.
Merge 와 Rebase 의 차이점 이해하기
이 부분도 역시 Git 을 사용하는데 있어 필수적으로 알고 있어야할 개념이라고 생각합니다. 작업중인 브랜치에서 작업이 다 끝나 다른 브랜치로 합치고 싶은데, 어떤 것을 사용해야 할까요?
정답은 없습니다.
merge를 사용하면 관리 포인트가 복잡해진다
rebase는 라인을 단순하게 유지할 수 있다
현재 내가 속한 팀의 상황, 브랜치 운영 전략에 따라가는 것이 제일 좋습니다. 어느 한 쪽이 다른 한 쪽보다 항상 좋은 것은 아닙니다. git merge 명령어와 git rebase 명령어의 가장 큰 차이는 합친 후의 모습입니다. git merge 는 대상이 된 브랜치들을 그대로 간직할 수 있다는 장점이 있습니다. 사실 간직하고 있지 않아도 과거를 추적해서 원복할 수 있으니 큰 의미에서는 상관없겠지만, 사실 여간 귀찮은게 아니라.. git rebase 는 커밋들을 깔끔하게 관리하고 싶을 때 더욱 좋습니다.
저는 사실 git rebase 명령어를 95% 이상의 비율로 사용하고 있습니다. git rebase -i HEAD~5 과 같은 명령어로 커밋 순서 변경, 커밋 합치기, 커밋 복사 등 대화형 인터페이스가 좋아서 사용하는 것도 있고, 문제 생겨도 지금의 저는 알 바 아니죠 ㅎ 미래의 내가 알아서 하겠지 라는 마음으로.. -_-ㅎ
Git 은 너무나도 편리한 시스템이지만 원리를 이해하지 않고 사용한다면 나만 편할 뿐 다른 사람들에겐 끝도 없는 고통을 주기 쉽습니다. 모두가 협업하는 상황에서는 Git 의 기본은 알고 작업하시면 좀 더 수월하겠죠? Git 은 제가 소개한 것보다 훨씬 더 많은 내용을 담고 있습니다만, 이 정도만 알고 가도 어지간한 작업은 문제가 없을거에요!
오늘도 모두 즐코딩하세요~
