Git Flow 전략에 맞는 개발방법

여기서 다루는 내용은 절대적인 법칙이 아니다. 많은 개발자들이 git flow 전략과 branch 등 사용하긴 하지만 구체적인 방법은 모두 다르다. (그래서 convention이라는 표현이 사용되는 것 같기도 하다. 팀마다 설정하기 나름이니..) 다만, 우리 팀의 Rule이니 꼭 꼭 지켜주길 바란다. 아무튼 우리 팀에서 사용하는 convention이라고 생각하면 된다. 작업을 하다가 불편한 점, 뭔가 더 추가되었으면 하는 점이 생긴다면 회의 안건으로 올려도 좋다.

Flow란?

직역하여 흐름이라는 의미

Git + Flow는 git에서 제공하는 branch 기능을 활용한 변경 이력 관리 전략이다.

Git Flow란?

브랜치를 나누는 방법에 대한 분류 종 하나이다.

Git Flow의 특징은 브랜치를 5종류로 나눈다.

• main
  • 서비스를 직접 배포하는 역할을 하는 브랜치이다.
  • 과거 master라고 명명했었지만.. 모종의 사유로 바뀌었다.
• feature
  • 각 기능 별 개발 브랜치이다.
• develop
  • feature에서 개발된 내용이 저장되는 브랜치이다.
• release
  • 배포를 하기 전 내용을 QA(품질 검사)하기 위한 브랜치이다.
• hot fix
  • main 브랜치로 배포를 하고 나서 버그가 생겼을 대 빨리 고치기 위한 브랜치이다.

main과 develop은 필수 프랜치이다. 하지만 나머지 브랜치는 유지보수를 목적으로 하는 선택적인 브랜치이다.

프로젝트의 스타일에 따라서 커스텀 하면 된다.

우리 팀은, main과 develop, feature 브렌치를 주로 사용할 예정이다.

Github 세팅

• 레포지토리의 Settings에서 branch rule을 설정한다.
  • Require a pull request before merging
    • Require approvals
    • Require review from Code Owners
  • 위 세 개 정도 체크한다. (세팅은 프장님 세팅을 참고했다.)

---

⛔ 작업을 시작하기 전에 git pull 한번 하고 시작하자.

개발 방법

1. Issue 등록하기

• 먼저 작업을 진행할 이슈를 등록해야한다. (보통 파트장이 해줄 것)

• issue 탭으로 이동한 뒤, New issue 버튼을 누른다.

• 이슈의 제목과 내용을 작성한다.
• 우측 설정에서 다음을 설정한다. (선택)
  • Assignees : 작업을 할당할 사람을 골라준다.
  • Labels : 이슈의 유형에 맞는 라벨을 골라준다.
  • Projects : 이슈가 할당되는 프로젝트를 골라준다.
    • 우리는 서비스의 규모가 작기 때문에, 서비스가 그냥 프로젝트가 된다.
    • 단, 서비스의 규모가 큰 경우에는 프로젝트가 분리될 수 있다.
  • Milestone : 이슈가 해당되는 Milestone을 골라준다.
    • 프장은 안쓰는 것 같기도 하다. (그럼 공란으로 둠)

2. Issue 할당하기

• ISSUE를 수락하고 싶은 사람은 comment를 남겨 알린다.

• 위 사진에는, 혼자 진행하다보니 커멘트가 없다.
• 근데 따로 커멘트를 남기지 않아도, 회의에서 파트장들이 Assignees를 결정하고 미리 할당할 가능성이 크다.

3. feature-{이슈번호} 브랜치를 만들고 작업하기

git flow 전략에서 볼 수 있었듯, 각각의 기능을 개발하는 브랜치의 이름은 feature이다. 여기에 이슈 번호를 매겨서 브랜치를 만든다.

이제 이슈 할당을 받았으니 브랜치를 만들고 작업하면 된다.

위 이슈를 기준으로 보면, 이슈 제목 “README Enhancement” 옆에 #5라고 되어있는 것을 볼 수 있다. 이게 이슈 번호이다.

브랜치 만들기

git branch -c feature-#5

브랜치 전환하기

git switch feature-#5

개발하기

이 때부터 개발을 해주면 된다.

단, 할당된 이슈에 걸맞는 개발을 해야한다.

막무가내로 냅다 다 쳐박지 마라.

Add 및 Commit 하기

git add .

혹은, 특정 파일만 하고싶다면 . 대신에 파일이름을 적기

commit 할 때 template 사용하는거 잊지말자.

git commit

이걸 실행하면 템플릿이 나온다.

템플릿은 #을 기반으로 작성되어 있는데, 이는 주석을 의미한다. (즉, 실제 커밋 시에는 적용되지 않는 부분이다.)

