[한컴AI 아카데미 | 2026.05.26 | Day 57] Git Workflow

1. Git 워크플로우(Git Workflow)란?

Git 워크플로우는 개발 팀이 코드를 작성하고, 수정하고, 병합(Merge)할 때 따르는 일련의 규칙이자 프로세스이다.

정해진 정답은 없으며, 팀의 규모, 프로젝트의 복잡도, 배포 주기 등에 따라 적절한 방식을 선택하여 사용한다.

2. 주요 Git 워크플로우 5가지

1️⃣ 중앙집중식 워크플로우 (Centralized Workflow)

• 개념: SVN 방식과 유사하게, 하나의 중앙 저장소(단일 main 또는 master 브랜치)만 사용하는 방식이다.
• 특징: 모든 개발자가 별도의 브랜치 없이 main 브랜치에 직접 코드를 커밋하고 푸시(Push)한다.
• 장점: 구조가 매우 단순하여 초보자나 소규모 팀, 단기 프로젝트에 적합하다.
• 단점: 여러 명이 동시에 작업할 때 충돌(Merge Conflict)이 빈번하게 발생하며, 메인 코드가 쉽게 망가질 위험이 있다.

---

진행 순서

 

1. 중앙 저장소 복제: 서버에 있는 원격 저장소를 내 로컬 컴퓨터로 가져온다. 👉 git clone
2. 코드 수정 및 커밋: main 브랜치에서 바로 코드를 수정하고 로컬에 커밋한다. 👉 git commit
3. 최신 코드 가져오기: 원격 저장소에 그새 다른 사람이 올린 코드가 있는지 확인하고 가져온다. 👉 git pull
4. 중앙 저장소로 푸시: 충돌이 없다면 내 커밋을 원격 main 브랜치로 바로 올려버린다. 👉 git push

 

 

2️⃣ 기능 브랜치 워크플로우 (Feature Branch Workflow)

• 개념: 핵심이 되는 main 브랜치는 그대로 두고, 새로운 기능(Feature)을 개발할 때마다 독립된 브랜치를 만들어 작업하는 방식이다.
• 특징: 기능 개발이 완료되면 코드 리뷰(Pull Request)를 거쳐 main 브랜치에 병합한다.
• 장점: 메인 코드가 안전하게 보호되며, 기능별로 독립된 작업과 체계적인 코드 리뷰가 가능해져 현대 애자일(Agile) 팀에서 가장 선호한다.
• 단점: 브랜치 관리가 제대로 되지 않으면 브랜치가 너무 많아져 복잡해질 수 있다.

---

진행 순서

 

1. 최신 상태 동기화: main 브랜치를 최신 상태로 업데이트한다. 👉 git pull origin main
2. 독립 브랜치 생성: 만들고 싶은 기능의 이름을 따서 새 브랜치를 파고 이동한다. 👉 git checkout -b feature/login
3. 기능 개발 및 푸시: 작업 후 커밋한 뒤, 내 기능 브랜치 이름 그대로 원격 저장소에 올린다. 👉 git push origin feature/login
4. Pull Request(PR) 생성: 깃허브(또는 깃랩)로 이동해서 "내가 만든 이 기능 main에 합쳐줘!" 하고 PR을 날린다.
5. 리뷰 및 병합: 팀원들의 코드 리뷰와 승인(Approve)을 받으면 원격에서 main 브랜치로 코드를 합친다 👉 Merge
6. 로컬 정리: 내 컴퓨터로 돌아와 main으로 이동한 뒤, 합쳐진 최신 코드를 받고 썼던 기능 브랜치는 삭제한다.

 

3️⃣ 깃플로우 (Gitflow Workflow)

