GitHub 협업 - 시작하기

Github 협업의 구조를 이해하는 데 도움이 된 링크

1. 초심자를 위한 Github 협업

2. 토이 팀프로젝트 시나리오, 브랜치 전략

읽고 나면 앞으로 어떤 단어를 넣어 구글링해야 될 지 알 수 있다.

내가 github 협업을 처음 시작할 때 어땠는지 주절거릴 셈이라 정보성 내용을 글머리로 밀었다. 원래 3개였는데 최근에 다시 보니까 하나가 사라졌다.

 

혼자 쓰는 git은 좀 생소해도 별 게 없다. 기초에 대한 유튜브 강의도 많고, 원하는 대로 되지 않을 때는 대개 정해진 순서를 지키지 않아서이다. add, commit, push하는 일련의 과정이 익숙해지고 github desktop이나 사용하는 IDE가 제공하는 GUI의 편리함까지 더하면 그냥 클라우드 같다.

그런데 한 repository(이하 repo)에 여럿이 손을 대기 시작하면 얘기가 좀 다르다. 뭐 조금만 하면 에러가 나고, 이걸 어떻게 시작해야 이런 고초를 겪지 않을 수 있는 지에 대한 강의도 찾기 힘들다. branch를 나누고 일하다가 합치라는데, 이렇게 해봐도 에러가 나는 거 같다. 다른 팀원이 같은 파일 같은 부분에 손을 댄 걸 올려놨다면 conflict 에러가 나는 게 당연한데 이게 당연하다는 거 조차 처음엔 모른다. 마냥 짜증난다!

 

프로젝트 협업툴로 git을 처음 사용했을 때, 혼자서 조금 연습만 해둔 상태였다. 웹 파트에서는 git을 써본 사람이 나밖에 없어서 팀원들을 돕기로 하고 시작했다. 하지만 모두가 초행이면 'git을 쓰긴 썼다'에서 더 나아가긴 어려운 것 같다.

1. 일 분배를 정확히 하지 못하면 각자 건드리는 파일들이 너무 자주 겹친다.

재앙은 보통 여기서 시작된다. 그런데 함께하는 프로젝트 자체가 처음인 사람들이 이 일 분배를 깔끔하게 할 수 있을리가. 모두가 이것저것 다 한 번씩 건드려보고 그대로 push, merge하면 conflict 천지다. 심지어 이러면 뭐가 남겨둘 사항인지 분간이 어렵다. 새로운 게 업데이트가 아닌 찌꺼기일 수도 있으니.

2. git을 처음 쓰는 사람은 내가 commit이나 repo를 날려 먹으면 어떡하지? 라는 걱정을 항상 안고 있다.

그래서 push자체를 최대한 미룬다. 대개 이런 사람은 로컬에서의 commit도 잊고 자주 안 한다. 그래서 나중에 push하려고 하면 다른 사람이 이미 push해둔 걸 pull하며 생기는 conflict들이 잔뜩 있고, 로컬에 있는 수정 사항 덩어리도 너무 커져 있다. conflict는 당연히 나고, 이 에러가 금방 해결되지 않는 거에 지쳐서 다시 또 push 자체를 피하는 악순환이 된다.

나는 팀 내의 이런 분위기를 개선하는 데 실패했다. 나도 처음이었으니 다른 사람의 만능키가 될 수 없었고, 내가 어렴풋이 이해한 걸 설명하기엔 모자랐다. 대신 clone을 다시 받고 자신의 변경 사항을 수동으로 적용한 뒤 push하기를 권장했다. 이도 안 되면 카톡으로 프로젝트 파일 전체를 통째로 받고 내가 하나하나 비교해가며 변경 사항을 내 로컬에 합치고 push했다. 에러 핸들링만 죽어라 했다. 프로젝트는 계속 나아가야 되니 자진해서 버전을 관리하는 사람이 되었지만, 매우 비효율적인 방식이었다. 팀원들은 git을 숙달할 기회를 놓쳤고 나는 여기에 시간을 쓰느라 내가 만들어야 되는 부분에 소홀했다.

3. 자꾸 main에 곧장 push한다.

push 규칙을 구체적으로 문서화하지 않고 팀원들이 branch의 필요성을 실제적으로 인지하지 못하면 생기는 현상이다. 프로젝트 repo에 접근하는 사람이 적어서 동시 업데이트로 인한 pull 반복을 겪지 못하고, 로컬에서 commit을 빈번하게 하는 일을 번거롭게 느껴 push할 commit이 적으면 그렇다.

내 경우 프로젝트 repo에 비교적 자주 접근하는 사람이 나 외엔 한 명이었다. 내 설명은 미흡했고, 2번의 문제를 겪고 있는 상황에서 다른 사람에게 뭘 수정하시든 branch로 나눠 push해주셔야 돼요, 라고 컷하는 건 매우 어려웠다. 이 부분은 금방 포기하고 나도 main에 push했다. 그랬더니 이후 github에 합류한 데이터 파트 팀원들도 똑같은 방식으로 push했다. 불완전하거나 오류 있는 코드를 push해서 전체에 문제가 생길 때는 손댈 수 있는 사람이 실시간으로 달려들어 고쳤다. 결국 이 프로젝트의 tree는 일자가 되었다...

 

이런 난리통을 겪고 나서 위코드에 들어왔는데 사전 스터디 기간 한 달 중 마지막 주 과제가 git 공부하기였다. 학습 목표에는 혼자 하는 수준의 과제만 있었지만 사전 스터디 팀원들은 첫주에 이미 다 했다. 그래서 github 협업 연습을 권하고 12월 28일, 30일에 걸쳐 리딩했다. 내가 해보지 않은 부분도, 시간이 지나 해결법을 잊은 에러도 있었지만 첫 프로젝트 경험을 통해 해결 방법을 찾는 능력은 쏠쏠히 들인 것 같다.

이 다음에 그에 대해 포스팅 할 때 내 TIL을 찾아봐야 되니 날짜를 써놨다. 블로그 글 빨리 쓰는 법 있으면 제보 주세요.