Git 레포관리

Table of Content

• 처음에 시도했던 브랜치 전략
• 두 번째로 시도한 브랜치 전략
• 새롭게 정한 브랜치 전략(최종)

---

Branch 관리

1. 처음에 시도했던 브랜치 전략

현재 코넥트 프로젝트에서는 Git Flow라는 브랜치 전략을 비슷하게 따라했다.

1-1. Git Flow란?

기본적으로 5가지 브랜치로 이뤄진다.

이슈단위로 feature브랜치를 생성하며, 주된 개발 프로세스는 develop브랜치에서 이뤄진다.

Master: 릴리즈 시 사용하는 최종 단계 메인 브랜치로, Tag를 통해 버전 관리를 한다.

Develop: 다음 릴리즈 버전 개발을 진행하는 브랜치로 추가 기능 구현이 필요해지면, 해당 브랜치에서 다시 브랜치(Feature)를 내어 개발을 진행하고, 완료된 기능은 다시 Develop 브랜치로 Merge한다.

Feature: Develop 브랜치에서 기능 구현을 할 때 만드는 브랜치로 한 기능 단위마다 Feature 브랜치를 생성하는게 원칙이다.

Release: Develop에서 파생된 브랜치로, Master 브랜치로 현재 코드가 Merge 될 수 있는지 테스트하고, 이 과정에서 발생한 버그를 고치는 공간이다. 확인 결과 이상이 없다면, 해당 브랜치는 Master와 Merge한다.

Hotfix: Mater브랜치의 버그를 수정하는 브랜치로 검수를 해도 릴리즈된 Master 브랜치에서 버그가 발견되는 경우가 존재한다. 이때 Hotfix 브랜치를 내어 버그 수정을 진행한다. 디버그가 완료되면 Master, Develop 브랜치에 Merge해주고 브랜치를 닫는다.

2. 두 번재로 시도한 브랜치 전략

2-1. 브랜치 관리

main브랜치와 develop브랜치를 나눈 뒤, develop브랜치에서 파트(FE|BE)별 브랜치를 만들어서 관리했다.

주된 작업은 파트별 develop브랜치에서 진행했으며, 개발자는 파트별 브랜치에서 feature브랜치를 만들어서 작업했다. 작업이 완료된 이후 pr을 통해 파트별 develop브랜치로 merge했다.

이후 각 파트별 작업이 완료되면 develop브랜치를 최신화했다.

.
└── Co-nect
      develop
          ├── develop-FE
          │    ├── FE/feature/#12-login_page
          │    └── FE/feature
          └── develop-BE 
                ├── BE/feature
                └── BE/feature

# 브랜치 네이밍: 
# [BE|FE]/<feature>/<#이슈번호>-<세부내용>
# 예시: FE/feature/#12-login_page

2-2. 레포지토리 관리

fork를 활용해서 공통 레포지토리를 upstream으로 사용하고 개인 레포지토리를 Origin으로 사용했다. 개발자 개인별 작업은 개인 레포지토리에서 자유롭게 진행하고 확실한 코드만 upstream에 반영했다.

2-3. 장점

1. remote와 origin을 따로 공통으로 관리하는 코드를 안전하게 관리할 수 있다.

개인 로컬 → 개인 원격 저장소 → 공통 원격 저장소 이런식으로 관리하기 때문에 혹시 모를 실수를 방지할 수 있다.

2-4. 문제

1. 브랜치 계층이 많아 최신화하기 번거롭다.

파트별 브랜치(front, back)은 개발과정에서 자주 최신화되지만 develop브랜치를 자주 최신하지 못해 문제가 발생했다.

develop브랜치에 합쳐야할 적절한 시기를 자주 놓쳐 불필요한 conflict문제가 자주 발생했다.

2. 프로젝트 규모에 비해 복잡하다.

아직 배포도 제대로 안되었고, 버전1도 출시하지 않는 상황에서 과도한 전략인 것 같다.

3. 새로 정한 브랜치 전략 및 레포지로리 관리

gitflow전략으로 그대로 따라하자.

front, back이라는 파트별 브랜치를 없애고 develop브랜치에서 바로 feature브랜치를 생성한다.

fork를 하지 말고 공통 레포지로리를 origin으로 사용

.
└── main (origin)
      ├─ deploy # 배포 브랜치
      └─ develop
            ├── FE/#12-login_page
            ├── FE/
            ├── BE/#11-something
            └── BE/

# 브랜치 네이밍: 
# [BE|FE]/<feature>/<#이슈번호>-<세부내용>
# 예시: FE/feature/#12-login_page

3-1. feature단위

기능 단위로 feature브랜치를 생성한다.

우리 프로젝트에서는 기능 단위로 이슈를 생성하기 때문에 이슈별로 브랜치를 생성한다.

3-2. develop 기능 반영하기

feature작업이 끝나면 pr을 통해 develop에 반영한다.

develop브랜치가 업데이트되면 나머지 팀원들은 작업하던 브랜치 및 개인 로컬에 develop브랜치를 최신화한다.

⚠️ 주의사항

절대 임의로 develop브랜치에 commit하지 않는다. 혹시나 하게 된다면 확실한 방법으로 팀원모두에게 알려야한다.

3-3. deploy브랜치

배포 브랜치입니다.

참고자료

https://gyoogle.dev/blog/github/Git vs GitHub vs GitLab Flow.html

https://medium.com/daangn/deploy-브랜치-전략-활용-방법-545f278ca878