Git

[Git] Git-flow 전략으로 협업하기

sabeom 2024. 1. 4. 17:45

Git-flow 전략 간단하게 살펴보기

Git-flow를 사용했을 때 작업을 어떻게 하는지 살펴보기 전에 먼저 Git-flow에 대해서 간단히 살펴보겠습니다.
Git-flow에는 5가지 종류의 브랜치가 존재합니다. 항상 유지되는 메인 브랜치들(master, develop)과 일정 기간 동안만 유지되는 보조 브랜치들(feature, release, hotfix)이 있습니다.

  • master : 제품으로 출시될 수 있는 브랜치
  • develop : 다음 출시 버전을 개발하는 브랜치
  • feature : 기능을 개발하는 브랜치
  • release : 이번 출시 버전을 준비하는 브랜치
  • hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치

위 그림을 일반적인 개발 흐름으로 살펴보겠습니다.
처음에는 master와 develop 브랜치가 존재합니다. 물론 develop 브랜치는 master에서부터 시작된 브랜치입니다. develop 브랜치에서는 상시로 버그를 수정한 커밋들이 추가됩니다. 새로운 기능 추가 작업이 있는 경우 develop 브랜치에서 feature 브랜치를 생성합니다. feature 브랜치는 언제나 develop 브랜치에서부터 시작하게 됩니다. 기능 추가 작업이 완료되었다면 feature 브랜치는 develop 브랜치로 merge 됩니다. develop에 이번 버전에 포함되는 모든 기능이 merge 되었다면 QA를 하기 위해 develop 브랜치에서부터 release 브랜치를 생성합니다. QA를 진행하면서 발생한 버그들은 release 브랜치에 수정됩니다. QA를 무사히 통과했다면 release 브랜치를 master와 develop 브랜치로 merge 합니다. 마지막으로 출시된 master 브랜치에서 버전 태그를 추가합니다.

 

 

Git-flow 우린 이렇게 사용해요.

1. Fork Repository

Organization Repository

 

Create new fork

 

2. Clone Repository

Clone Repository

git clone [Repository URL]

 

3. Git 설정

# 사용자정보
git config --global user.name "sabeom"
git config --global user.email sabumi2002@naver.com

# git 연동 확인
git remote -v

# git origin 설정
git remote add origin [포크한 원격저장소]

# git upstream 설정
git remote add upstream [원본 원격저장소]

# git 연동 재확인
git remote -v

origin과 upstream 등록정보 확인

 


4. Branch 생성 전 Fork한 Repository Sync

  • 브랜치 분기 전에 베이스-브랜치(dev)를 항상 최신으로 동기화
git fetch upstream
git checkout dev
git merge upstream/dev
git push

git fetch upstream
gir checkout dev
git merge upstream/dev
git push
만약 원본브랜치에 변경사항이 있다면 최신으로 동기화 한다.

 

 

5. Branch 생성

git checkout -b [브랜치 명]	//ex) git checkout -b feature-login

local repository에 브랜치(feature-login)가 생성됬는지 확인

 

6. 생성한 브랜치에서 필요 시 commit & push

생성한 브랜치(feature-login)에서 commit&push

 

7. 리베이스 사전작업으로 Fork한 Repository Sync

  • 두 브랜치를 병합하기 전에 베이스-브랜치(dev)를 항상 최신으로 동기화
git fetch upstream
git checkout dev
git merge upstream/dev
git push

 

8. Rebase

git checkout [병합할 브랜치 명]	//ex) git checkout feature-login
git rebase origin/dev

9. Solve Conflict & Commit & Push

충돌 발생 시 해결 후 커밋&푸시 진행

 

10. Squash & Merge

git checkout dev
git merge --squash [브랜치 명]	//ex) git merge --squash feature-login
git commit -m "[커밋 명]"
git push

기존의 커밋들이 하나로 합쳐져서 병합됬는지 확인

 

11. Branch 삭제

  • 로컬브랜치 삭제 
git branch -D [브랜치 명]	//ex) git branch -D feature-login
  • 원격브랜치 삭제
git push [원격 저장소 이름] -d [원격 브랜치 이름]	//ex) git push origin -d feature-login

브랜치(feature-login)가 정상적으로 삭제됬는지 확인

 

12. Pull Request

  • 1. Open pull request

Open pull request

  • 2. Create pull request

Create pull request

  • 3. pull request 확인

pull request: 1. 승인 or 2. 거절

1. Merge pull request를 클릭하면 승인 => Confirm merge로 넘어간다.
2. Close pull request를 클릭하면 거절

 

  • 4. Confirm merge

Confirm merge

Merge pull request를 클릭 후 Confirm merge를 누르면 pull request가 완료된다.

 

13. Full Request 후 Fork한 Repository Sync

git fetch upstream
git checkout dev
git merge upstream/dev
git push

PullRequest가 정상적으로 됬는지 확인

 

 

 

Rebase, Squash 사용 이유

rebase와 squash를 사용하면 그래프가 얼마나 단순해지는지 볼 수 있습니다.

Rebase, Squash 사용 X
Rebase, Squash 사용 O

 

 

Reference

1. 우아한기술블로그 git-flow

2. [git] merge, squash, rebase 등 참고

3. [git] Git-flow vs Github-flow

4. [git] 협업: Fork부터 Pull Request 까지

5. [git] rebase 참고 (vi)

6. [git] 여러가지 상황에서 명령 취소(되돌리기)

7. [git] github에 push된 commit 삭제하기

8. [git] push한 파일에 .gitignore 적용하기

9. [git] 자주 사용할 것 같은 명령어 정리