[RealPJ] Ch01. Git Flow 전략 알아보기

공부 내용을 정리하고 앞으로의 학습에 이해를 돕기 위해 작성합니다.

 

Git 

주요 명령어

• Commit: 변경 사항을 저장소에 기록한다.
• Push: 로컬에서 커밋된 변경 사항을 원격 저장소에 업로드한다.
• Pull: 원격 저장소의 변경 사항을 로컬 저장소로 가져온다.

Git Flow 전략

• Git Flow는 브랜치를 효과적으로 관리하여 배포까지 안정적으로 진행할 수 있도록 돕는 전략이다.
• 주로 여러 개발자들이 협업하며 발생할 수 있는 브랜치 간의 충돌을 최소화하고, 배포를 안정적으로 할 수 있는 환경을 만든다.

주요 Branch

• Main(= Master): 최종 배포되는 코드가 있는 브랜치이다.
• Dev: 개발 중인 기능들이 통합되는 브랜치이다.
• Feature: 새로운 기능을 개발하기 위한 브랜치이다.
• Release: 배포 전 최종 점검을 위한 브랜치이다.
• Hotfix: 긴급한 문제를 수정하기 위한 브랜치이다.

정기 배포를 위한 Git Flow 전략 

요구 사항

• Login 기능 개발
• Logout 기능 개발

브랜치 구조 및 개발 흐름

• Level 1 (Master): 최종 배포 브랜치
• Level 2 (Dev): 로그인 및 로그아웃 기능 개발을 위한 브랜치
• Level 3 (Feature/login, Feature/logout): 각각의 기능을 개발하는 브랜치
• Level 4 (Release): 배포 전 점검을 위한 브랜치
• Hotfix: 긴급 수정이 필요한 경우 생성하는 브랜치

브랜치 작업 절차

Feature 개발 후 Release 준비

• Dev 브랜치에서 로그인, 로그아웃 기능을 Feature 브랜치로 개발한다.

기능 개발이 완료되면, Release 브랜치를 생성하여 최종 점검을 진행한다.

1. Release Branch 생성 후 추가 작업이 필요해질 경우 

Release 브랜치에서 새로운 브랜치를 생성한다.

 

Release 브랜치에서 새로운 브랜치를 생성해 작업을 마친 후 Master에 Merge한다.

 

Master에 Merge된 후 Dev 브랜치에도 Master를 Merge하여 동기화한다.

 

왜 Master와 Dev 간 Sync를 맞춰야 할까?

- Dev는 Master를 Base로 생성된 Branch이다.

- 그러므로 Dev = Master + @의 코드를 갖고 있어야 한다.

- 만약 Sync가 안 맞을 경우엔 Dev != Master + @가 된다.

- 이런 상태로 누군가 Dev에서 신규 Branch를 생성하게 되면 코드가 꼬이게 된다.

2. Release Branch 생성 후 추가 작업이 없는 경우 

Release Branch를 Master Branch에 Merge 한다.

 

Dev Branch에 Master Branch를 Merge 하여 Master와 Dev의 Sync를 맞춘다.

3. Hotfix가 필요한 경우

다음과 같은 상황에서 운영에서 장애가 발생하여 Hotfix로 이슈를 수정하여 배포가 나가야 한다고 가정한다.

 

Master Branch를 기준으로 Hotfix Branch를 생성한다.

 

Hotfix Branch에 수정 작업을 진행한다.

 

Hotfix 작업이 끝나면 Master Branch에 Merge 한다.

 

Dev Branch에 Master Branch를 Merge 하여 Master와 Dev의 Sync를 맞춘다.

 

이 후 신규 작업은 Dev Branch를 Base로 새로운 Feature Branch를 생성한다

 

Hotfix 이 후 왜 Master와 Dev 간 Sync를 맞춰야 할까?

- Master를 Dev에 Merge 하지 않고

- Dev에서 Feature Branch 생성하게 되면

- 최신 코드가 아닌 상태로 개발이 진행된다.

 

Git Flow 실습

1. Release Branch 생성 후 추가 작업이 필요해질 경우 

프로젝트 생성 및 초기 설정

• 프로젝트를 하나 생성하고, 이를 SourceTree에서 연다.

• GitHub에서 리포지토리를 하나 만들고, 첫 번째 커밋을 한 후 이를 원격 저장소에 푸시한다.

브랜치 생성 및 커밋

• 단축키 Command + Shift + B를 사용해 브랜치를 만든다.
• 첫 번째로 dev 브랜치를 생성한다.

• README.md 파일에 dev 브랜치 생성이라는 내용을 추가하고 커밋한다.

이후 feature/login, feature/logout 브랜치를 각각 생성한다.

 

• feature/login 브랜치로 이동하여 login 기능 구현 내용을 추가하고 커밋한다.

• feature/logout 브랜치로 이동하여 logout 기능 구현 내용을 추가하고 커밋한다.

Feature 브랜치 개발 완료 후 Merge

feature/login과 feature/logout 브랜치를 dev 브랜치로 머지한다.

