프롤로그

이 글은 앞으로 쓸 예정인 필로소퍼, 미니쉘에 대한 회고 기록, 학습 기록을 남기기 앞서 다시 블로그 관리에 시동을 거려는 나름의 처절한 몸부림(…) 입니다.

협업으로 학습과 개발을 해보니, 자연스레 저보다 깃에 익숙한 팀원에게 사실상 깃 관리를 맡겼었습니다.

하지만 아무래도 관리적으로 아쉬운 점이나, 깃의 제대로된 활용(?) 에 있어서 배워야 한다는 생각, 보완을 어떻게 하면 좋을까? 하는 생각을 하게 되었습니다.

따라서 협업에서 충분한 숙지가 필요한 ‘깃’이라는 협업 관리 툴에 대한 이해도를 높이고, 유용한 기능들을 놓치지 않기 위해 정리하는 글입니다.

사실은 이런 글을 굳이 적을 필요가 없다? 는 생각도 한 켠에 들긴 했습니다.

사실상 모든 기능들이나, 개념은 매뉴얼을 참조하면 되고, 커맨드 몇 번 입력하면 되니…

그러나 막상 팀업으로 빌드가 이어지는 와중에 그런 식으로 맥을 끊는 고민들이 발생하는게, 상당히 안 좋다는 걸 느꼈습니다.

개발 흐름을 끊기도 하고, 무엇보다 그걸로 시간을 쓰는게 ‘경험’ 적으론 유익하나 ‘개발’ 면에선 다소 아쉬움을 느꼈습니다. 내가 얼마나 빠르지만 정확하게 개발이 가능하냐 는 정말 중요한 강점이 될 수 있기 때문입니다.

이에 필요한 기능이나, 알아야 할 점들을 정리해 보았습니다. 다소 주의하실 사항은 이 글은 팀 개발을 위한 Git GitHub 시작하기라는 교재를 학습하고, 거기서 필요한 일부만 남겨둔 것이라는 점입니다.

내용이 완벽하게 담긴 것은 아니니, 학습에 참고 용 정도고 부정확한 내용도 있을 수 있음을 먼저 알립니다.

git conflict 날 때를 대비하는 전략 꿀팁

1. master 브랜치는 메인 브랜치로 두고 다른 기능을 추가한다면 보통 새로운 브랜치를 현재 메인 브랜치 HEAD 시점에서 분기하여 작성하게 된다. 이때, 기능이 완료하고 이를 보통 커밋 후 머지하여 master 브랜치로 해당 내용을 병합하는게 가장 기본적인 루틴이다.
   하지만 알다시피 원본 브랜치에서 지속적인 커밋이 존재한다면, 해당 커밋들이 존재하는 상황에서 나의 새로운 브랜치에서의 수정이 conflict 를 발생시킬 수 있다.
   예를 들면 아래와 같다.
   

   원본 [커밋1] ⟵ [커밋2] ⟵ [커밋3] ⎯⎯⎯⎯⎯
   		↖                                  ↖
   			⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ [커밋4] ⎯⎯⎯ [병합커밋]

   따라서 이런 경우를 대비해, conflict 날 요소가 있는지 사전에 확인하면 좋은데, 방법은 다음과 같다.

   1. 원본이 되는 브랜치를 최신화 한다.
   2. git checkout 으로 현재 내가 작성 중이던 브랜치로 넘어간다.
   3. git merge <원본 브랜치> -m "커밋 내용"으로 진행하여, 현재 내가 작업한 브랜치에 원본 브랜치를 병합해보고, 새로운 병합커밋을 작성해준다.
   4. 이때 conflict가 나는 부분이 있다면 해당 부분을 수정해주고, 없다면 다시 원본 브랜치에 병합하도록 한다.
   5. 이로써 원본 브랜치로 내가 만든 기능이 여러 사람과 작업 중인 원본 브랜치에 병합되더라도 conflict 를 발생시키지 않는다.

   이때 테스트 해본 결과, 병합 대상으로 원본 브랜치로 설정할 경우 브랜치의 변동사항이 없다면 merge가 cli 상에선 적용 되지 않았다.(교재에선 그대로 진행된 것 같은데 해당 내용은 GUI 버전이고 아마도 그렇게 될 경우 다른 커맨드 옵션이 들어간 것으로 추정된다.)