• 개념: 프로젝트의 배포(Release) 주기를 엄격하게 관리하기 위해 브랜치의 역할을 고도로 세분화한 구조적인 방식이다.
• 5가지 핵심 브랜치:
  • main: 항상 제품으로 출시 가능한 상태의 안정된 코드만 관리
  • develop: 다음 버전을 출시하기 위해 개발 중인 기능을 모으는 통합 브랜치
  • feature/*: 새로운 기능을 개발하는 임시 브랜치
  • release/*: 출시 전 최종 테스트와 버그 수정을 진행하는 브랜치
  • hotfix/*: 이미 배포된 서비스에서 긴급하게 발생한 버그를 수정하는 브랜치
• 장점: 대규모 프로젝트와 정기적인 릴리즈 사이클이 있는 엔터프라이즈 환경에 매우 적합하다.
• 단점: 구조가 복잡하여 소규모 팀이나 빠른 배포(CI/CD)를 지향하는 팀에는 다소 무겁고 느릴 수 있다.

---

진행 순서

 

1. 시작은 언제나 develop: 새로운 기능을 만들 기점을 잡기 위해 develop 브랜치로 이동한다.
2. 기능 브랜치 생성 및 개발: feature/* 브랜치를 파서 기능을 개발하고, 완료되면 develop 브랜치로 합친다. 👉 이 과정을 여러 팀원이 반복
3. 출시 준비 (release): 다음 버전 배포일이 다가오면 develop에서 release/v1.0 브랜치를 새로 만든다. 👉 새로운 기능 추가 없이, 오직 버그 수정과 출시 테스트만
4. 마스터 배포 및 태깅: 출시 준비가 끝나면 release 브랜치를 main 브랜치로 합치고 "v1.0" 같은 태그를 단다.
5. 개발 브랜치 동기화: 배포용 수정사항이 반영되었으니 release 브랜치를 develop 브랜치에도 다시 합쳐준다.
6. 긴급 패치 (hotfix): 서비스 도중 갑자기 에러가 터지면, main에서 바로 hotfix/bug 브랜치를 파서 수정한 뒤 main과 develop 양쪽에 동시에 합쳐준다.

 

4️⃣ 포킹 워크플로우 (Forking Workflow)

• 개념: 하나의 중앙 저장소를 공유하는 것이 아니라, 각 개발자가 중앙 저장소를 자신의 계정으로 '복제(Fork)'하여 독립된 개인 원격 저장소를 운영하는 방식이다.
• 특징: 자신의 저장소에서 작업한 후, 원본 저장소의 관리자에게 "내 코드를 반영해달라"고 요청(Pull Request)을 보낸다. 오직 관리자만이 원본 코드에 병합할 권한을 가진다.
• 장점: 원본 저장소의 보안이 강력하게 유지되므로, 서로 모르는 수많은 개발자가 참여하는 오픈소스 프로젝트에 필수적이다.
• 단점: 저장소를 양쪽 모두 동기화해야 하므로 초보자가 관리하기에 다소 까다롭다.

---

진행 순서

 

1. 저장소 복제(Fork): 원본 공식 저장소(Upstream) 페이지에서 'Fork' 버튼을 눌러 내 깃허브 계정으로 똑같은 저장소(Origin)를 복사해 온다.
2. 로컬 다운로드: 내 계정으로 복사된 저장소를 내 컴퓨터로 클론한다. 👉 git clone [내 깃허브 주소]
3. 원격 주소 연결: 내 컴퓨터에 원본 저장소 주소도 별도로 등록해 둔다. 👉 git remote add upstream [원본 주소] 
4. 기능 개발 및 내 저장소 푸시: 새 브랜치를 파서 코드를 수정한 뒤, 내 계정의 원격 저장소로 푸시한다. 
5. 원본에 기여 요청(PR): 내 깃허브 저장소로 가서 "원본 저장소 관리자님, 제가 고친 코드 좀 가져가 주세요!" 하고 원본 저장소를 대상으로 PR을 보낸다.
6. 관리자 승인: 원본 저장소 관리자가 코드를 검토하고 마음에 들면 합쳐준다. 👉 Merge

 

5️⃣ 트렁크 기반 개발 (Trunk-Based Development)

• 개념: 모든 개발자가 하나의 '트렁크(Trunk, 주로 main 브랜치)'라고 불리는 중앙 브랜치에 매일 혹은 하루에도 여러 번 자주 코드를 병합하는 방식이다.
• 특징: 브랜치의 수명을 수 시간~수 일 정도로 매우 짧게 유지하며, 자동화된 테스트(CI/CD)를 통해 빠른 배포를 추구한다.
• 장점: 병합 충돌을 최소화하고 피드백 루프가 매우 빠르다.
• 단점: 높은 수준의 자동화 테스트 환경과 개발자들의 역량이 요구된다.

---

 

1. 메인에서 아주 짧은 브랜치 생성: main(트렁크) 브랜치에서 바로 아주 작은 단위의 기능을 개발할 브랜치를 만든다.
2. 빠른 코딩 및 커밋: 반나절이나 최대 하루를 넘기지 않을 정도의 아주 작은 분량만 코딩하고 커밋한다.
3. 지속적 통합(CI) 가동: 코드를 main에 합치기 전, 자동화된 테스트 봇이 내 코드가 기존 시스템을 망가뜨리지 않는지 자동으로 검사한다.
4. 메인에 즉시 병합: 테스트를 통과하면 바로 main 브랜치로 코드를 합쳐버린다.
5. 무한 반복 및 자동 배포: 팀원 전체가 하루에도 몇 번씩 이 과정을 반복하며, main에 코드가 합쳐질 때마다 배포 시스템(CD)이 자동으로 유저에게 서비스를 업데이트한다.

 

3. 우리 팀에 맞는 워크플로우 선택 가이드

• 학생, 해커톤, 아주 작은 프로젝트: 중앙집중식(Centralized)
• 일반적인 스타트업, 애자일 개발 팀: 기능 브랜치(Feature Branch)
• 대기업, 엄격한 출시 주기가 필요한 프로젝트: 깃플로우(Gitflow)
• 오픈소스 프로젝트, 외부 기여자가 많은 경우: 포킹(Forking)

4. Git 워크플로우 실천을 위한 모범 사례

1. 작고 잦은 커밋: 한 번에 큰 변경사항을 올리지 말고, 의미 있는 단위로 나누어 커밋한다.
2. 명확한 브랜치 네이밍: feature/login, bugfix/issue-12와 같이 직관적인 이름을 사용한다.
3. 지속적인 동기화: 메인 브랜치의 최신 코드를 자주 가져와(Pull/Fetch) 충돌을 예방한다.
4. 코드 리뷰 필수화: Pull Request(PR) 시스템을 활용해 팀원 간 교차 검증을 거친 후 병합한다.

 

 

 

[참고]

Gitflow Workflow | Atlassian Git Tutorial

How to stop using feature branches - codefortynine GmbH

Git - 분산 환경에서의 워크플로

알잘깔딱센 GitHub 핵심개념 | 위니북스

[Git] GitHub로 협업하기 - Forking Workflow

————————————————————————————————————————————————————— 

 

본 후기는 [한글과컴퓨터x한국생산성본부x스나이퍼팩토리]

한컴 AI 아카데미 (B-log) 리뷰로 작성 되었습니다.