알아두면 좋은 브랜치전략.md

remote 저장소의 branch

• master or main
• develop
• release
• feature/(merge 후에 삭제)

local 저장소의 branch

• develop
• feature/xxx
• HOTFIX

remote - master

• 초기 보일러 플레이트가 존재하는 브랜치

remote - develop

• 각자 local의 develop branch들에서 PR을 날리고 merge를 하는 브랜치

remote - release

• cloud에 배포하는 브랜치이다.

local - develop

• remote의 develop branch가 merge되어 갱싱된 경우 pull을 이용해 최신 상태로 업데이트 한다.

local - feature

• 각자 개발중인 기능을 나타내는 branch이다.
• 모든 feature branch는 최신 상태의 develop branch에서 뻗어나와야 한다.
• branch 이름은 feature/기능명으로 할 수 있도록 한다.

알아두면 Git Flow 전략

• 프로젝트 시작

  • 프로젝트 초기 구성이 완료된 remote-master branch에서 remote-develop branch를 생성한다.

• 일일 작업 개발

  • remote 원본 작업 레포지토리를 나의 Github 레포지토리로 Fork를 한다.
  
  

  

  • 위에는 초기 작업 레포를 나의 Github 저장소로 Fork를 한 상태이다. 그리고 Fork한 저장소를 나의 local 저장소로 clone을 받자.
  
  

  

  
  

  

  • 위와 같이 clone을 받으면 자동으로 origin이 생기게 된다.
  • remote는 로컬 저장소와 Github 저장소를 연결해주는 통로라고 생각하면 된다. 따라서 현재 Fork한 레포지토리와 로컬 저장소가 연결된 상태이다.

  • 이번에는 원본 레포지토리와 로컬 저장소를 연결해보자.

    
    • 원본 레포지토리의 주소를 복사하자.
    • 그러면 위와 같이 이름을 upstream 이라고 지정했기 때문에 원본 레포지토리와 로컬 저장소가 upstream으로 연결된 것을 볼 수 있다.

• PR Merge

  • 각 팀원은 conflict가 발생하지 않도록 코드 리뷰를 진행한다.
  • 충돌이 났을 경우, 충돌이 난 인원끼리 모여 충돌 부분을 해결한다.
  • 공통적으로 사용하고 수정하는 파일은 자주 PR을 날려서 merge를 한다.

branch 구성도

정리하기

1. 원본 레포지토리에 master 브랜치에 보일러 플레이트를 적용한 후에, develop 브랜치를 만든다.

2. 원본 레포지토리를 나의 Github 레포지토리로 Fork를 한다.

3. Fork한 레포지토리를 나의 로컬 저장소로 clone을 한다.

4. 로컬 저장소에서 feature/기능이름 브랜치로 만들어서 작업을 한 후에 로컬 저장소의 develop 브랜치와 합친 후에 나의 Github 원격 레포지토리로 push를 한다.

5. 나의 Github 원격 레포지토리에 push가 문제없이 되었다면 원본 레포지토리에 Pull Request를 날린다.

6. 그리고 코드리뷰가 필요하다면 코드 리뷰를 진행하고 문제가 없다면 merge를 한다.