git 전략 : 작업 브랜치 생성

이번 프로젝트는 실제 프로젝트를 진행하는 것처럼 작업 브랜치를 분기하여 진행하였다.

 

즉, main 브랜치에 직접 코드를 작성하거나 push하는 행위는 절대 금지 

 

git 전략

 

개념

다양한 git 전략이 있지만 아래와 같은 그림에서의 "Gitflow" 전략을 간단히 정리해보았다. 

• 브랜치를 특정 목적에 맞게 구성하고, 병합 과정을 통해 개발과 배포를 관리하는 방식으로 운영한다.
• 각각의 브랜치는 특정 작업 단계나 기능 구현, 버그 수정 등을 담당한다.
• 팀 단위의 협업이나 지속적인 배포에 유용하며, 프로젝트의 안정성과 효율성을 높일 수 있다. 
  1. 어떠한 제품의 요구 발생시 하나의 레포지터리가 생성되며 그와 동시에 master(이하 main) branch 생성
  2. Main branch가 생성되면 바로 개발을 위한 develop branch를 생성하고 이를 default branch로 설정
  3. Feature branches는 develop  branch로부터 생성되며 하나의 기능(Story)을 작성할때 마다 발생 
  4. 하나의 feature branch가 개발이 완료되면 develop branch(Epic)에 병합
  5. Story가 모여 한 Epic(기능들의 집합)을 이루게되면 release branch가 생성
  6. Release branch가 완료되면 main branch와 develop branch 모두에 병합
  7. 만약 master branch에서 문제가 감지되면 hotfix branch는 main branch로 부터 생성
  8. Hotfix branch가 완료되면 main branch와 develop branch 모두에 병합

 

적용

안내 받은 브랜치 전략은 아래와 같았지만, gitFlow를 적용해도 되냐는 질문에 처음 시도해보는 수업 내용이라 git 전략까지는 고려를 못 하셨다며 그래도 된다는 답변이 돌아왔다. 

• 차이점은 아래 방법은 main 브랜치에서 기능 브랜치를 딴 후, PR을 보낸 후 merge하는 방식이다.
• gitFlow는 main 브랜치에서 dev 브랜치를 분기하고, 거기서 기능 브랜치를 또 분기하는 방식이다.

 

위의 개념을 참고하여 다음과 같은 과정으로 작업을 했다. 

• 우선 main 브랜치로부터 dev 브랜치를 분기했다.
• 그 뒤, dev 브랜치를 기본 브랜치로 설정했다. 

 

그 뒤, dev 브랜치로부터 feature branches를 생성했다. 

• 예를 들어 헤더를 개발하고자 할 때 'feat/header' 라는 이름의 브랜치를 생성했다. 
  • 보통은 하나의 기능을 개발하고, PR을 날려 코드 리뷰를 한 후에 dev 브랜치에 병합한다고 한다. 
  • 하지만 이번 스프린트에서는 3일 차, 4일차, 5일차 최종 작업물에 한해 코드 리뷰를 진행하기 때문에 여기서는 기능 개발이 완료되면 로컬에서 바로 병합시키고, 마지막 dev 브랜치를 main 브랜치로 PR하기로 했다. 

 

git CLI

내가 한 git CLI를 정리해보았다. 이번에 git CLI를 사용하면서 어느정도 개발 플로우에 익숙해진 것 같다.

• (main 브랜치에서) git checkout -b dev
  
  • main 브랜치를 기반으로 git checkout -b dev 을 command line에 작성하면 새로운 'dev' 브랜치가 생성됨과 동시에 해당 브랜치로 옮겨가게 된다.
• git push origin dev
  • 작업이 완료된 dev 브랜치를 원격 레포지토리(origin)으로 push하여 main으로 PR할 준비를 하면 된다.
  • 여러 개의 기능(story)을 묶어 큰 범위의 작업 단위(epic)로 PR한다.
• (dev 브랜치에서) git checkout -b feat/header
  • dev 브랜치를 기반으로 기능 구현을 위한 브랜치 분기를 해준다.
• git checkout dev -> (dev 브랜치에서) git merge feat/header
  • feature/header 기능이 완료가 되었다면 (솔로 프로젝트이기 때문에 여기서 각 기능에 대한 동료 코드리뷰는 생략) dev 브랜치에 내용을 병합한다.
• (dev 브랜치에서) git branch -d feat/header
  • 완료된 기능 브랜치는 바로 삭제해준다. 추후, 해당 기능에 수정사항이 생기는 경우 다시 만들어주면 된다.
  • 나중에 origin에 있는 브랜치들도 dev, main을 제외하고는 다 삭제해준다. 

 

그외에도 중간 커밋 내용 수정하기, 브랜치 이름 수정하기 등 다양한 CLI를 쓸 수 있는 시간이었다.

필요한 부분은 그때그때 찾아가며 기록해두자!

 

• git branch : 지역 브랜치 목록 보기
• git branch -r : 원격 브랜치 목록 보기
• git branch -a : 지역과 원격을 포함한 모든 브랜치 목록 보기
• git -m feature/header feat/header : feature/header로 브랜치 이름 변경