[Project] 협업을 위한 Git 가이드

팀 프로젝트, 아직도 '최종_진짜최종.zip'으로 하시나요?

Git 없이 팀 프로젝트를 진행한다고 상상해 볼까요?

서로 코드가 충돌 나서 에러가 터지고, 버전 관리 없이 최종, 최최종, 진짜_마지막 파일들로

폴더가 뒤덮이는 끔찍한 상황이 발생할 겁니다.

 

오늘은 성공적인 팀 프로젝트를 위한 Git의 핵심 개념과 협업 규칙을 정리해 보았습니다.

---

1. 기본 개념 : 저장소 (Repository)

협업의 시작은 공간을 분리하는 것에서 시작합니다.

• 원격 저장소 (Remote Repository): 서버에 있는 우리 팀의 공유 공간 (GitHub, GitLab 등)
• 로컬 저장소 (Local Repository): 내 컴퓨터에 있는 나만의 작업 공간

---

2. Branch : 우리만의 안전한 실험실

브랜치(Branch)는 별도의 작업 공간을 제공하는 기능입니다.

가장 큰 장점은 "과감한 시도"가 가능하다는 점입니다.

• 실패하면? 과감히 삭제하고 다시 시작하면 됩니다.
  코드가 꼬여서 하나하나 수정하는 것보다 브랜치를 날리고 새로 파는 게 훨씬 빠를 때가 많습니다.
• 성공하면? 그때 합치면 됩니다.

💡 핵심: 브랜치는 서로를 방해하지 않고 6명이 동시에 헤엄쳐도 부딪히지 않게 해주는 "레인"과 같습니다.

 

 

branch를 만들고 commit, merge 등을 진행하는 과정

 

---

3. Commit : 3개월 뒤의 나에게 보내는 편지

열심히 개발한 내용을 기록하는 단위입니다.

단순히 저장(Save)하는 것이 아니라 "누가, 언제, 무엇을, 왜 바꿨는지"를 남기는 역사입니다.

• 시간이 아닌 '기능' 단위 : 오늘 하루 일과가 끝났다고 커밋하는 게 아닙니다. (X)
• 논리적 완결성 : 로그인 함수 구현 완료, 버튼 CSS 수정 등 논리적으로 동작이 완결될 때 작게 작게 커밋해야 합니다. (O)
• 커밋 컨벤션 : 말머리와 명료한 제목을 사용하는 규칙은 필수입니다. 그래야 커밋이 쌓여도 한눈에 파악할 수 있습니다.

---

4. Merge Request (MR) : 코드 리뷰의 장

Git 자체 기능은 아니지만, 원격 저장소(플랫폼)가 제공하는 협업의 꽃입니다.

• 프로세스: Merge Request → Code Review → Approve
• 코드 리뷰: 서로 부담 갖지 말고 코드를 확인해 주세요.
  지금 버그를 잡는 것이 나중에 며칠을 밤새우며 디버깅하는 것보다 훨씬 낫습니다.

---

5. Conflict : 충돌은 에러가 아닙니다

Merge(병합) 과정에서 발생하는 충돌(Conflict)을 두려워하지 마세요.

이는 Git이 "두 코드가 겹치는데, 어떤 코드를 쓸까요?"라고 물어보는 질문일 뿐입니다.

• 팀원과 상의 후 해당 부분만 수동으로 해결(선택)해 주면 됩니다.
• 충돌은 자연스러운 개발의 일부입니다!

---

6. 브랜치 관리 전략 (Branch Strategy)

브랜치를 마구잡이로 만들면 어디서 무엇이 수정됐는지 파악하기 힘듭니다. 우리 팀에 맞는 전략이 필요합니다.

• 추천 전략: Gitflow (정석), GitLab flow, GitHub flow
• 조언: 처음에는 정석적인 Gitflow 전략을 사용해 보고,
  점차 팀의 성향에 맞춰 애자일하게 전략을 수정해 나가는 것을 추천합니다.

💡 꿀팁: 구현이 끝난 브랜치는 미련 없이 지우세요!
커밋 기록이 남아있다면 언제든 돌아갈 수 있습니다. 쌓아두면 혼란만 가중됩니다.

 

---

✅ 팀 프로젝트 필수 그라운드 룰 (Checklist)

성공적인 협업을 위해 아래 규칙들은 팀원들과 꼭 합의하고 시작하세요.

 

1. Main/Develop 브랜치 직접 커밋 금지

• 무조건 작업 브랜치를 만들고, MR(Merge Request)을 통해서만 코드를 합칩니다.

2. 브랜치 이름 규칙 준수

• 개인적인 이름(dy_work) 금지 ❌
• feature/기능명, fix/버그명 형식을 지켜주세요. ⭕

3. 작업 끝난 브랜치 즉시 삭제

• Merge가 완료된 브랜치는 바로 삭제합니다.

4. 1일 1커밋 & 잦은 Merge

• 하루 최소 1커밋을 목표로 하세요.
• 브랜치를 너무 오래 붙들고 있지 마세요. 2~3일 안에 Merge 하는 것이 이상적입니다.

---

🚀 지금 당장 정해야 할 3가지

아직 정하지 않았다면, 팀 회의 때 이것부터 정하세요!

1. 브랜치 전략 & 이름 규칙: (예: Git-flow 사용, feature/login 등)
2. 커밋 메시지 규칙: (예: Conventional Commits 참고)
3. 코드 리뷰 프로세스: (예: 리뷰어는 최소 1명, 승인 1개 필수 등)

---

마치며

"기술은 도구일 뿐이다. 중요한 것은 그것을 어떻게 활용하느냐이다." - 리누스 토발즈 (Linus Torvalds)

 

실수했나요? 괜찮습니다. Git은 언제든 과거로 돌아갈 수 있는 타임머신 기능을 제공합니다.

도구를 믿고, 두려움 없이 다양한 시도를 해보시길 바랍니다!