Github-Flow 전략으로 프로젝트 관리하기

Git-Flow 전략에 대해 먼저 알고난 후, Github-Flow 전략을 알게되었습니다. 무엇을 먼저 알게 되는 상관은 없는데 만약 대학생 시절로 돌아간다면 Github-Flow 전략 정도는 이해하고 사용하면 좋지 않았을까 싶습니다. 이걸 이제와 제대로 쓰는 것도 많이 부끄럽고 창피하네요. 

 

 

Github-Flow

 

Github Flow 예시

 

 

앞서 배운 Git-Flow는 아무래도 조금 복잡한 느낌이 없지 않아 있었습니다. 알고보면 단순하지만 저의 경우 초면엔 조금 당황스럽고 오래 집중해서 읽어본 뒤 이해할 수 있었어요. Github-Flow는 보다 더 단순한, GitHub에 적용하기 더 쉽게 고안해낸 새로운 관리 방식입니다.

 

기본 master 브랜치만 정확하게 정립되어 있다면 나머지 가지들은 특별히 관여하지 않고 자유롭게 PR 기능을 사용하는 것이 바로 Github-Flow의 정의입니다. 그냥 간단하게 말해 main 브랜치만 고정해두고 기능 개발은 (dev 뭐 이런 거 없이) 개발용 브랜치를 생성하여 만드는 것이죠.

 

전체적인 흐름은 아래와 같습니다.

 

1. 브랜치 생성

• master 브랜치에 어떤 이유든 새로운 브랜치를 생성한다.
• Git-Flow와 같이 체계적인 브랜치 분류가 없기 때문에 브랜치 이름을 명확하게 지어야 한다.
• feature나 develop 브랜치가 존재하지 않는다.
• 단, 새로운 기능 추가나 버그 해결을 위한 브랜치 이름은 자세하게 작성한다.

 

2. 개발 & 커밋 & 푸쉬

• 개발을 진행하면서 커밋한다.
• 커밋 메세지를 통해 작업을 구분해야 하므로 최대한 상세하게 적는다.
• 원격 브랜치에 수시로 push 한다.
• 항상 원격지에 자신이 하고있는 일을 올려 다른 사람들도 확인케 한다.

 

3. PR 생성

• 피드백이 필요하거나 합병 준비가 완료되면 PR을 생성한다.
• 자신의 코드를 공유하고, 리뷰 받는다.
• 합병 준비가 완료 되었다면 master 브랜치로 반영을 요구한다.

 

4. master 반영하기 전 리뷰&토의

5. 라이브 서버 or 테스트 환경에 배포 (문제 발생시 곧장 master 내용을 다시 초기화)

6. 최종 합병

 

master로 merge 되고 push 되었을 때는 즉시 배포되어야 합니다.

 

 

 

 

---

제 생각엔 솔로 프로젝트 같이 짧고 지속적으로 테스트&배포하는 작업은 github-flow로 하고,

한 달 이사의 긴 프로젝트는 git-flow로 전략을 짜면 좋을 것 같습니다.

 

평소 솔로 프로젝트를 하면서 단 한 번도 브랜치를 생성해서 관리한 적이 없는데 이제부터 똑바로 습관화 시키면 좋을 것 같습니다.