Git / Git Workflow 가 뭘까?
Git과 Git Workflow의 이해
버전 관리 시스템
버전 관리
버전 관리는 소프트웨어 개발 및 유지 보수 과정에서 발생하는 소스 코드, 문서 등의 생성, 변경 이력, 삭제 이력 등을 관리하는 것이다.
우리는 다음과 같은 상황에서 버전 관리의 필요성을 느낀다
- 파일의 이전 버전으로 되돌리기가 어려운 경우
- 여러 사람이 협업할 때 파일 충돌이 발생하는 경우
- 변경 사항 추적이 어려운 경우
- 백업과 복구가 필요한 경우
버전 관리의 필요성
버전 관리 없이 작업할 때
프로젝트_최종.zip
프로젝트_최종2.zip
프로젝트_최종_진짜최종.zip
프로젝트_최종_완료.zip이런 방식의 문제점은 어떤 파일이 최신인지 알기 어렵고, 변경 내용을 파악하기 힘들며 협업시 파일 충돌 발생, 특정 시점으로 되돌리기(롤백)이 복잡하다.
버전 관리 시스템(VCS, Version Control System)
버전 관리 시스템은 파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전을 다시 불러올 수 있는 시스템이다.
1. 로컬 버전 관리 시스템(Local VCS)
- 간단한 데이터베이스를 이용해 파일의 변경 정보를 관리
- 대표적으로 RCS(Revision Control System)
- 개인 컴퓨터에서만 사용 가능
2. 중앙 집중식 버전 관리 시스템(CVCS)
- 파일과 변경 이력을 중앙 서버에서 관리
- 클라이언트는 서버에서 특정 버전을 받아서 사용
- 대표적으로 SVN, CVS
문제점
- 서버 장애 시 작업 불가능
- 오프라인에서 사용할 수 없음
- 모든 작업이 서버를 경유해야 해서 속도가 느림
- 서버 데이터 손실 시 복구 어려움
3. 분산식 버전 관리 시스템(DVCS)
- 각 클라이언트가 전체 저장소의 복사본을 보유
- 서버가 없어도 독립적으로 작업 가능
- 대표적으로 Git, Mercurial, Bazaar
Git
Git의 특성
Git은 리누스 토르발즈가 2005년에 개발한 분산 버전 관리 시스템으로, 여러 명의 개발자가 하나의 소프트웨어 개발 프로젝트에 참여할 때 소스 코드를 관리하는 데 사용된다.
Git의 주요 특징
- 분산형 구조: 모든 개발자가 전체 이력을 가짐
- 빠른 브랜치: 가벼운 브랜치 생성과 병합
- 오프라인 작업: 네트워크 연결 없이도 대부분의 작업 가능
- 무결성: SHA-1 해시를 통한 데이터 무결성 보장
Git의 기본 용어
- Repository: 프로젝트 저장소
- Commit: 변경사항을 저장소에 기록
- Branch: 독립적인 작업 공간
- Merge: 브랜치를 합치는 작업
- Push: 로컬에서 원격 저장소로 업로드
- Pull: 원격 저장소에서 로컬로 다운로드
주의: commit(로컬 저장소에 저장)과 push(서버로 전송)는 다른 개념이다.
Git의 기본 용어
저장소 관련
- Working Directory: 실제 작업하는 파일들이 있는 폴더
- Staging Area: 커밋 준비 영역
- Local Repository: 로컬 저장소
- Remote Repository: 원격 저장소
브랜치 관리
- Master/Main: 기본 메인 브랜치
- Feature Branch: 기능 개발용 브랜치
- HEAD: 현재 작업 중인 브랜치의 최신 커밋
Git Workflow
Git은 브랜치로 작업을 관리하는데, 팀에서 브랜치를 어떻게 사용할지에 대해 정해둔 규칙을 Workflow라고 한다.
Git Flow
브랜치의 역할이 명확하고 대규모 프로젝트에 적합한 워크플로우이다. 5개의 브랜치로 관리한다.
브랜치 구조
- Master: 배포 가능한 안정 버전
- Develop: 다음 릴리스를 위한 개발 브랜치
- Feature: 새로운 기능 개발
- Release: 릴리스 준비 및 버그 수정
- Hotfix: 긴급 버그 수정
Git Flow 작업 과정
- 개인 작업은
develop에서feature브랜치를 따서 작업한다. - 개인 작업이 끝나면
develop에 병합한다. develop브랜치에서 배포 준비가 끝나면release브랜치로 분할한다.release브랜치에서 디버깅하고 문제가 없으면master와develop브랜치에 합친다.master브랜치를 배포한다.- 배포 버전에서 급한 문제가 생기면
hotfix브랜치를 따서 작업한다. hotfix에서 버그 수정이 끝나면master와develop에 합친다.
적용 사례:
- 정기적인 릴리스가 있는 프로젝트
- 안정성이 중요한 서비스
- 대규모 팀 프로젝트
GitHub Flow
하나의 메인 브랜치인 master 브랜치를 중점으로 운용하며 pull request를 활용하는 방식의 워크플로우이다.
Pull Request: "작업한 코드가 있으니 내 브랜치를 pull해 검토, 병합해달라"라는 의미
GitHub Flow 작업 과정
- 개인 작업은
feature브랜치에서 작업하며 작업이 끝나면 pull request를 생성한다. - Pull request에서 코드 리뷰 후에 문제가 없으면
master에 병합한다. master에 병합하면 바로 배포 작업을 수행한다. (CI 자동화 권장)
적용 사례:
- 지속적 배포를 하는 웹 서비스
- 빠른 개발 사이클이 필요한 프로젝트
- 소규모 팀 또는 스타트업
GitLab Flow
Master와 Develop 2개의 메인 브랜치로 관리하는 방식의 워크플로우이다. 항상 최신 버전을 유지하지 않아도 되며 배포 버전과 개발 버전을 따로 둘 수 있다는 장점이 있다.
GitLab Flow 작업 과정
develop브랜치는 항상 최신 버전의 코드를 관리하며 작업을 하는 메인 브랜치이다.develop브랜치가 배포되기 적합하다고 판단되면master브랜치에 merge한다.
적용 사례:
- 환경별 배포가 필요한 프로젝트
- 안정성과 유연성을 모두 고려해야 하는 프로젝
Git과 Git Workflow의 구조적 차이
1. Git의 핵심 구성 요소
Git은 다음과 같은 핵심 구성 요소로 이루어져 있다:
- 저장소(Repository): 프로젝트의 모든 파일과 이력 정보를 포함
- 커밋(Commit): 변경 사항의 스냅샷
- 브랜치(Branch): 독립적인 개발 라인
- 원격 저장소(Remote): 서버에 호스팅된 저장소2. 주요 Git Workflow 모델
다양한 Git Workflow 모델이 존재하며, 각각의 특징은 다음과 같다:
Centralized Workflow:
- 중앙 집중식 모델
- 모든 개발자가 main 브랜치 즉 에 직접 커밋
Feature Branch Workflow:
- 각 기능별로 별도의 브랜치에서 개발
- 기능 완성 후 main에 병합
Gitflow Workflow:
- 엄격한 브랜치 구조를 가진 복잡한 워크플로우
- develop, feature, release, hotfix, main 브랜치 활용
Forking Workflow:
- 각 개발자가 원본 저장소를 포크하여 작업
- 풀 리퀘스트를 통해 원본에 기여
포크(Fork) : Git과 같은 버전 관리 시스템에서 다른 사람의 저장소(repository)를 자신의 계정으로 복사하는 것
3. 브랜치 전략 비교
각 워크플로우는 브랜치를 다르게 활용한다:
- Centralized: 주로 단일 브랜치(main) 사용
- Feature Branch: 기능별 임시 브랜치 + main 브랜치
- Gitflow: 영구 브랜치(main, develop) + 임시 브랜치(feature, release, hotfix)
- Forking: 원본 저장소와 포크된 저장소 간의 관계 중심
Git과 Git Workflow의 기술적 차이
1. Git의 내부 동작 방식
Git은 파일 시스템에 기반한 Key-Value(딕셔너리) 저장소로 동작한다:
- Blob: 파일 내용을 저장하는 객체
- Tree: 디렉토리 구조와 blob 참조를 저장
- Commit: 스냅샷과 메타데이터를 저장
- Reference: 특정 커밋을 가리키는 포인터 (브랜치, 태그 등)
2. Git Workflow의 프로세스 차이
워크플로우에 따라 개발 프로세스가 크게 달라진다:
Centralized Workflow 프로세스:
1. 변경 사항 커밋
2. 원격 저장소에서 최신 변경 가져오기(pull)
3. 충돌 해결 후 원격 저장소에 푸시(push)
Gitflow Workflow 프로세스:
1. develop 브랜치에서 feature 브랜치 생성
2. 기능 개발 및 커밋
3. 완성된 기능을 develop에 병합
4. release 브랜치 생성 및 버그 수정
5. release를 master와 develop에 병합
6. 필요시 hotfix 브랜치로 긴급 수정
3. 협업 방식의 차이
워크플로우에 따라 팀 협업 방식이 달라진다:
- Centralized: 직접적인 푸시/풀 모델
- Feature Branch: 코드 리뷰 후 병합 모델
- Gitflow: 체계적인 릴리스 및 유지보수 모델
- Forking: 풀 리퀘스트 기반 오픈소스 기여 모델
Merge 관련
Git은 한 브랜치에서 작업한 내용을 Main 브랜치에 병합(Merge) 할 수 있는 다양한 방법들을 제공한다. 이러한 방법들을 Merge 전략이라고 부른다.
Merge Commit
Create a merge commit은 모든 브랜치의 commit log와 merge log가 동시에 기록되는 방식이다.
특징
- 모든 브랜치의 커밋이 히스토리에 기록됨
- 모든 커밋 정보를 상세하게 파악 가능
- 그만큼 히스토리가 복잡해지는 단점
A---B---C feature
/ \
D---E---F---G main
↑
병합 커밋 생성사용 시기:
- 기능 개발 과정을 완전히 보존하고 싶을 때
- 협업에서 누가 무엇을 개발했는지 추적이 중요할 때
Squash and Merge
Squash and merge는 여러 개의 commit을 하나로 합친 후 merge하는 방식이다.
특징
- 작업 완료된 브랜치의 여러 커밋을 하나로 합침
- 기존 브랜치는 삭제됨
- 상세한 커밋 기록 정보를 잃을 수 있으나 히스토리가 간결해짐
기존: A---B---C feature
/
D---E---F main
결과: D---E---F---G main
↑
A+B+C를 합친 새 커밋사용 시기:
- 실험적 개발 과정을 숨기고 싶을 때
- 작은 기능을 하나의 커밋으로 표현하고 싶을 때
Rebase and Merge
Rebase and merge는 Rebase 기능을 사용해 브랜치를 merge하는 방식으로, 신규 branch의 시작점을 main의 가장 최근 커밋으로 (강제로) 옮기는 것이다.
Rebase란?
메인브랜치와 새로운 브랜치가 각각 추가적인 커밋을 한 경우에서 새로운 브랜치의 시작점을 강제로 옮기는 것이다.
특징
- Merge된 이후의 로그가 하나의 브랜치에서 연속 작업한 것처럼 보임
- 선형적인 히스토리 생성
- 강제성을 가지므로 충돌 해결을 잘해야 함
기존: A---B---C feature
/
D---E---F main
Rebase 후: D---E---F---A'---B'---C' main
↑
선형적 히스토리Fast-forward Merge
메인브랜치는 변경사항이 없고 새로운 브랜치만 변경사항이 있는 상황에서, 단순히 새로운 브랜치를 메인브랜치로 옮기는 것을 말한다.
사용 시기:
- 깔끔한 선형 히스토리를 원할 때
- 개인 작업 브랜치를 정리할 때
Merge 전략 비교
| 방식 | 히스토리 | 장점 | 단점 |
|---|---|---|---|
| 3-way Merge | 복잡한 그래프 | 완전한 이력 보존 | 복잡한 히스토리 |
| Squash Merge | 간단한 선형 | 깔끔한 히스토리 | 세부 이력 손실 |
| Rebase Merge | 깔끔한 선형 | 읽기 쉬운 이력 | 충돌 해결 복잡 |
