# Simple Git Workflow (for Pair programming)
- upstream 레퍼지토리에서 각 팀원의 remote 레퍼지토리로 fork해온다.
- remote 레퍼지토리에서 Local로 가져오기 위해 git clone을 통해 clone해온다.
- driver를 맡은 팀원이 먼저 코드를 작성하고, commit한 후 origin master로 push한다.
- navigator를 맡았던 팀원은 driver를 맡았던 팀원의 레퍼지토리에서 pull을 통해 수정된 코드를 가져온다.
* pull은 fetch와 merge의 성격을 모두 가진다. 일명 '가져와 병합하기'라고 표현 할 수 있다. 원격 저장소의 최신 정보를 내 로컬 저장소에 업데이트 할 수 있도록 만들어 주도록 하는 명령이 pull이다.
# Merge Conflict
Merge
팀 단위로 개발을 진행할 경우, 각 팀원은 각자 새로운 이슈를 처리할 branch를 생성하고 새로 만든 branch에서 담당 작업을 진행한다. 이렇게 각자 진행한 branch들의 변경 사항을 병합해야만 한다. 병합을 하기 위해서는 git merge <commit>과 같은 명령어를 사용한다.
Solution For Merge Conflict
서로 같은 파일을 수정하는 경우 중에서 특히 서로 같은 이름의 파일을 수정하고, 수정한 부분이 겹치는 경우는 충돌이 발생할 수 있다. 다른 경우에는 git이 auto merge를 통해 자동으로 병합을 진행해주지만, 충돌이 발생한 경우에는 직접 해당 부분에 대해 수정을 해주어야한다. 충돌이 일어난 파일을 살펴보면 <<<<<< HEAD >>>>>> 와 같은 형식으로 나타나 있음을 확인할 수 있는데, 이 때 incoming으로 표현된 부분이 내가 아닌 다른 사람에 의해 수정된 코드이다. 해당 부분을 알맞은 방식으로 삭제 및 수정을 거친 후 다시 commit을 진행해주면, 정상적으로 병합이 이루어지게 된다.
Rebase
merge를 여러번 진행하게 되면, merge commit이 계속 생성됨에 따라 따라 불필요한 object들도 다수 생성되면서 merge 상황에 대한 log를 확인하기에 불편해진다. rebase는 말 그대로 branch의 베이스를 다시 설정한다는 이야기인데, rebase를 먼저 실행한 후 병합을 시도하면 분기된 줄기들의 이력을 하나의 줄기로 합칠 수 있다고 한다.
HEAD
현재 상태에 체크아웃이 된 commit을 말한다. 좀 더 간단하게 말하면 가장 최근에 작업중인 커밋에 대해 말하는 것이다. 각 커밋은 해시값으로 특정 가능하다.
상대참조(^)
커밋의 해시값을 사용해 이동하는 방법 대신, ^이라는 상대 커밋 기능을 이용할 수 있다. 만약 우리가 master^라고 작성하면 이는 master의 부모에 대해 찾게 되며, master^^라고 작성하면 master의 부모의 부모를 찾는다. HEAD 역시 상대 참조로 사용 가능하다.
(사실 Rebase와 HEAD 부분은 아직 봐도봐도 이해가 잘 안간다. 좀 더 추가적인 공부가 필요할 듯 하다.)
merge에 관련해서 더 찾아볼 키워드들!
- fast-forward
- recursive strategy
# 스프린트 진행 과정 및 발생한 오류들
-
상대의 remote repository를 추가하기 위해 git remote add <임의로 설정할 이름> <팀원의 주소> 를 이용
-
remote -v 를 통해 서로 연결된 상태를 확인
처음 페어와 함께 서로의 repository에서 수정된 내용을 커밋하고 pull, push하는 과정은 큰 무리 없이 진행됐다. 하지만 문제는 충돌 상황을 만들어내는 부분에서 발생했는데, 내용을 수정한 팀원 쪽에서 먼저 push를 한 뒤 내 쪽에서 pull을 진행했음에도 자꾸 코드 병합 과정에서 충돌이 없이 수정되어 있었고 서로 드라이버와 네비게이터의 역할을 바꿔 다시 진행을 해보아도 역시나 마찬가지였다.
고민하던 이 문제는 정말 간단하게 해결되었는데 git에서 add, commit, push가 정확히 어떤 단계에서 어떤식으로 동작하도록 명령하고, 현재 상태에 대한 수정을 기록하는지 정확하게 알지 못해서 발생한 문제였다. merge를 하는 과정에서 일어나는 conflict는 서로 다른 개발자가 같은 코드의 같은 부분에 대해 다른 내용으로 수정할 경우 발생하는데, 우리의 경우는 두 명 중 한명은 로컬 저장소에서만 수정한 부분이 존재하고 이 내용을 원격 저장소에 push하지 않은 상태에서 다른 팀원의 수정된 내용이 포함된 레포지토리에 대해서 그대로 pull을 해왔기 때문에 당연히 충돌이 없이 그대로 가져온 결과만 나왔던 것이었다..
프리코스때부터 git은 늘 어려웠지만, 오늘같이 이런 근본적인 부분에서 막히지 않으려면 한번 알 때 제대로 알아야 한다고 느낀 하루였다. 새로운 것에 대해 배울 때 이해가 느린 편이라 아직도 사실 완벽히 이해가 가진 않지만, 앞으로 협업을 진행하며 복습하다보면 지금보단 나아질 것이라 생각한다.. 보는 것보단 확실히 직접 해봐야 더 느는 것 같다.
# branch
-
branch를 생성하면서 switch 할 때는 git branch -b 이용
-
이후 존재하는 branch 사이에서 switch 할 때는 git branch 이용
-
branch의 삭제는 git branch -d를 이용
-
remote 저장소의 위치는 git branch -r 를 이용해 확인
-
로컬 branch의 정보는 git branch -v 를 이용해 확인
-
git --merged : 이미 merge된 branch들을 표시 / -no-merged : merge되지 않은 branch들을 표시.
개인적으로 branch도 이해하기에 꽤 난해한 개념이라 느꼈는데, 서칭을 하다보니 '원하는 시점에서 그대로 복사된 평행세계'란 표현이 이해하기에 가장 와닿고 쉽게 느껴졌던 것 같다. branch는 변경 사항들에 대해서 그 차이를 기준으로 저장하는 것이 아니라, 일련의 스냅샷과 같이 데이터를 저장한다고 한다. 만약 우리가 수정한 코드에 대해 커밋을 진행하면 현재의 staging area에 존재하는 데이터에 대한 스냅샷을 지정하는 포인터와 이전 커밋에 대해 저장하는 커밋 오브젝트 등을 저장하게 된다는 것이다.
위 그림은 사실 지금 당장 이해해야 할 내용은 아니지만, 일반적인 git workflow 방식에서 사용하는 branch의 흐름을 나타낸 그림을 보면서 좀 더 자세하게 이해하고 싶어 다시 그려본 것이다. master는 현재 배포 가능한 수준의 상태만을 관리한다. 우리가 흔히 게임에서 패치가 이루어질 때 볼 수 있는 버전이 이 라인에 속한다고 생각하면 좀 더 쉽다. hotfixes 라인에 존재하는 작업은 이미 배포된 버전에서 문제가 발생할 경우, master에서 바로 분기점을 만들어 브랜치를 생성하고 문제 되는 부분만을 수정한 뒤 병합하는 것을 나타낸 것이다. 게임으로 생각해보면 어떤 한 캐릭터의 스탯에 대해서 버그가 발생했을 때 그 캐릭터에 대한 정보만을 빠르게 수정하고 올리기 위해 master에서 바로 분기점을 가지고 나눠진 것이라 생각하면 된다. feature branch는 각각의 기능 개발 혹은 버그 픽스를 위해 develop에서 분기점을 가지고 나와서 개인의 로컬 저장소에서 관리되며, 개발이 완료되었다고 판단될 때 다시 develop 라인으로 병합된다. 간단하게 생각하면 develop은 각 기능에 대한 branch들을 병합하는 라인이라 생각하면 좋을 듯 하다. release branch는 사실 이해하기가 조금 힘들었는데, develop과 master 사이에서 배포를 위해 준비할 수 있는 단계로 우선 이해를 했다.
나름대로 git에 대해 많이 검색하고 찾아봤다고 생각했는데 아직도 이해가 가지않는 부분들이 많아서, 앞으로도 꾸준히 자료를 찾고 정리해야겠다는 필요성을 오늘 정말 많이 느꼈다..
