GitHub의 main과 branch는 무엇이 다를까?

웹사이트를 개발하다 보면 “브랜치에는 올렸지만 main에는 아직 반영하지 않았다”는 말을 자주 듣는다. 분명 GitHub에 파일을 올렸는데 실제 사이트에서는 보이지 않을 때도 있다. 작업이 사라진 것은 아닐까, 이제 무엇을 해야 할까.

이 차이를 이해하려면 작업 기록을 저장하는 것, 공식 버전에 합치는 것, 웹사이트에 배포하는 것을 구분하면 된다. 서로 이어지는 일이지만 같은 작업은 아니다.

Git과 GitHub부터 구분하기

Git은 파일의 변경 이력을 관리하는 버전 관리 도구다. 이전 상태로 돌아가거나, 다른 작업 흐름을 만들거나, 여러 사람이 만든 변경사항을 합칠 수 있다.

GitHub는 Git 저장소를 원격으로 보관하고 공유하며, 코드 리뷰와 협업을 돕는 서비스다. Git은 인터넷이나 GitHub 없이도 로컬 컴퓨터에서 사용할 수 있다. GitHub에 올리는 작업은 그다음 단계다.

main과 branch: 공식 버전과 별도의 작업 흐름

main은 대개 프로젝트의 공식 기준으로 삼는 기본 브랜치 이름이다. 다만 모든 저장소가 반드시 main을 쓰는 것은 아니다. 저장소에 따라 기본 브랜치 이름이나 배포 대상 브랜치가 다를 수 있다.

branch는 별도의 변경 작업을 진행하기 위한 이름 붙은 작업 흐름이다. 예를 들어 현재 main을 기준으로 feature/new-article이라는 브랜치를 만들고 새 글을 작성할 수 있다.

브랜치를 만든다고 저장소 전체를 물리적으로 복사하는 것은 아니다. Git은 기존 커밋을 공유하고, 각 브랜치가 어느 커밋을 가리키는지 관리한다. 새로운 변경 기록은 해당 브랜치에서 이어진다.

중요한 사실은 작업 브랜치에 파일이 있어도 main에는 아직 없을 수 있다는 점이다.

commit과 push는 왜 따로 있을까

commit은 Git에서 변경사항을 하나의 기록으로 저장하는 동작이다. “글 제목 수정”, “도식 추가”처럼 어떤 변경을 했는지 메시지를 남길 수 있다. 로컬에서 커밋했다면 그 기록은 우선 로컬 저장소에 있다.

push는 로컬에 있는 커밋을 GitHub와 같은 원격 저장소에 보내는 작업이다. commit은 변경 기록 저장, push는 원격으로 전달이라고 기억하면 된다.

반대로 다른 곳에서 올라온 변경 기록을 가져올 때는 fetch나 pull을 사용한다. fetch는 원격 이력을 가져와 확인할 수 있게 하고, pull은 일반적으로 가져온 이력을 현재 브랜치에 통합하는 단계까지 수행한다.

merge와 Pull Request는 무엇일까

브랜치에서 작성한 변경사항이 준비되었다면, 이를 main에 합칠 수 있다. 이때 사용하는 개념이 merge(병합)다.

GitHub의 Pull Request(PR)는 병합을 요청하고 변경 파일을 검토하는 협업 기능이다. PR을 열면 어떤 파일이 바뀌었는지 확인하고, 테스트 결과를 보거나 의견을 나눌 수 있다. 검토 후 Merge를 실행하면 변경사항이 대상 브랜치에 반영된다.

merge는 Git이 변경 이력을 합치는 동작이고, PR은 그 작업을 검토하고 승인하기 위한 GitHub의 절차라는 점에서 다르다. PR 없이 명령어로 병합할 수도 있다.

병합 과정에서는 양쪽에서 같은 부분을 다르게 수정해 충돌(conflict)이 발생할 수도 있다. 이 경우 어느 변경을 유지할지 확인한 뒤 해결해야 한다. 병합 방식에 따라 별도의 병합 커밋이 생기기도 하고, 기존 커밋만 이동하는 형태가 되기도 한다.

배포(deploy)는 병합과 다른 작업이다

배포는 GitHub에 있는 소스코드를 실제 실행 환경에 반영하는 과정이다. 예를 들어 GitHub 저장소를 Cloudflare에 연결하고 main을 Production 브랜치로 지정했다면, main에 새 커밋이 반영될 때 자동으로 빌드와 배포가 시작되도록 구성할 수 있다.

이 경우 흔한 작업 흐름은 다음과 같다.

1. main을 기준으로 작업 브랜치를 만든다.
2. 작업 브랜치에서 파일을 수정하고 commit한다.
3. push하여 GitHub에 작업 기록을 올린다.
4. PR로 변경사항을 검토하고 테스트한다.
5. 검증된 변경사항을 merge하여 main에 반영한다.
6. Cloudflare가 main의 변경을 감지하고 빌드·배포한다.
7. 실제 운영 사이트에서 결과를 확인한다.

하지만 이 흐름이 모든 프로젝트에 똑같이 적용되는 것은 아니다. 배포 대상 브랜치, 자동 배포 여부, 미리보기(Preview) 배포 설정에 따라 결과가 달라진다. 또한 main에 병합했다고 해서 배포가 무조건 성공하는 것은 아니다. 빌드 오류가 날 수 있으므로 실제 배포 완료 상태도 확인해야 한다.

실제 사례: 블로그 새 글을 작업 브랜치에 올렸다면

새로운 블로그 연재를 준비하며 editorial/smart-home-responsive-20261013이라는 브랜치를 만들었다고 가정해 보자. 이 브랜치에 Markdown 원고와 PC·모바일 SVG 도식이 들어가고, GitHub로 push까지 끝났더라도 main과 운영 사이트에는 아직 반영되지 않는다.

브랜치에서 글의 draft 설정을 공개 상태로 바꿨더라도 마찬가지다. 그 변경은 아직 작업 브랜치 안에 있다. 이후 검증을 마치고 main에 병합해야 운영 배포 흐름에 들어간다.

이는 작업이 실패했거나 사라졌다는 뜻이 아니다. 기존 사이트를 유지하면서 새 콘텐츠를 별도로 검토하고 있는 상태다.

언제 main을 수정하고 언제 브랜치를 쓸까

작은 오탈자나 간단한 설명 수정이라면 팀의 운영 규칙에 따라 main에 직접 반영할 수도 있다. 반면 여러 파일을 바꾸는 새 기능, 디자인 개편, 보안 관련 변경, 여러 편의 콘텐츠를 한꺼번에 올리는 작업에는 브랜치와 PR을 사용하는 편이 검토와 복구에 유리하다.

운영 사이트가 GitHub의 main과 연결되어 있다면 특히 검증되지 않은 변경을 main에 직접 push하지 않는 습관이 중요하다. 브랜치는 실패를 막아 주는 마법 같은 보호막은 아니지만, 위험한 변경과 운영 중인 버전을 분리하는 데 도움이 된다.

헷갈릴 때 다시 보는 한 장 요약

브랜치에 push했다는 것은 작업 기록을 GitHub에 올렸다는 뜻이다. main에 merge했다는 것은 그 변경사항을 공식 기준에 합쳤다는 뜻이다. 실제 서비스에 반영되었는지는 배포까지 확인해야 알 수 있다.