이 과정에서 충돌이 발생하면, 충돌을 해결한 후 다시 커밋한다.

이제 더 이상 새로운 feature 기능이 필요가 없다. 이제 릴리즈 브랜치로 생성하는데 사용하면 된다. 

 

dev 브랜치에서 release 브랜치를 생성한다.

만약 QA나 테스트 과정에서 추가 기능이 필요하다면, 이 브랜치에서 새로운 기능 브랜치를 생성한다.

 

 

release 브랜치를 생성했는데, QA나 테스트를 하는 과정에서 패스워드를 생성했으면 좋겠다는 의견이 있어서 그 기능을 추가해서 배포하는 걸로 가정한다.

 

그럼 패스워드 로직을 구현하기 위한 브랜치를 구현해야 하는데 주의해야 할 점은, dev에서 생성하는게 아니라 release에서 생성해야 한다.

 

따라서 release에서 feature/find_pw 브랜치를 생성한다.

 

READEME에 새로운 메시지를 추가하고 commit 한다.

 

release 브랜치보다 commit이 하나 더 쌓인 상태로 find_pw 브랜치가 생성되었다.

이제 모든 테스트가 끝났고, 운영에 배포를 하는 시점이 왔다.

find_pw 브랜치 같은 경우는 아직 릴리즈 브랜치에 머지가 되지 않은 상황이기 때문에 릴리즈 브랜치에 find_pw 브랜치를 머지 해줘야한다.

 

release 브랜치로 체크아웃 하고 feature/find_pw 브랜치를 release 브랜치로 머지한다.

 

그 다음에 main 브랜치에 release 브랜치를 머지한다.

 

main 브랜치에서 메시지를 적고 commit 한다.

 

마지막으로, main 브랜치의 내용을 dev 브랜치에 머지하여 두 브랜치 간의 동기화를 맞춘다.

 

2. Release Branch 생성 후 추가 작업이 없는 경우 

Dev 브랜치 생성

Main 브랜치에서 Dev 브랜치를 생성한다. Dev 브랜치는 이후 Feature 브랜치들의 베이스 브랜치가 된다.

 

Dev 브랜치를 체크아웃한 상태에서 feature/login 브랜치와 feature/logout 브랜치를 각각 생성한다.

 

각 Feature 브랜치에서 필요한 기능을 개발한 후, Dev 브랜치로 Merge한다.

Release 브랜치 생성

Dev 브랜치에서 Release 브랜치를 생성한다.

이 브랜치는 배포 전 최종 점검을 위한 브랜치이다.

 

Main 브랜치로 Merge

추가 작업이 필요하지 않다면, Release 브랜치를 Main 브랜치로 Merge한다.

 

이 과정에서 실제 운영 환경에 배포된 것으로 가정할 수 있다.

 

 

마지막으로 Main 브랜치를 Dev 브랜치로 Merge하여, Dev 브랜치가 최신 상태를 유지하도록 한다

3. Hotfix가 필요한 경우

Feature 브랜치 생성

Main 브랜치에서 Dev 브랜치를 생성한 후, feature/login과 feature/logout 브랜치를 각각 생성한다.

각 Feature 브랜치에서 필요한 기능을 개발한 후, Dev 브랜치로 Merge한다.

 

Hotfix 브랜치 생성

운영 중에 발생한 문제를 긴급하게 수정하기 위해 Main 브랜치에서 Hotfix 브랜치를 생성한다.

Hotfix 브랜치는 Main 브랜치를 기준으로 생성된다.

커밋 메시지를 남긴다. 지금은 간단하게 남기지만 실무에서는 어떤 기능을 추가했는지 상세하게 적어야 한다.

로그를 보면 hotfix는 login, logout과 관계없는 메인을 베이스로 새로운 브랜치를 생성했기 때문에 메인 다음에 바로 hotfix로 파란색 그래프로 이어지는 것을 볼 수 있다.

 

수정 작업이 완료되면, Hotfix 브랜치를 Main 브랜치로 Merge한다.

 

Dev 브랜치로 Merge

Main 브랜치에 Merge된 Hotfix 내용을 Dev 브랜치로 Merge하여, Dev 브랜치가 최신 상태를 유지하도록 한다.

Login과 Logout 브랜치는 Hotfix의 내용을 포함하고 있지 않다. 따라서, Hotfix 작업이 완료되어 Main과 Dev 브랜치에 Merge된 후에는 각 Feature 브랜치를 사용하는 개발자들에게 "Hotfix가 Main과 Dev 브랜치에 Merge되었으니, 각 Feature 브랜치에서 Main 브랜치의 최신 내용을 Pull 받아주세요"라고 알린다.

 

login에 체크아웃하고 dev를 머지한다.

 

Git Flow 전략을 통해 브랜치 관리의 중요성과 효율적인 협업 방법을 배웠다. 실습을 통해 각 브랜치의 역할과 사용 시점을 이해할 수 있었다. 앞으로도 꾸준히 실습하며 Git Flow를 익히고, 프로젝트에 적용해 볼 것이다.