협업 중 반복되는 Conflict, 원인은 의외로 간단했다
프로젝트를 팀원들과 함께 진행하면서,
`main` 브랜치에서 변경사항을 pull 받을 때마다
잦은 충돌(conflict) 이 발생하는 일이 반복됐다.
처음에는 내가 작업하던 파일에서 충돌이 나는 줄 알았지만,
자세히 들여다보니 내가 수정하지도 않은 파일에서도 충돌이 발생하고 있었다.
그럴 때마다 해당 파일을 일일이 수동으로 수정하고,
내 작업 브랜치에 push한 뒤 PR을 보내는 방식으로 진행했다.
“왜 내가 수정하지도 않은 파일이 충돌을 일으킬까?”
의문이 들었고, 결국 이 문제를 팀원들과 공유하며
원인을 함께 분석해보기로 했다.
나의 병합 방식
나의 기본 작업 흐름은 다음과 같았다:
# 개인 브랜치에서
git add .
git commit -m "작업 내용"
git push origin 개인브랜치,
# 이 상태에서 main pull 받을 때
git pull origin main
# 이 때 conflict가 우다다 발생하게 됨.
팀원들도 직접 main에서 작업하는게 아닌, 각자의 개인 브랜치를 통해 main에 pr을 보내고 merge하는 방식으로 작업하는데
왜 이런 conflict 가 발생할까? 짜증이났다..
원인은 바로 이거였다.
나는 나의 개인 브랜치에서 바로 main에 pull 을 요청한 것
즉, 나의 로컬 main 브랜치도 최신화하지 않은 상태에서 개인 브랜치에 main을 바로 pull 한 부분이 문제가 됐던 부분이였다,
그래서 결론은,
나의 병합 방식을 아래와 같이 수정하기로 했다.
git switch main # main으로 브랜치 바꾸고
git pull origin main # gitHub 최신 상태 가져온 다음
# 개인 브랜치로 이동해서 최신 main을 개인 브랜치로 merge
git switch 개인브랜치
git merge main
그리고 이후 내 브랜치에 다시 push 하는 방식으로 하는 방향으로 정했다.
그 이후 팀 작업 시 규칙을 제안하였다
- PR은 main과 merge 완료된 브랜치에서만 생성할 것.
- main 기준으로 병합 후 -> 개인 브랜치를 반드시 최신화할 것.
- 충돌이 발생하면 :
- 로컬에서 충돌을 해결 후 커밋까지 한 상태에서 PR생성.
- GitHub 상에서 해결하지 말고, 로컬에서 처리한 뒤 push할 것.
정리하며,
팀원들과 협업하는 과정에서 이런 충돌 문제는 작은 규모일 땐 불편함 정도로 끝날 수 있지만,
프로젝트가 커질수록 치명적인 문제로 이어질 수 있다.
그래서 초반부터 Git 흐름을 명확히 이해하고, 일관된 병합 기준을 갖추는 것이 정말 중요하다고 느꼈다.
이번 경험을 통해
Git 협업에서 "병합 기준의 일관성"이 얼마나 중요한지
몸소 체감할 수 있었다.
'개발 도구 > Git' 카테고리의 다른 글
[Git] PR 커밋 중복 및 브랜치 히스토리 꼬임 정리 (0) | 2025.04.30 |
---|---|
[Git] CI/ CD (0) | 2025.03.04 |
[Git] Git이란? (0) | 2025.02.26 |