싸피 공통 프로젝트 깃 협업 중 겪은 어려움

commit이 어느 정도 쌓이면 원격저장소에 push 해서 PR을 만든다.

이 간단한 과정도 여러 명이서 하면 엄청난 혼란이 발생한다.

 

필자가 직접 겪은 문제점에 따른 해결 전략을 고민하고 기록해보고자 한다.

 

줄을 서세요!! 한 명씩 들어가세요

PR 머지는 하나씩!

PR 코드리뷰 후 머지는 한 번에 하나씩 하는 것이 좋다는 것을 느꼈다.

메인 브랜치에 머지할 때 conflict는 굉장히 빈번하게 발생한다.

해당 conflict를 해결 한 후 머지한 후,

대기중인 다음 PR에 머지된 메인브랜치를 pull해서 반영하고 나서야 머지해야 한다.

안 그러면 conflict가 계속 다른 PR에 남아있어서 굉장히 많은 혼란이 생길 수 있다.

 

하나의 PR에는 하나의 주제만

하나의 PR에는 그 PR 전체를 관통하는 작업 주제가 있어야 한다.

작업 주제가 여러 개가 되어버리면 예상치 못한 곳에서 conflict가 발생할 수 있다.

ex) 작업하다가 눈에 거슬리는 컨벤션 문제 (;이라던가, indent, 파일 대소문자!!!!)

이런 경우에는 작업 PR 따로, 컨벤션 통합 PR 따로 작성하자!

여러 군데 건드리지 말고 하나의 주제로 하나의 PR을 작성한 후 깔끔하게 main 브랜치에 머지하는 규칙을 지키자.

 

하나의 PR에는 하나의 개발자만

아무리 사소한 커밋이라도 코드리뷰와 피드백을 통해 의견을 개진할 것!

절대 남의 PR에 푸시하지 말 것 ㅠㅠ

당하는 사람 입장에서는 굉장히 황당하고, 남의 커밋으로 인해 오류가 생겼을 때 기분이 상당히 나쁠 것이다.

이 상황은 필자가 가해자 입장이었는데, 사과드리고  기프티콘 조공과 함께..

앞으로는 1PR 1개발자 원칙을 꼭 지키자고 혼자 결심했다..

컨벤션을 맞추는 아주 간단한 작업이라서 괜찮을 것이라고 생각하고

기존 PR에 푸시해버렸는데 생각지 못한 오류가 많이 발생했었다.

 

git add . 지양하기

특히 하나의 주제로 작업하지 못했을 때 git add . 는 절대 금물이다.

여러 주제의 작업이 통합되어 뒤죽박죽한 PR을 만들 수 있기 때문이다.

또 어떤 변경사항이 커밋에 반영될지 확인을 안 하고 커밋하는 것이기 때문에 당연히 하면 안되는 것이다.

그렇지만.. 한 번에 작업물이 스테이징 되어 매우 편하다

애초에 "하나의 주제로 작업하기 -> PR 보내기 -> 코드리뷰 후 머지하기"

사이클 반복을 지켜서 git add . 를 해도 문제가 없게끔 하는 방법이 있다.

git add . 대신 git add -p를 사용하여 어떤 작업이 스테이징 될 지 확인하고 적용하는 것을 추천한다.