git이라는 툴이 그냥 사용하다 보면 익혀지지 않을까라는 생각으로 몇차례 사용해보았습니다. 그러나 좀처럼 git이라는 툴에 대한 이해도는 올라오지 않았고, 사내 프로젝트는 SVN을 사용하다 보니 Git과는 더 멀어졌다는 위기감을 느끼게 되었습니다.
해서 본격적으로 git에 대해서 학습하고, 실제로 사용해보며 체득해보려고 합니다
Git
먼저, '팀개발을 위한 Git,GitHub를 시작하기'를 읽으며 머리 속에 파편화 되어있거나 비어있었던 git의 사용 방법과 세부적인 내용들을 익혔습니다. 특히 와닿았던 부분은 아래와 같습니다.
- git clone \ .
. 을 clone 시 마지막에 붙일 경우 현재 디렉토리를 기준으로 clone을 받아올 수 있어 해당 폴더에 한번 더 들어가서 git을 사용하지 않아도 된다. - git을 커밋할 때 가장 중요한 개념은 stages 개념이다. 원하는 변경사항만 골라 무대에 올리고 스냅샷어 커밋으로 기록합니다.
- 병합이 이루어지는 방식은 세 가지 입니다.
1. fast-forword: 소스들이 부모자식 관계이므로 최신소스로 합쳐집니다.
2. merge: 각각의 파일의 소스가 다르지만 충돌지점이 없어 정상적으로 병합됩니다.
3. conflict: 충돌이 발생한 것이므로 해당 파일을 열어 소스를 정리해 주어야 합니다. - 병합을 하는 방법은 크게 세 가지로 나누어집니다.
1. merge
2. rebase
3. cherry-pick - git pull --rebase를 사용하면 remote 브랜치를 변경하지 않으면서 나의 브랜치에 깔끔하게 받아올 수 있습니다. (단, 역사를 부정하는 일이니 가급적 merge가 좋아보입니다)
Git Branch
git과 다른 vcs의 가장 큰 차이점 중 하나가 branch 입니다. 그리고 제가 이해한 branch는 commit과 같이 이해했을 때 그 효용성에 대한 이해가 극대화 될 수 있었습니다.
브랜치를 잘 활용하기 위해서 먼저 커밋을 사용자의 마음대로 옮기고, 합치는 등의 기능을 자유롭게 구사할 수 있어야 합니다. 커밋을 내 맘대로 지지고 볶을 수 있게 되면 브랜치를 사용하는 이유와 커밋에 대해서도 쉽게 이해할 수 있게 됩니다.
해서 먼저 선행되어야 되는 것은 git의 가장 기초적인 명령어들과 그중에서도 merge, rebase, cherry-pick에 대한 이해도를 높이는 것입니다. git 명령어들을 가장 직관적이고 빠르게 익힐 수 있는 방법은 Learning git branching 라고 불리는 게임을 통한 학습입니다. 해당 게임은 직관적인 커밋과 브랜치의 구성과 이동 동작들을 동적으로 표현해주어 git의 브랜치와 커밋에 대한 이해도를 빠르게 올려줍니다.
Git Commit
위의 게임을 하여 브랜치에 대한 이해도가 어느 정도 올라오면 실제 프로젝트에서 git을 사용해봅니다.
1. 기차 커밋 만들어 보기
브랜치를 통해서 먼저 기능들을 분리하여 시작해보기보다는 먼저는 하나의 브랜치에 커밋들을 기차처럼 줄줄이 생성해 봅니다. 대신 커밋들을 생성할 때, merge/rebase/cherry-pick을 사용하여 추후에 기능별로 별도의 브랜치로 분리할 것을 고려하여 생성합니다. 이런 기준을 잡고 시작하면 add . 명령어를 통해 모두 커밋 하기보다는 기능별로 분류하여 커밋하는 습관이 생기게 됩니다.
(git 명령어로 하다 보면 자연스럽게 GUI 툴을 찾게 됩니다.)
2. 기차 커밋 쪼개서 브랜치 만들어보기
어느정도 기차가 늘어났으면 이제 시작점이 되는 커밋을 체크아웃 받아 기능별로 브랜치를 만들고, 커밋들을 분류하여 옮겨 닮습니다. 필요에 따라 rebase, cherry-pick을 사용합니다. 보통 별개의 기능들을 각각의 브랜치에 옮겨 닮는 것이므로 merge는 아직 사용할 일이 없을 것 같습니다.
3. 브랜치로 먼저 쪼개서 커밋들 생성하기
이러한 경험이 생기면 이제 git을 커밋하는 이유에 대한 이해도가 대폭 상승합니다.
브랜치에 대한 이해도 단단해집니다. 커밋과 브랜치에 대한 이해가 완료 되면 이제 다음 진행 사항들을 자연스럽게 브랜치를 먼저 나누고 시작하는 것이 가능해지게 됩니다. 또 만약 실수하더라도 복구할 수 있다는 자신감이 붙습니다.
결론은 '커밋을 최대한 자주 하되 가급적 의미에 맞게 쪼갭니다' 그러면 후에 처리하여 main에 merge 하기 수월 할 수 있습니다.
