- 오늘은 Git 특강 2편, 즉 협업을 위한 Git 활용법에 대해 배운 내용을 정리해보려 한다.
- 단순히 Git 명령어를 아는 수준에서 벗어나, 실제 팀 프로젝트에서 브랜치 전략, 충돌 방지, 그리고 협업 규칙 설정 등 실전에서 꼭 필요한 부분들을 중심으로 강의가 진행되었다.
🔁 Git은 ‘도구’일 뿐, 협업의 핵심은 ‘사람’
- Git 명령어는 단지 수단일 뿐, 협업은 결국 사람이 하는 일이다.
- 그래서 오늘 강의는 Git 사용법보다도 어떻게 팀이 소통하고, 역할을 나누며, 문제를 해결하는가에 초점이 맞춰졌다.
🌿 브랜치를 나누는 기준
- 가장 먼저 다룬 내용은 브랜치를 어떻게 나누는가였다. 브랜치 전략은 팀마다 다를 수 있지만, 다음과 같은 기준을 활용할 수 있다:
- 기능 단위: inventory, store, battle 등 기능별로 브랜치 생성
- 클래스 단위: Inventory.cs, Store.cs, Battle.cs 파일별 작업
- 모듈 단위: Monster, Item, UI 등 하나의 독립된 역할 단위로 나눔
- 또한, 프로젝트 초반에는 어느 정도 기초적인 밑작업을 선행해 두는 것이 중요하다고 강조했다. 예를 들어, 전투 기능을 만들다 보니 몬스터 클래스가 필요하다면, 이를 dev 브랜치에 먼저 반영하고, 모든 브랜치가 이를 기준으로 작업할 수 있게 한다.
🧠 회의는 설계와 규칙을 다루는 시간
- 강의에서는 효율적인 회의 방향도 다뤘다. 단순히 ‘누가 뭘 만들까’를 정하는 데 그치지 않고, 아래와 같은 내용을 중심으로 논의하는 것이 바람직하다:
- 공통 클래스 활용: Item 클래스를 만들어 상점과 인벤토리에서 함께 사용하는 구조
- 반복 줄이기: GreenSnail.cs, BlueSnail.cs를 하나의 Snail.cs로 통합
- 데이터 흐름: 데이터를 어디에 저장하고, 어떻게 전달할 것인가
- 코드 컨벤션과 Git 컨벤션: camelCase, snake_case, commit 메시지 스타일 등 통일
⚠️ 충돌을 막는 가장 현실적인 방법
- Git 충돌(conflict)은 협업에서 흔히 발생하는 문제인데, 그 해결보다 중요한 건 사전에 방지하는 습관이다.
❗ 협업 시 충돌을 줄이기 위한 핵심 규칙
- 같은 줄을 건드리지 않는다.
- 같은 씬(Scene)이나 프리팹(Prefab)을 동시에 수정하지 않는다.
- 다른 사람이 작업한 파일은 되도록 건드리지 않는다.
- Merge 전에 dev 브랜치를 먼저 자신의 브랜치에 병합해서 충돌을 미리 해결한다.
- 예기치 않게 스페이스나 엔터를 눌러도 같은 줄을 수정한 걸로 처리되기 때문에 코드 리뷰나 커밋 전에 꼭 확인이 필요하다.
❓ “올려도 될까?” 헷갈릴 땐?
- "이거 커밋해도 될까?"라는 생각이 들 때는 혼자 판단하지 말고 팀원 또는 튜터에게 확인하는 습관을 들이자.
- 특히 공동 작업물(씬, 프리팹 등)은 충돌 위험이 높기 때문에 더더욱 조심해야 한다.
📌 마무리하며
- Git은 도구고, 협업은 문화다.
- 오늘 배운 내용은 기술 그 자체보다도, 어떻게 팀이 효율적으로 함께 일할 수 있는지에 대한 고민과 방향성을 다루고 있어 더욱 와닿았다.
- 다음 프로젝트에서는 단순히 ‘나의 기능’만 구현하는 것이 아니라, 팀 전체를 고려한 브랜치 전략과 커뮤니케이션으로 협업해 나가고 싶다.