Git/GitHub - 조별로 브랜치를 나누고 Pull Request로 합쳐보기

이번에는 기본 Java만으로 만든 HTTP 서버 예제를 조별로 확장했습니다.

기능을 추가하는 것 자체도 실습의 목적이었지만, 개인적으로는 각자 작업한 결과를 Git 브랜치로 관리하고 GitHub의 Pull Request를 통해 main에 합치는 과정을 중시하였습니다..

그동안 혼자 개발할 때는 작업 브랜치를 만들더라도 결국 제가 만들고 제가 병합하면 끝이었습니다. 이번에는 하나의 저장소를 세 사람이 나눠 사용하면서, 각자 별도의 브랜치에서 작업하고 PR을 통해 합치는 흐름을 실제로 진행해봤습니다.

하나의 서버를 세 기능으로 나눴습니다

공통으로 사용할 기본 HTTP 서버를 main 브랜치에 올린 뒤, 각자 맡을 기능을 정했습니다.

담당브랜치작업 내용

조원 1	f/add/fortune	무작위 메시지를 출력하는 페이지(/api/fortune) 추가
조원 2	feature/kdh	존재하지 않는 경로에 표시할 404 페이지 제작
본인	feature/usersgui	/users 페이지를 확장하고 GUI와 복사 기능 추가

각자 main에서 자신의 브랜치를 만든 뒤 해당 브랜치로 이동했습니다. 이후 맡은 기능을 구현하고 Commit한 다음, 같은 이름의 원격 브랜치로 Push했습니다.

흐름만 단순하게 표현하면 다음과 같습니다.

main에서 분기
    ↓
각자의 브랜치에서 작업
    ↓
Commit
    ↓
원격 브랜치로 Push
    ↓
Pull Request 작성
    ↓
main에 Merge

여기서 중요한 점은 작업 중인 코드를 곧바로 main에 올리지 않았다는 것입니다. 각자의 작업은 별도 브랜치에 격리되어 있었고, 작업이 끝난 뒤에야 PR을 통해 main에 들어갈 수 있었습니다.

 

개인 프로젝트로 Git를 사용할 때는 Commit과 Push만으로도 해야 할 일이 끝났습니다. 하지만 협업에서는 원격 저장소에 Push한 브랜치도 여전히 개인 작업 공간입니다.

예를 들어 feature/usersgui를 Push하면 GitHub에 해당 브랜치가 생기지만, main의 소스는 아직 바뀌지 않습니다. 이후 GitHub에서 다음 방향으로 Pull Request를 만들어야 합니다.

base: main
compare: feature/usersgui

이 요청은 “제 브랜치의 변경 사항을 main에 반영해 주세요”라는 의미입니다.

이번 실습에서는 세 기능 모두 이 과정을 거쳐 병합했습니다. 실제 저장소에도 다음 PR 기록이 남았습니다.

• feature/kdh → main: 404 페이지
• feature/usersgui → main: users 페이지 확장
• f/add/fortune → main: 무작위 메시지 페이지

fortune 작업은 앞서 경로만 추가한 첫 번째 PR과 실제 기능을 추가한 PR로 나뉘어 들어갔습니다.

소스만 최종 결과로 복사했다면 누가 어떤 기능을 맡았고 어떤 순서로 반영됐는지 알기 어렵습니다. 반면 PR로 병합하니 작업 브랜치, Commit, 변경 내용과 병합 시점이 GitHub에 기록으로 남았습니다.

서로 다른 브랜치였지만 완전히 독립적인 작업은 아니었습니다

각자 서로 다른 페이지를 맡았다고 해도 최종적으로는 하나의 HTTP 서버 안에 들어갑니다. 따라서 자신의 브랜치만 보고 작업을 끝내면 안 됩니다.

다른 사람의 PR이 먼저 병합되었다면 내 브랜치가 시작됐을 때의 main과 현재 main이 달라집니다. 실제 팀 프로젝트에서는 PR을 병합하기 전에 최신 main을 받아서 함께 실행되는지 확인하는 과정이 필요합니다.

원격 저장소의 최신 내용 확인
    ↓
최신 main을 내 브랜치에 반영
    ↓
충돌 여부와 전체 실행 확인
    ↓
PR 병합

이번 과제처럼 규모가 작은 예제에서는 빠르게 끝날 수 있지만, 프로젝트가 커질수록 이 과정의 중요성도 커질 것입니다.

특히 같은 파일의 같은 줄을 두 사람이 수정했다면 Git이 어느 내용을 남겨야 할지 자동으로 판단할 수 없습니다. 그때 발생하는 것이 Merge Conflict입니다.

기록을 합치는 과정

PR을 만들었다고 곧바로 Merge하지는 않았습니다. 다른 사람의 작업을 합치기 전에 변경 내용을 함께 확인했던 경험을 살려, 조원들이 모여 각자 작성한 소스를 설명하고 리뷰하는 시간을 가졌습니다.

각 담당자가 자신이 추가한 기능과 수정한 위치를 먼저 설명하고, 다른 조원들은 해당 코드가 기존 서버 흐름에 어떤 영향을 주는지 함께 확인했습니다. 이 글에서는 개별 소스에 대한 리뷰 내용은 생략하지만, 병합 전에 서로의 변경 사항을 한 번씩 읽어봤다는 과정 자체는 Git 협업에서 중요했습니다.

이 시간을 가지니 PR은 단순히 Merge 버튼을 누르기 위한 화면이 아니었습니다. 작성자는 자신이 무엇을 바꿨는지 설명하고, 나머지 조원은 그 변경이 main에 들어가도 되는지 확인하는 단계가 됐습니다.

개인 실습에서는 작성자와 병합하는 사람이 같아 이 과정을 건너뛰기 쉽습니다. 하지만 여러 사람이 함께 작업할 때는 기능이 정상적으로 보인다는 이유만으로 바로 합치기보다, 변경 의도와 영향 범위를 짧게라도 공유하는 편이 안전합니다.

 

이번 실습에서 최종 결과만 본다면 세 페이지가 하나의 서버에 추가된 간단한 예제입니다. 하지만 Git 관리 관점에서는 그보다 많은 과정을 경험했습니다.

• 공통 main에서 작업 브랜치를 분리했습니다.
• 각자 자신의 브랜치에만 Commit했습니다.
• 원격 저장소에 같은 브랜치를 Push했습니다.
• Pull Request로 main에 반영을 요청했습니다.
• 병합 후에도 각 기능의 작업 기록이 남았습니다.

Git을 단순히 소스를 저장하는 도구로만 사용할 때는 Commit과 Push 정도면 충분했습니다. 하지만 여러 사람이 하나의 결과물을 만들기 시작하자 브랜치와 PR이 왜 필요한지 훨씬 분명하게 보였습니다.

실습 저장소: heebaek200/temp_http_server