Git 실전 협업 가이드, 팀원의 Push부터 팀장의 최종 Merge까지 (GitHub, STS, Git Bash)

Git 실전 협업 가이드, 팀원의 Push부터 팀장의 최종 Merge까지 (GitHub, STS, Git Bash)

 

단순히 코드를 저장하는 용도로 Git을 사용하던 단계를 넘어, 6명의 팀원이 유기적으로 움직이는 '진짜 프로젝트'에 접어들면 우리는 큰 고민에 빠집니다. "내가 작성한 코드가 다른 사람의 코드를 침범하면 어쩌지?", "팀원들이 각자 수정한 수십 개의 파일을 어떻게 하나로 안전하게 합칠 수 있지?" 등 과 같은 질문들이 꼬리에 꼬리를 문다. 특히 웹 애플리케이션 개발처럼 프론트엔드와 백엔드, 데이터베이스 설정이 복잡하게 얽혀 있는 프로젝트라면, 누군가 한 명의 실수로 인해 전체 프로젝트가 구동되지 않는 소위 '빌드 깨짐' 현상이 빈번하게 발생하곤 합니다.

그렇기 때문에 '팀장과  팀원의 실전 협업 시나리오'는 바로 이러한 불안함을 해소하고, 프로젝트의 안정성을극대화하기 위한 핵심 장치입니다. 여기서 팀장과 팀원은 단순히 직급의 차이가 아니라, 코드 생산과 품질 관리라는 명확한 역할 분담을 의미합니다. 팀원은 자신의 이니셜 브랜치라는 독립된 실험실에서 자유롭게 기능을 구현하고 테스트합니다. 이곳은 외부의 간섭이 없는 공간이기에 과감한 시도가 가능합니다. 반면, 팀장은 프로젝트의 최종 결과물인 main 브랜치를 지키는 '문지기'역할을 수행합니다. 팀원들이 각자의 공간에서 보내온 코드들을 검증하고, 프로젝트의 전체적인 방향성과 일치하는지, 기존 기능과 충돌은 없는지를 최종적으로 판단하여 승인하는 권한을 갖습니다.

 

이러한 방식의 핵심은 '검증의 자동화와 시각화'에 있습니다. 팀원이 자신의 브랜치에 코드를 올리고 팀장에게 합쳐달라고 요청하는 순간, 우리는 단순히 소스를 옮기는 것이 아니라 '코드 리뷰'라는 중요한 협업의 단계를 밟게 됩니다. 팀장은 GitHub의 인터페이스나 STS의 비교 도구를 통해 어떤 부분이 추가되었고 어떤 로직이 수정되었는지 한눈에 파악할 수 있습니다. 이는 단순히 에러를 찾는 과정을 넘어, 팀원 간에 기술을 공유하고 코드의 일관성을 맞추는 소중한 학습의 시간이 되기도 합니다.

이와 같은 내용을 기반으로 총 세 가지 방법으로 나누어 설명하고자 합니다. 첫 번째는 개발 협업의 표준인 GitHub의 Pull Request(PR) 방식입니다. 웹 환경에서 소통하며 기록을 남기기에 가장 최적화된 방법입니다. 두 번째는 개발자에게 가장 친숙한 IDE인 STS(Spring Tool Suite)의 GUI를 활용하는 방법으로, 로컬 환경에서 코드를 직접 돌려보며 병합하기에 유리합니다. 세 번째는 Git Bash 커맨드라인을 이용한 정석적인 방법입니다. 명령어를 통해 데이터가 흐르는 원리를 이해하면 어떤 돌방 상황에서도 당황하지 않고 대처할 수 있는 능력을 갖추게 될 것입니다.

 

 

 

 

 

상황, 팀원의 Push부터 팀장의 최종 Merge까지

 

팀장과 팀원이 협업을 하기 위해서는 상황이 필요한데, 구체적인 상황은 아래와 같습니다.

 

팀장은 main 브랜치를 관리하고, 팀원들은 각각 만들어진 본인들의 member 브랜치를 이용해 본인의 작업 소스를 Commit & Push를 진행합니다. 팀장은 팀원들의 각 브랜치 PR을 확인 후, 이상이 없다면 Merge를 진행합니다.

 

 

 

 

 

Pull Request & Merge 방법

 

🎈 상황 (팀장과 팀원)

팀원 👨🏻‍💻
- 본인의 member1 브랜치에서 작업을 마친 후 Push합니다.

팀장 👩🏻‍💻 : 
- 팀원들이 Push한 작업본 PR들을 확인 후, 변경된 코드를 검증하여 이상이 없다면 Merge후, 최종 main 브랜치에 반영합니다.

 

