Git Flow vs GitHub Flow

Git Flow vs GitHub Flow 비교

브랜치 구조

Git Flow	GitHub Flow
다중 브랜치 구조 (5개 이상)	단일 메인 브랜치 구조
main / master: 제품 릴리스 이력	main: 항상 배포 가능한 상태
develop: 개발 통합 브랜치	없음 (모든 작업은 main에서 분기)
feature/*: 기능 개발	feature/*: 기능 개발 (명명 규칙은 유사)
release/*: 릴리스 준비	없음
hotfix/*: 긴급 버그 수정	없음 (모든 수정은 main에서 분기)

워크플로우 특징

Git Flow	GitHub Flow
복잡하고 체계적인 프로세스	단순하고 직관적인 프로세스
정기 릴리스 주기에 최적화	지속적 배포(CD)에 최적화
명시적 릴리스 관리	암묵적 릴리스 (병합 = 배포 가능)
릴리스 관리를 위한 전용 브랜치	Pull Request로 코드 리뷰 관리
다양한 환경 지원에 용이	주로 단일 환경 배포에 초점

작업 프로세스

Git Flow

1. develop에서 feature/* 브랜치 생성
2. 기능 개발 완료 후 develop에 병합
3. 릴리스 준비시 release/* 브랜치 생성
4. 테스트 및 버그 수정 후 main과 develop에 병합
5. 긴급 버그는 main에서 hotfix/* 브랜치 생성하여 수정
6. 수정 후 main과 develop에 병합

GitHub Flow

1. main에서 기능 브랜치 생성
2. 기능 개발 및 커밋
3. Pull Request 생성
4. 코드 리뷰 및 논의
5. main에 병합 (병합 = 배포 가능)
6. 배포

적합한 상황

Git Flow	GitHub Flow
대규모 팀과 프로젝트	소규모 팀과 프로젝트
명확한 릴리스 주기가 있는 프로젝트	지속적 배포가 필요한 웹 서비스
여러 버전을 동시에 관리해야 하는 경우	단일 버전만 유지하는 서비스
CI/CD 파이프라인이 복잡한 경우	간단한 CI/CD 파이프라인
리소스가 충분한 대형 조직	빠른 반복과 실험이 필요한 스타트업

결론

현재 두명이서 빠른 개발이 필요한 웹 서비스를 개발해야 하는 상황이므로 GitHub Flow 전략을 사용!

수월하게 진행할 수 있도록 메모장을 이용한 GitHub Flow 전략을 연습!

연습

기초부터 하나하나씩 시작해봅시다

git clone으로 새로 생성한 repository를 불러옴

불러온 후에 cd를 통해 들어가기 + status를 통해 상태 확인

그 후 Frontend(123) 와 Backend(내용 321)을 수동으로 생성해서 저장해주었다

git status로 상태 확인

변경된 파일을 확인 후
add . 로 스테이지에 올리고 commit!

git push origin main 으로 초기화를 하고 시작하려고 했으나

이 오류는 로컬 저장소와 원격 저장소가 동기화되어 있지 않을 때 발생
GitHub에서 저장소를 생성할 때 README.md 파일을 자동으로 생성했거나, 다른 커밋이 이미 있는 경우에 이런 상황이 발생한다.
해결하기 위해서 git pull origin main

그 후 git push origin main

push를 통해 원격 저장소 main branch에 파일 두개가 저장된 것을 확인!

이제 본격적으로 시작!

git checkout main 을 통해 최신상태를 확인 후
git checkout -b feature-frontend-update feature+설명 branch를 만들면서 이동

메모장을 수정해서 저장한 후
git status를 사용해서 확인

git add 후 commit 해준 후 push
꿀팁 처음 브랜치를 파고 원격저장소에 푸시할 때 push -u(추적 관계 설정) 를 해주면 git push, git pull로 편하게 사용 가능!

원격 저장소의 feature-frontend-update branch에 Frontend가 반영된 것을 확인!

이제 수정을 합쳐봅시다

New pull request 클릭

compare 합칠 브랜치 (변경 내용도 확인)

제목과 내용 설정 후 Create pull request!

Merge pull request를 통해서 main 브랜치로 병합!

Confirm merge (원래는 팀원이 코드를 리뷰하고 승인)

main branch에 잘 병합된 것을 확인할 수 있다

로컬에서 다시 main 브랜치로 돌아온 후 pull로 최신화! (브랜치 삭제는 선택!)

팀원끼리 분업을 완벽하게 해서 충돌이 안일어나면 이정도로도 협업이 가능하다.. 하지만 코드가 복잡해질수록 충돌이 안 일어날 수 없는 법 충돌 시뮬레이션까지 해봅시다