한 팀에서 신규 서비스 제안서를 작성한다고 가정해 보겠습니다.
기획자는 고객 문제와 기능을 정리하고, 데이터 담당자는 시장 자료를 추가합니다. 디자이너는 서비스 화면을 넣고, 팀장은 전체 내용을 검토한 뒤 최종본을 승인합니다.
그런데 모든 사람이 신규서비스_제안서_최종본.docx를 직접 수정한다면 어떻게 될까요?
기획자가 작성한 문장을 데이터 담당자가 이전 내용으로 덮어쓸 수도 있고, 아직 검토하지 않은 화면이 최종본에 들어갈 수도 있습니다. 문제가 발견되더라도 누가, 언제, 왜 그 문장을 바꿨는지 다시 찾아야 합니다.
결국 이런 파일이 생기기 시작합니다.
신규서비스_제안서_최종본.docx신규서비스_제안서_최종본_수정.docx신규서비스_제안서_진짜최종.docx신규서비스_제안서_진짜최종_팀장검토.docx
GitHub가 해결하려는 문제도 이와 크게 다르지 않습니다.
GitHub는 코드를 보관합니다. 하지만 협업에서 더 중요한 역할은 여러 사람이 같은 프로젝트를 수정하면서 작업이 뒤섞이지 않도록 하고, 무엇을 최종본에 반영할지 함께 검토할 수 있게 만드는 것입니다.
먼저 Git과 GitHub는 구분할 필요가 있습니다.
Git은 각 팀원의 컴퓨터에서 파일과 변경 기록을 관리하는 시스템입니다. GitHub는 Git으로 관리한 프로젝트를 온라인에 보관하고, 팀원들이 작업을 공유하고 검토할 수 있도록 돕는 서비스입니다. GitHub의 Git 소개
Word 문서 협업으로 비유하면 Git은 각 수정본의 버전 기록을 관리하는 방식이고, GitHub는 팀의 Google Drive 공유 폴더와 검수 공간을 합쳐놓은 서비스에 가깝습니다.
전체 개념을 먼저 바꿔보면 다음과 같습니다.
| Git 용어 | 팀의 Word 문서 협업으로 비유하면 |
|---|---|
| Repository | 제안서, 이미지, 참고 자료와 변경 이력이 들어 있는 프로젝트 폴더 |
| Remote Repository | 팀원들이 함께 사용하는 Google Drive의 공용 폴더 |
| Local Repository | 각 팀원이 자신의 컴퓨터에 내려받은 개인 작업 폴더와 변경 이력 |
| Commit | Ctrl+S에 작업자와 수정 내용을 기록하는 일 |
| Push | 내 Commit을 팀의 Google Drive에 올려 다른 사람이 볼 수 있게 하는 일 |
| Pull | 다른 팀원이 반영한 최신 내용을 내 작업 폴더로 가져오는 일 |
| Branch | 최종본을 건드리지 않고 업무별로 만드는 별도의 수정본 |
| Checkout | 지금 내가 작업할 수정본을 선택하는 일 |
| Worktree | 두 가지 업무를 동시에 진행하기 위해 개인 작업대를 하나 더 만드는 일 |
| Pull Request | 수정본을 최종본에 반영해 달라고 팀에 요청하는 검수 절차 |
| Merge | 팀의 검토가 끝난 수정본을 최종본에 합치는 일 |
Repository는 팀의 프로젝트 폴더입니다
Repository는 흔히 ‘레포’라고 줄여 부릅니다.
Repository의 원래 의미는 저장소입니다. 다만 Git의 Repository에는 현재 파일만 들어 있는 것이 아니라 누가 어떤 내용을 바꿨는지에 대한 변경 기록도 함께 들어 있습니다.
신규 서비스 제안서를 만드는 팀이라면 하나의 폴더 안에 Word 제안서만 두지는 않을 것입니다. 화면 이미지, 시장 조사 자료, 매출 계산표와 참고 문서도 함께 보관할 수 있습니다.
Git Repository도 이와 비슷합니다. 하나의 서비스를 만드는 데 필요한 코드와 이미지, 설정 파일 그리고 지금까지의 변경 기록을 하나의 프로젝트로 관리합니다.
Repository는 원격과 로컬로 나뉩니다.
원격 Repository는 GitHub에 있는 팀의 공용 저장소입니다. Google Drive에 있는 공용 프로젝트 폴더와 비슷합니다. 팀이 승인한 최종본과 각 팀원이 공유한 수정본을 이곳에서 확인할 수 있습니다.
로컬 Repository는 각 팀원의 컴퓨터에 있는 저장소입니다.
기획자에게는 기획자의 로컬 Repository가 있고, 프런트엔드 개발자와 백엔드 개발자에게도 각각의 로컬 Repository가 있습니다. 모든 팀원이 하나의 공용 폴더를 직접 수정하는 것이 아니라, 각자의 컴퓨터에서 프로젝트 전체를 내려받아 작업합니다.
원격 Repository를 내 컴퓨터에 처음 내려받는 행위를 Clone이라고 합니다. Clone하면 프로젝트 파일뿐 아니라 지금까지 쌓인 변경 기록도 함께 가져옵니다.
반대로 다른 팀원이 원격 Repository에 반영한 최신 변경 내용을 내 컴퓨터로 가져오는 행위는 Pull이라고 합니다. GitHub의 원격 Repository 설명
예를 들어 기획자가 로그인 문구를 수정해 GitHub에 반영했다면, 개발자는 Pull을 통해 그 변경 내용을 자신의 로컬 Repository로 가져올 수 있습니다.
정리하면 다음과 같습니다.
- 원격 Repository는 팀이 공유하는 기준점입니다.
- 로컬 Repository는 각 팀원이 실제로 작업하는 개인 공간입니다.
- Push는 내 작업을 팀에 공유하는 행위입니다.
- Pull은 팀의 최신 작업을 내 공간에 반영하는 행위입니다.
Google Drive처럼 하나의 파일을 모두가 실시간으로 수정하는 구조와는 조금 다릅니다. Git에서는 각 팀원이 자신의 공간에서 작업한 뒤, 변경 내용을 원격 Repository에 모아 최종본에 반영합니다.
Commit은 Ctrl+S이면서 팀에 남기는 작업 기록입니다
Commit은 Ctrl+S라고 보면 됩니다.
다만 혼자 사용하는 Word 문서의 Ctrl+S보다 조금 더 많은 정보를 남깁니다.
Word에서 Ctrl+S를 누르면 현재 문서가 저장됩니다. Commit은 변경 내용을 저장하면서 누가, 언제, 무엇을 바꿨는지 기록하고, 작업을 설명하는 메시지도 함께 남깁니다. GitHub의 Commit 설명
따라서 Commit은 다음과 같이 이해할 수 있습니다.
Commit =
Ctrl+S+ 작업자 기록 + 수정 내용에 대한 메모
예를 들어 팀원들이 다음과 같은 Commit을 만들 수 있습니다.
- 기획자:
회원가입 정책 문구 추가 - 데이터 담당자:
시장 규모 자료 업데이트 - 디자이너:
회원가입 화면 이미지 교체 - 개발자:
회원가입 오류 메시지 수정
Commit을 이렇게 나누면 다른 팀원도 무엇이 바뀌었는지 이해하기 쉽습니다.
서비스에서 문제가 발견됐을 때도 최근에 누가 무엇을 수정했는지 확인할 수 있습니다. 문제가 생긴 변경만 이전 상태로 되돌리거나, 해당 작업을 담당한 팀원에게 정확한 맥락을 물어볼 수도 있습니다.
Commit 기록은 누가 잘못했는지를 찾기 위한 장부라기보다, 팀원들이 당시의 작업 맥락을 다시 이해하기 위한 기록에 가깝습니다.
다만 Commit했다고 다른 팀원이 바로 볼 수 있는 것은 아닙니다.
Commit은 아직 내 로컬 Repository에만 있습니다. 팀에 공유하려면 Push가 필요합니다.
Push는 내 작업을 팀에 공유하는 일입니다
Push는 로컬 Repository에서 만든 Commit을 원격 Repository로 전송하는 행위입니다.
Word 문서로 보면 내 컴퓨터에서 작성한 수정본을 Google Drive의 팀 폴더에 업로드하는 것과 비슷합니다. Push가 완료돼야 다른 팀원이 GitHub에서 내 Branch와 Commit을 확인할 수 있습니다. GitHub의 Push 설명
Commit과 Push는 같은 행위가 아닙니다.
- Commit은 내 작업 공간에 변경 기록을 저장합니다.
- Push는 저장한 변경 기록을 팀의 원격 Repository에 공유합니다.
개발자가 자신의 컴퓨터에서 여러 번 Commit했더라도 Push하지 않았다면 다른 팀원은 그 작업을 볼 수 없습니다.
반대로 Push했다고 해서 팀의 최종본인 main이 바로 바뀌는 것도 아닙니다. 작업한 Branch가 원격 Repository에 공유됐을 뿐입니다.
그다음 Pull Request를 통해 검수를 받아야 합니다.
Branch는 팀의 최종본을 지키기 위한 수정본입니다
팀에서 가장 먼저 정해야 할 것은 어떤 문서가 현재 최종본인지입니다.
GitHub에서는 기본 Branch인 main이 보통 이 역할을 합니다. 현재 서비스에 반영해도 되는 승인된 코드가 main에 모입니다.
새로운 기능을 만들 때마다 모든 개발자가 main을 직접 수정한다면, 아직 끝나지 않은 작업이나 검토하지 않은 변경이 최종본에 섞일 수 있습니다.
그래서 업무마다 별도의 Branch를 만듭니다.
예를 들어 팀에서 다음과 같은 업무가 동시에 진행될 수 있습니다.
회원가입-개선Branch결제오류-수정Branch메인화면-개편Branch
Word 문서로 보면 신규서비스_제안서_최종본.docx를 직접 수정하지 않고, 각 담당자가 자신이 맡은 업무의 수정본을 따로 만드는 것과 같습니다.
기획자는 회원가입 정책을 정리하고, 개발자는 결제 오류를 수정하며, 디자이너는 메인 화면을 개편할 수 있습니다. 각자의 작업은 서로 다른 Branch에서 진행되므로 검토가 끝나기 전까지 main에는 영향을 주지 않습니다. GitHub의 Branch 설명
여기서 Branch는 팀원별로 하나씩 만드는 공간이라기보다 업무별로 나누는 작업 흐름에 가깝습니다.
한 팀원이 여러 Branch를 담당할 수도 있고, 하나의 Branch를 여러 팀원이 함께 수정할 수도 있습니다. 중요한 것은 누가 작업하느냐보다 어떤 목적의 변경을 분리해서 관리하느냐입니다.
다만 Branch가 실제로 프로젝트 폴더 전체를 복사하는 것은 아닙니다. Git 내부에서는 특정 Commit에서 시작된 별도의 작업 흐름으로 관리합니다.
Word 비유에서는 ‘최종본에서 갈라져 나온 업무별 수정본’이라고 이해하면 충분합니다.
Checkout은 지금 담당할 수정본을 선택하는 일입니다
Branch가 여러 개 있다면 지금 어떤 Branch에서 작업하고 있는지 알아야 합니다.
기획자가 회원가입-개선 수정본을 고쳐야 하는데 실수로 결제오류-수정 수정본을 열어 작업한다면 변경 내용이 엉뚱한 업무에 섞일 수 있습니다.
Checkout은 현재 작업할 Branch를 선택하는 행위입니다.
회원가입-개선 Branch를 Checkout하면 내 작업 폴더의 파일이 해당 Branch의 상태로 바뀝니다. 다시 main을 Checkout하면 승인된 최종본의 상태가 작업 폴더에 나타납니다. Git의 Checkout 설명
따라서 Branch와 Checkout은 구분해야 합니다.
- Branch는 업무별 수정본입니다.
- Checkout은 그중 지금 내 작업대에 펼쳐놓을 수정본을 선택하는 일입니다.
Checkout하기 전에 Commit되지 않은 변경이 남아 있다면 Branch 전환이 막히거나 변경 내용이 다른 Branch로 따라갈 수 있습니다.
팀 협업에서 “어느 Branch에서 작업했나요?”라는 질문이 자주 나오는 이유도 여기에 있습니다. 작업 내용이 맞더라도 Branch를 잘못 선택했다면 다른 업무와 뒤섞일 수 있기 때문입니다.
Git에는 Branch 전환 용도로 git switch라는 명령도 있습니다. 다만 GitHub나 Codex를 사용하다 보면 “이 Branch를 Checkout한다”는 표현도 계속 접하게 됩니다.
Worktree는 두 가지 업무를 동시에 처리하기 위한 별도의 작업대입니다
Branch가 여러 개 있어도 하나의 작업 폴더에서는 기본적으로 한 Branch만 펼쳐놓을 수 있습니다.
한 개발자가 회원가입-개선 Branch를 작업하고 있다고 생각해 보겠습니다. 아직 작업이 끝나지 않았는데 운영 중인 결제 기능에서 긴급한 오류가 발견됐습니다.
개발자는 기존 작업을 잠시 멈추고 결제오류-수정 Branch로 Checkout해야 합니다. 이때 Commit하지 않은 변경이 남아 있다면 먼저 정리해야 하고, 오류를 고친 뒤에는 다시 기존 Branch로 돌아와야 합니다.
Worktree는 이런 상황에서 개인 작업대를 하나 더 만드는 기능입니다.
첫 번째 폴더에서는 회원가입-개선 Branch를 계속 열어두고, 두 번째 폴더에서는 결제오류-수정 Branch를 열 수 있습니다. 개발자는 진행 중인 작업을 억지로 정리하지 않고 두 폴더를 오가며 각각의 업무를 처리할 수 있습니다.
Git의 Worktree는 하나의 Repository에 여러 작업 폴더를 연결해 둘 이상의 Branch를 동시에 Checkout할 수 있도록 합니다. 각 Worktree는 서로 다른 파일 상태를 가지지만 Repository의 Commit 기록은 함께 사용합니다. Git의 Worktree 설명
Branch와 Worktree의 차이는 다음과 같습니다.
Branch는 팀의 업무별 수정본이고, Worktree는 한 팀원이 그 수정본을 펼쳐놓을 개인 작업대입니다.
팀원마다 로컬 Repository가 있다고 해서 Worktree가 필요 없는 것은 아닙니다. Worktree는 여러 사람에게 공간을 나눠주는 기능이 아니라, 한 사람이 협업 과정에서 두 개 이상의 업무를 동시에 다뤄야 할 때 사용하는 기능입니다.
예를 들어 자신의 기능을 개발하면서 다른 팀원의 Pull Request를 직접 실행해 봐야 하거나, 긴급 오류를 수정해야 할 때 유용합니다.
Git은 기본적으로 같은 Branch를 여러 Worktree에서 동시에 Checkout하지 못하게 합니다. 같은 수정본을 두 작업대에서 동시에 고치면 어느 작업 공간의 상태가 기준인지 헷갈릴 수 있기 때문입니다.
Pull Request는 수정본을 팀의 최종본에 반영해 달라는 요청입니다
Branch에서 작업을 마치고 Commit한 뒤 Push하면 수정본이 원격 Repository에 공유됩니다.
하지만 Push했다고 main에 바로 반영되는 것은 아닙니다.
Word 문서로 보면 담당자가 신규서비스_제안서_시장자료수정.docx를 Google Drive에 올린 상태입니다. 이제 수정본을 기존 최종본과 비교하고, 팀의 검토를 받아야 합니다.
Pull Request, 줄여서 PR은 한 Branch의 변경 내용을 다른 Branch에 합쳐달라고 요청하는 기능입니다. 보통 업무 Branch의 변경 내용을 main에 반영하기 위해 사용합니다. GitHub의 Pull Request 설명
PR을 만들면 팀원들은 다음 내용을 함께 확인할 수 있습니다.
- 이 작업을 왜 진행했는지
- 어떤 파일과 문장이 바뀌었는지
- 어떤 Commit이 포함됐는지
- 자동 테스트와 빌드가 통과했는지
- 추가로 수정해야 할 부분이 있는지
Word 문서에서 ‘변경 내용 추적’을 켜고 수정된 문장을 하나씩 검토하는 것과 비슷합니다.
기획자는 요구사항이 올바르게 반영됐는지 확인하고, 다른 개발자는 코드에 문제가 없는지 검토할 수 있습니다. 디자이너는 화면이 의도한 대로 구현됐는지 확인할 수 있고, 보안 담당자는 권한이나 개인정보 관련 문제가 없는지 의견을 남길 수 있습니다.
검토 과정에서 수정 요청이 나오면 작업자는 자신의 Branch를 다시 수정해 Commit하고 Push합니다. 새로 Push한 Commit은 기존 PR에 이어서 반영되므로 팀원들은 수정 전후를 다시 확인할 수 있습니다.
모든 검토가 끝나면 업무 Branch를 main에 Merge합니다. 이때 비로소 수정본이 팀의 최종본에 들어갑니다.
정리하면 다음과 같습니다.
- Push는 내 수정본을 팀에 공유합니다.
- Pull Request는 수정본을 검토해 달라고 요청합니다.
- Review는 팀원들이 변경 내용을 확인하고 의견을 나누는 과정입니다.
- Merge는 검수가 끝난 수정본을 최종본에 반영합니다.
PR을 만들었다고 자동으로 Merge되는 것은 아닙니다.
두 팀원이 같은 부분을 서로 다르게 수정했다면 충돌이 발생할 수도 있습니다. 예를 들어 기획자는 버튼 이름을 ‘가입하기’로 바꿨는데, 다른 Branch에서는 같은 버튼을 ‘시작하기’로 바꿨다면 Git은 어떤 표현이 최종본인지 대신 결정할 수 없습니다.
팀이 결정해야 합니다.
팀의 전체 작업 과정을 연결해 보면
팀에서 회원가입 기능을 개선한다고 가정해 보겠습니다.
먼저 팀원들은 원격 Repository의 main을 Pull해 자신의 로컬 Repository를 최신 상태로 맞춥니다. 모든 사람이 같은 최종본에서 작업을 시작하기 위해서입니다.
회원가입 개선을 담당한 개발자는 회원가입-개선 Branch를 만들고 Checkout합니다. 현재 서비스에 반영된 main은 그대로 유지한 채 새로운 기능을 개발합니다.
작업 중에는 목적에 따라 Commit을 나눕니다.
이메일 입력 검증 추가중복 가입 오류 문구 수정회원가입 완료 화면 연결
작업이 끝나면 Commit을 원격 Repository의 회원가입-개선 Branch로 Push합니다.
이제 Pull Request를 만듭니다. PR에는 왜 회원가입을 변경했는지, 무엇이 바뀌었는지, 어떤 방법으로 확인했는지를 적습니다.
기획자는 요구사항을 확인하고, 다른 개발자는 코드를 검토합니다. 디자이너는 화면을 확인하고 필요한 수정 의견을 남깁니다.
개발자는 피드백을 반영해 다시 Commit하고 Push합니다. 검토가 완료되고 자동 테스트도 통과하면 PR을 Merge합니다.
그러면 원격 Repository의 main이 새로운 최종본으로 바뀝니다.
다른 팀원들은 변경된 main을 Pull해 자신의 로컬 Repository도 최신 상태로 맞춥니다. 이후 새로운 업무는 이 최신 main을 기준으로 다시 Branch를 만들어 시작합니다.
결국 팀의 전체 흐름은 다음과 같습니다.
팀의
main을 Pull한다 → 업무별 Branch를 만든다 → Checkout한다 → 작업하고 Commit한다 → Push한다 → Pull Request를 만든다 → 팀이 검토한다 → Merge한다 → 다른 팀원들이 다시 Pull한다
진행 중인 업무를 유지하면서 긴급한 다른 작업까지 처리해야 한다면 Worktree를 추가하면 됩니다.
이 과정이 유기적으로 돌아가야 팀의 최종본도 지킬 수 있습니다.
무료로 시작해도 충분합니다
개인 프로젝트뿐 아니라 작은 팀도 GitHub Free로 시작할 수 있습니다.
무료 요금제에서도 공개·비공개 Repository를 제한 없이 만들 수 있고, Branch와 Commit, Push, Pull Request를 사용하는 기본적인 협업 흐름을 경험할 수 있습니다. GitHub 요금제 안내
이제 Codex한테 '커밋해줘'라고 해봅시다!