첫번째. GitHub 홈페이지에서 Pull Request(PR) 활용하기

 

팀원이 본인 브랜치(member1)에 작업을 마친 소스를 Commit & Push를 진행합니다. 진행 후, GitHub 홈페이지의 Pull Request 영역에서 팀장에게 '소스 확인 후 Merge 부탁드립니다. 승인해주세요!'를 진행합니다.

 

 [ 팀원 STEP ] 

 

1.  팀 프로젝트의 GitHub Repository로 이동 후, 'main' 브랜치에서 'member1' 브랜치로 이동합니다. 이동하게되면 'Contribute' select 영역이 나타납니다.

 

 

 

 

 

 

2.  'Open pull request' 버튼을 눌러 PR을 준비합니다.

 

 

PR은 Commit & Push를 진행한 계정과 GitHub에서 PR을 요청하는 계정이 일치하여야만 PR 승인 요청의 요건이 성립됩니다. 

 

 

 

 

 

3.  'Open a pull reuqest' 항목에서 STS에서 Push할 때 작성했던 Comment가 보여지고, 그 아래로 추가적인 Summary를 입력 후 'Create pull request' 버튼을 클릭 해 팀장에게 승인을 요청합니다.

 

 

'Add a description' 으로 Push 할 당시에 작성했던 Comment 만으로도 물론 충분하겠지만, 팀장에게 조금 더 친절한 정식 보고서를 작성할수도 있습니다.

 

• 작업 요약 (Summary)
• 주요 변경 사항 (Key Changes)
• 테스트 결과 (Test Results)
• 질문 및 검토 요청 (To Reviewer)

 

 

 

 

 

4.  팀원이 작성한 PR 등록이 완료되었고, 팀장의 승인을 기다립니다.

 

 

 

 

 

 [ 팀장 STEP ] 

 

1.  프로젝트 Repository로 이동 후, 'Pull Request' 탭으로 이동 합니다. 팀원이 요청한 PR 항목이 보여집니다. PR을 확인하기 위해, 아래 목록을 클릭합니다.

 

 

 

 

 

 

2.  'File Changed' 탭을 클릭합니다.

 

 

 

 

 

 

3.  팀원이 올린 PR의 내용대로 변경된 소스에 이상이 있는지 없는지 확인 후, 'Review changes' 버튼을 클릭합니다.

 

 

 

 

 

 

4.  팀장이 PR 확인 후, 팀원이 올린 내용을 승인하기 위한 Comment를 자유롭게 작성 후, 'Approve'를 선택하고 'Submit review' 버튼을 클릭합니다.

 

 

팀원이 작성한 PR을 팀장이 확인 후, 승인 전 Review 내용을 작성하고 'Approve'를 선택하고 Submit review 버튼을 클릭하여 PR에 대한 승인을 진행합니다. 이때, 아래 라디오버튼으로 제공하는 각 설정에 따라서 승인 형태가 변경됩니다.

 

• Comment (일반 의견)
  - 코드에 대해 가벼운 질문을 할 때 사용합니다. (예: 변수명이 좀 더 명확하면 좋을것 같네요..)
  - PR의 상태(빨간색 경고창)가 변하지 않고 여전히 Merge 버튼은 비활성화 상태로 유지됩니다.
• Approve (승인)
  - 팀원의 소스를 검토해 보니 버그가 없고 프로젝트 규칙에 잘 맞을 때 사용합니다.
  - 빨간색 경고창들이 초록색 체크 표시로 바뀌고 Merge pull request 버튼이 활성화되어 실제 반영이 가능해집니다.
• Request changes (수정 요청)
  - 코드에 명확한 에러가 보이거나 보안상 위험한 코드가 있거나 비즈니스 로직이 요구사항 내용과 다르게 작성되었을 때 사용합니다.
  - PR 상태가 'Changes requested'라는 강력한 빨간 경고로 바뀌고 팀원이 코드를 수정해서 다시 올리기 전까지는 절대로 Merge 할 수 없도록 차단됩니다.

 

 

 

 

 

5.  팀원의 PR이 승인된걸 확인할 수있고, 최종 Merge를 위해 'Merge pull request' 버튼을 클릭합니다.

 

 

 

 

 

 

6.  'Confirm merge' 버튼을 클릭합니다.

 

 

 

 

 

 

7.  해당 PR 승인 및 Merge가 성공적으로 끝났기 때문에, 해당 임무는 종료하겠다고 합니다. 

 

 

 

 

 

 

8.  최종적으로 Repository내, 소스를 확인해보면 PR 승인 후 Merge된 최종 소스가 반영되어 있는 모습을 확인할 수 있습니다.

 

 

 

 

 

 

@Junesker

---