Git｜브랜치, 병합, PR을 홈페이지 작업으로 이해하기

지난 글에서는 저장·커밋·푸시의 차이를 살펴봤습니다. 이번에는 GitHub에 코드를 올렸는데도 기본 코드에서 변경 내용이 보이지 않는 이유를 알아보겠습니다.

💬 “새 기능을 GitHub에 푸시했는데, main에서는 안 보여요.”

이 말만 듣고 업로드가 실패했다고 판단할 수 있을까요? 답을 찾으려면 브랜치(branch)를 알아야 합니다.

01. 먼저 커밋을 정확히 이해해 볼까요? 📸

커밋을 처음 배우면 “수정했다는 이력만 남긴다”고 생각하기 쉽습니다. 하지만 커밋은 변경 설명만 기록하는 것이 아닙니다. 선택한 변경 내용과 그 결과로 만들어진 코드 상태를 Git 이력에 기록합니다.

그래서 나중에 이전 코드와 비교하거나, 필요한 경우 이전 상태로 돌아갈 수 있습니다.

저장 → 수정한 내용을 파일에 남깁니다.

커밋 → 선택한 변경을 설명과 함께 Git 이력에 기록합니다.

푸시 → 커밋한 내용을 GitHub 같은 원격 저장소로 보냅니다.

02. 브랜치는 ‘작업의 갈래’입니다 🌿

브랜치(branch)는 영어로 나뭇가지라는 뜻입니다. Git에서는 코드의 변경 이력을 갈래로 나누어 작업할 때 사용합니다.

연구회 홈페이지가 정상적으로 작동하고 있는데, 새 출석 기능을 만들고 싶다고 가정해 보겠습니다.

🏠 main 브랜치

기존 홈페이지 코드를 관리하는 기본 작업 갈래입니다.

📝 attendance 브랜치

출석 기능을 개발하기 위해 만든 작업 갈래입니다. 브랜치 이름은 작업자가 직접 정할 수 있습니다.

출석 기능을 attendance 브랜치에서 수정하고 커밋한 다음 GitHub에 푸시했다고 해 보겠습니다. 이때 새 기능은 GitHub의 attendance 브랜치에서 확인할 수 있지만, main 브랜치의 코드가 자동으로 바뀌지는 않습니다.

💡 핵심 정리

GitHub에 푸시할 때는 어느 브랜치에 올렸는지가 중요합니다. main에서 보이지 않아도 다른 브랜치에는 정상적으로 올라가 있을 수 있습니다.

03. PR을 만들면 바로 합쳐질까요? 🔀

두 갈래의 변경 내용을 합치는 작업을 병합(merge, 머지)이라고 합니다.

PR(Pull Request)은 “이 브랜치의 변경 내용을 검토하고 다른 브랜치에 합쳐 주세요”라고 요청하는 방식입니다. 예를 들어 attendance의 출석 기능을 검토한 뒤 main에 반영해 달라는 요청을 만들 수 있습니다.

📌 세 단계는 각각 다릅니다

푸시: 브랜치의 커밋을 GitHub에 올리기
PR 생성: 변경 내용을 검토하고 합쳐 달라고 요청하기
병합: 변경 내용을 대상 브랜치에 실제로 합치기

따라서 푸시했다고 PR이 자동으로 생기지 않으며, PR을 만들었다고 바로 병합되는 것도 아닙니다.

04. 실제 작업 보고를 읽어 봅시다 🔍

💬 “푸시는 완료했고, PR은 아직 만들지 않았습니다.”

작업한 코드는 GitHub의 해당 브랜치에 올렸지만, 다른 브랜치에 합쳐 달라는 요청은 아직 하지 않았다는 뜻입니다.

동료가 “새 출석 기능을 attendance 브랜치에 푸시했어요”라고 했는데 main에서 새 기능이 보이지 않는다면, 먼저 GitHub에서 보고 있는 브랜치를 attendance로 바꿔 확인해 보세요.

attendance에도 변경 내용이 보이지 않는다면 그때 푸시 대상 저장소와 브랜치, 커밋 내용을 추가로 확인하면 됩니다.

📚 다음 편 예고

다음 편에서는 GitHub에서 브랜치를 바꾸어 확인하는 방법과, AI가 보고하는 커밋 번호·origin·fetch가 각각 무엇을 뜻하는지 실제 문장으로 풀어보겠습니다.