[Git] Git-Flow 전략

📚 들어가기

---

세미프로젝트를 진행하면서 사용했던 GitHub 전략에 수정이 필요했다. 

 

초기에는 메인 브랜치에서 팀원들의 코드를 병합하고, 개인마다 브랜치를 하나씩 줬지만 여러 가지 오류가 생겼다. 팀원 모두 GitHub를 능숙하게 사용하지 못해 결국 너나 할 것 없이 모두 메인 브랜치에 올리게 되는 상황이 발생했다. 프로젝트 중간에 CI/CD를 도입하면서, 메인 브랜치에 오류가 생기면 Jenkins가 배포를 실패하거나 잘못된 배포가 이루어지는 일이 생겼다. 병합 충돌 문제를 해결하지 못하는 등 여러 문제가 발생했다. 

 

이런 문제점을 해결하기 위해 파이널 프로젝트에서는 GitHub 전략을 상세하고 계획적으로 세워야 한다는 것을 인지했다.

 

👨🏻‍💻 사용방법

---

📌 GitFlow 전략

 

Main Branch
최종 프로젝트의 배포를 담당하고 Feature 브랜치는 이 브랜치를 상시 주시해야 된다
Develop Branch
각자 개발한 프로젝트의 기능들을 병합하여 최종적으로 테스팅 및 디버깅하는 브랜치
Feature Branch
개인 인원마다 하나씩 부여하여 개발한 기능을 업로드하여 관리하는 브랜치

 

📌 초기 세팅

git clone 깃허브 주소
깃허브 내용 가져오기

cd 프로젝트명
프로젝트로 이동

git remote -v
원격 주소가 맞는지 확인

git branch -r             
원격 저장소의 브랜치 확인

git checkout -b feature-username origin/feature-username
원격 저장소의 develop 브랜치에서 새로운 feature 브랜치 생성 이동

git pull origin main
feature 브랜치에서 main에 있는 최신 변경 사항 병합

 

📌 프로젝트 진행 (내 변경사항 push)

git fetch
원격 저장소의 변경 사항을 로컬로 가져오는 명령어

git add .
로컬 저장소의 변경사항 저장 *add 뒤에 띄어쓰기 후 온점*

git commit -m “커밋메세지”
push 하기 전 커밋 메세지

git push origin/feature-username
원격 저장소에 push

 

📌 프로젝트 진행 (develop 브랜치로 옮겨서 테스트)

git checkout develop
develop 브랜치로 이동

git pull origin develop
원격 develop 브랜치의 최신 변경 사항 가져오기

git merge feature-username
develop에서 하위 노드인 feature 변경사항 merge 이후 병합 충돌 해결

git push origin develop
해결 완료 후 develop 브랜치에 push

git checkout feature-username
feature-username 브랜치로 돌아가기

git branch
현재 브랜치 확인 후 작업 진행

 

📌 메인 브랜치로 최종 이동

Develop 브랜치에서 작업 완료
모든 기능이 개발되고 테스트가 완료된 상태에서 develop 브랜치에 있는 변경 사항을 메인 브랜치로 병합합니다.

Pull Request 생성
GitHub 웹사이트에 로그인하고, 해당 저장소로 이동합니다.
"New Pull Request" 버튼을 클릭합니다.
"base" 브랜치를 main으로 설정하고, "compare" 브랜치를 develop으로 설정합니다.
Pull Request 제목과 설명을 작성하고 "Create Pull Request" 버튼을 클릭합니다.

코드 리뷰 및 병합
팀원들이 Pull Request를 리뷰하고, 피드백을 주고받습니다.
자동화된 테스트가 설정되어 있다면, 이 과정에서 테스트가 자동으로 실행됩니다.리뷰가 완료되고 모든 테스트가 통과하면, "Merge Pull Request" 버튼을 클릭하여 develop 브랜치를 main 브랜치에 병합합니다.