vi 에디터 기반이므로 i 를 눌러서 수정모드로 들어간다.

빈 줄에 내용을 작성하면 된다.

• Commit Message Convention : 커밋 메시지를 작성하는 방법 (Rule)
  • 제목 작성하는 방법
    • 제목은 50자 이내로, 가능한 간결하게 작성한다.
    • 제목의 시작은 대문자로 작성한다.
    • 제목에 마침표를 사용하지 않는다.
    • 제목은 동사로 시작한다. (명령형으로 작성한다.)
    • 자주 쓰는 단어 및 형식 정리
      • Fix
        • 잘못된 기능을 고칠 때 사용한다.

        Fix my test
        Fix typo in style.css
        Fix my test to return undefined
        Fix error when using my function
        

        • 단순히 명사만 추가하여 수정했음을 명시할 수 있다.
        • in을 추가하여 어디를 수정했는지 명시할 수 있다.
        • to나 for를 추가하여 왜 그렇게 수정했는지 명시할 수 있다.
        • when을 추가하여 어느 상황에서 발생했는지를 명시할 수 있다.
      • Add
        • 무언가 추가할 때 사용한다.

        Add style.css
        Add mytest.test for test
        Add blue color to style.css
        

        • 단순히 코드나 문서가 추가되었음을 명시할 수 있다.
        • 왜 추가했는지, 무엇을 어디에 추가했는지 등을 나타낼 수 있다.
      • Remove
        • 삭제가 발생할 때 사용한다.

        Remove test.js
        Remove black color from style.css
        

        • from을 적어서 어디에 삭제했는지 명시할 수 있다.
      • Simplify
        • 코드를 단순화 했을 때 사용한다.
      • Update
        • Fix와는 다르게, 원래는 정상 작동했지만 보완작업을 했을 때 사용하는 개념이다.

        Update harry-server.js to use HTTPS
        

      • Implement
        • 무언가 구현을 달성했을 때 사용한다.
        • 큰 단위에 작성하면 좋다.
      • Prevent
        • 특정한 동작을 못하게 막을 때 사용한다.

        Prevent hello handler from saying Hi in hi.js
        

      • Move
        • 코드나 파일의 이동에 사용한다.

        Move A to B
        Move A into B
        

      • Rename
        • 이름의 변경이 있을 때 사용한다.

        Rename A to B
        

  • 본문 작성하는 방법
    • 본문은 72자를 단위로 줄바꿈을 시행한다.
    • 본문을 통해 무엇을, 왜 등을 설명한다.
    • 생략해도 된다. 하지만 작성해주면 읽는 이가 감사해할 것이다.
  • 푸터 작성하는 방법
    • 안써도 될듯?

Push 하기

git push origin 브랜치명

지금 상황에서는 git push origin feature-#5 가 되겠다.

4. Github에서 Push한 브랜치를 Pull Request 하기

• push 를 한 뒤에, 레포지토리로 돌아가면 이렇게 compare&Pull Request가 날라온다.
• *Pull Request를 줄임말로 PR이라고 부르기도 한다. 알아두길.. (별다줄..)

• 버튼을 눌러보면 아래와 같은 입력 창이 뜨는데, 커밋에서 작성한 내용과 동일할 것이다. 내용을 추가하고 싶다면 추가해도 좋다.

• 작성한 뒤에 create pull request를 눌러주면 된다.
  • ⛔ 주의할 점
    • 위 사진의 예시에서는 반영하지 못했지만, base:main 부분을 base:develop으로 바꿔주어야한다.
    • feature브랜치에서 작업한 결과물은 develop으로 합병한다.

• 그럼 Pull requests 부분에 1이라고 나온다.

• 들어가보면 아래와 같은 창이 나온다.

• 어떤 메시지를 작성했는지도 볼 수 있고, 커밋 내용, 파일 변경 이력도 볼 수 있다.
• 문제가 없다면 merge를 할 수 있다.

• 그 뒤 Delete Branch 버튼을 통해서 브랜치도 삭제할 수 있다.

• 그 뒤에 이슈를 닫아준다.

---

참고자료

• 기본적인 사용법

Github flow 사용법 & 시나리오

• git branch rule settings

[Github] 브랜치 보호 규칙 설정 - PR 리뷰 및 테스트 강제

• git flow 개념 이해

Git Flow란, 깃 브랜치 전략

Git 브랜치 활용 - GitFlow

• commit message 작성 및 template 부분 참고

Git | git 커밋 컨벤션 설정하기

<Git> 커밋 메시지 컨벤션 : 중요성 및 규칙 (feat. 템플릿)