백엔드 개발자 협업 (Convention,Githubsetting,gitignore,workflow)

협업은 어렵지만, 안 하면 더 어렵다 – 협업 가이드 정리

1. 어떻게 하면 싸우지 않고 프로젝트를 할 수 있을까?

1) 역할과 책임을 명확히 하기

• 누가 무엇을 맡는지 분명히 정하면 갈등과 중복 작업을 줄일 수 있음
• 초기에 정하고 필요에 따라 유동적으로 조정하는 것이 중요함

2) 명확한 소통 + 기록

• 구두 소통만 하면 나중에 "그때 그렇게 말 안 했는데?" 상황 발생
• Notion, GitHub Issues 등에 기록을 남겨두면 좋음
• “~한 것 같아요”보다는 “~로 결정된 거 맞죠?” 같이 확정적으로 질문하기

3) 이슈나 일정은 명확하게 관리

• 구두 확인보다는 명시적인 이슈, 일정 공유가 효과적
• 감정이 아닌 정보 중심으로 커뮤니케이션해야 함

4) 코드 리뷰는 협업이지 공격이 아님

• 비판이 아닌 제안으로 접근해야 함
• 피드백은 코드에 대한 것이지 사람에 대한 것이 아님
• 리뷰어와 작성자 모두 성장의 기회로 삼아야 함

5) 기술 선택은 감정이 아닌 근거로

• “써봤으니 좋다”가 아닌 “이 기술이 구조상 적합한 이유”를 설명해야 함
• 논쟁은 논리+서비스 맥락으로 접근해야 생산적임

6) 양심보다 규칙

• “당연히 이렇게 해줄 줄 알았어” → 갈등 유발
• 개개인의 기준은 다르기 때문에 공통 규칙을 설정해 두는 것이 안전함

---

2. 규칙 정하기

1) 코드 컨벤션 필요 이유 ( 추후 링크 예정 )

• 일관된 코드는 빠르게 이해되고, 디버깅·유지보수도 쉬움
• 네이밍, 들여쓰기, 괄호 위치 등 사소해 보이는 것들이 협업의 품질에 영향

2) 커밋 & PR 컨벤션

• fix: 로그인 오류 해결처럼 명확한 메시지는 추적이 쉬움
• temp, 수정 등의 메시지는 나중에 blame/log 분석 시 어려움 유발
• 브랜치 네이밍 예: feature/login-api, fix/user-auth
• PR 제목, 본문, Assignee, Reviewer 지정은 습관화해야 함

---

3. 프로젝트 초기 세팅

1) GitHub Repository 생성

• 새 저장소 만들기 → 이름, 설명, 공개 여부 설정
• 보통은 초기화 없이 생성하고 로컬에서 git init 후 연결

2) 협업자 초대

• Settings → Collaborators 또는 Manage Access
• 오너가 초대하고, 초대 수락 시 공동작업자 등록됨

3) Git Flow 브랜치 전략

브랜치용도설명

main	제품 배포용	운영되는 최종 코드
develop	개발 통합용	기능 브랜치 병합 대상
feature/*	기능 개발용	개별 작업 공간

---

4. .gitignore 및 폴더 구조

1) .gitignore

• Git이 추적하지 않을 파일 목록을 지정
• 예: 빌드 결과물, IDE 설정, 환경 변수 등

예시 (Spring Boot 기준):

/build/
/target/
.gradle/
.idea/
*.log
*.env
application-*.yml
.DS_Store

2) 백엔드 프로젝트 구조

레이어드 아키텍처:

com.example.myapp
├── config/
├── controller/
├── domain/
├── dto/
├── exception/
├── repository/
├── service/
├── util/
└── MyAppApplication.java

기능 기반 아키텍처:

com.example.myapp
├── user/
│   ├── controller/
│   ├── service/
│   ├── repository/
│   ├── dto/
│   └── domain/
├── post/
├── config/
├── exception/
└── MyAppApplication.java

하이브리드 구조:

• 초반에는 레이어드 기반 → 프로젝트가 커지면 기능 중심으로 전환

---

5. 협업 워크플로우

1) 브랜치 전략

• 항상 develop에서 feature 브랜치를 파생
• 예: feature/123-login-api

2) 기능 구현

• IDE에서 구현 후 테스트

3) 커밋

• 작은 단위로 자주 커밋
• 메시지는 명확하게 (컨벤션 지키기)

4) PR 작성

• base: develop, compare: feature/...
• 제목/본문/Reviewer/Assignee 설정 필수

5) 코드 리뷰 절차

1. 리뷰 확인
2. 수정 사항 반영
3. 브랜치에 Push
4. 각 comment에 대응 (Resolved, Reply 등)
5. Reviewer가 다시 확인 후 Approve 또는 추가 요청

6) Merge

• 승인 완료 후 develop에 병합

---

6. 협업 중 발생할 수 있는 상황 처리

1) 충돌(Conflict) 발생 시

• 같은 파일의 같은 줄을 다르게 수정할 경우 충돌 발생
• 항상 pull 전에 fetch로 변경사항 확인
• 충돌은 직접 해결 후 add → commit

2) 병합 시 유의사항

• 항상 main/develop → feature로 pull 후 작업
• pull 자주 해서 최신 상태 유지
• 파일/기능 단위로 작업 분리해서 충돌 방지

---

7. Git 키워드 정리

Fetch

• 원격 저장소의 변경 내역만 가져오기 (병합은 아님)
• 사용 시점: 최신 상태만 보고 싶을 때

Pull

• fetch + merge 조합 (내 브랜치에 병합까지 진행)
• 사용 시점: 다른 사람 작업을 반영하고 싶을 때

Merge

• 두 브랜치를 하나로 병합
• 커밋 그래프는 분기 유지됨 (히스토리 명확)

Rebase

• 내 커밋을 최신 커밋 위에 다시 적용
• 히스토리를 깔끔하게 만들 수 있음
• 충돌 시 해결 후 rebase --continue

Undo Commit

• 최근 커밋 취소 (코드 내용은 유지)
• 사용 시점: 푸시 전 커밋 메시지 수정

Revert Commit

• 기존 커밋을 취소하는 반대 커밋 생성
• 협업 중 푸시된 커밋을 되돌릴 때 유용

---

이 문서는 협업 시 자주 마주하는 상황과 실무에서 사용하는 용어들을 기반으로 정리되어 있으며, git을 처음 사용하거나 협업을 간만에 하거나 오랜만에 다시 시작 하기전에 참고하기 좋은 내용입니다.