잘못된 형식의 이미지 링크입니다.

아래 내용은 제가 개발하면서 느낀 주관이 포함되어 있으니 절대적으로 신뢰하기 보단 이런식으로 사용하기도 하는구나 라고 보고 넘어가 주시면 됩니다.

혹시나 제가 잘못 알고 있던부분이 있더라면 과감하게 지적해 주심면 감사합니다.

1. Git Flow 란 무엇인가?

- Git Flow 는 Git Branch 전략 중에 하나

  (Github Flow, GitLab Flow 등.. 그 외 자신만의 기준으로 Git Branch 를 사용한다면 그것이 당신의 Branch 전략이 됩니다)

2. Git Flow 가 어떻게 사용하는데?

  - 사용하는 방법을 설명하기에 앞서, 기본적인 전제조건이 몇개 있습니다.

    1. Commit 을 최대한 자주 한다

        비록 로그가 길어지겠지만, 나중에 특정 상황에 도달했을 때 "왜 나눠서 Commit 하지 않았지?" 라고 후회할 수 있습니다

        (예를들면 기능 5개를 한번에 Commit 했는데, 그중 1,2개만 반영하고 나머지는 폐기해야 할 경우)

        러프하게 하더라도 최대 1개 기능에 1개 Commit 이 되어야 합니다. (2개 이상의 기능수정을 1개의 Commit 에 걸쳐서 하지 마세요)

    2. Push 는 항상 동작되는 코드여야 한다.

        코드가 Push 된 순간부터 다른 누군가가 Pull 할 수 있기 때문에, 동작되지 않는 코드가 Pull 되는 순간 동료들의 모든 코드가 당신의 코드 수정만들 기다리며 Stop 됩니다

  - Branch 설명

    - Master : 배포용 Code, 상용 배포 버전입니다.

    - Develop : 개발용 Code, Master 에 Merge 되기 전에 기능들을 합산하여 최종적으로 테스트 하는 버전입니다

    - Feature : 기능 개발용 Code, Develop 에서 분기된 Branch 로 기능 하나당 하나의 브랜치로 구성된다

    - Hotfix :긴급 수정용 Code, Master 에서 분기된 Branch 로 급한 코드 수정이 필요할때 사용됩니다.

    - Release : 버그 수정용 Code, Develop 에서 분기된 Branch 로 오로지 배포 전 버그 수정용으로 사용됩니다.

  - 예시를 통한 사용법 상세 설명

    - 만약 당신이 모든 코드 수정을 Master 에서만 하고있다면 먼저 코드 안정화부터 진행합니다.

    - 코드 안정화가 끝났다면 Develop Branch 를 새로 만듭니다

    - 당신이 작업해야할 기능을 나눕니다

      (로그인 화면을 수정하고, 유저정보 화면을 추가하고, 광고들을 삭제해야 한다)

    - Develop Branch 에서 분기된 3개의 Feature Branch 를 만든다

      (feature/login-fix, feature/user-info. feature/delete-ad)

    - 각 Feature Branch 에서는 작업할 기능만 온전히 작성한다.

      그리고 각 Branch 간 코드들은 Build 에 이상이 없는 상태

      (그 결과 feature/login-fix 에서는 유저화면이 없고, 광고가 남아있다)

    - 이 중 반영되어야 할 기능들이 선별된다 (고객요구사항 등)

    - Develop 으로 선별된 기능들이 Merge 된다

    - Merge 완료 후 Develop Code 테스트

    - 이때 버그 발생시 Release Branch 로 버그 수정

      (Release 는 Develop 으로 병합)

    - 내용 수정

      develop 이 일단 정상적으로 빌드되어서 돌아가면 develop 에서 release 브랜치를 만듭니다.

    - release 에서 계속 테스트를 진행하면서 고객사에 넘길 준비를 합니다. 그러다가 테스트하던 release 브랜치에서 버그 발생시 Release Branch 에서 버그 수정후 곧바로 release 와 develop 두 브랜치 모두에 커밋합니다. 이걸 계속 반복해줍니다.

    - 이제 release 브랜치 에서 모든 테스트가 끝난후라면, 비로소 Release 브랜치를 닫고 develop과 master 로 이 결과를 merge 해줍니다.

    - 그리고 난뒤 master 에는 버전 번호 태그를 달고 이걸 고객에게 배포하는거죠.

    - 시간이 지나서 고객사에서 버그리포트가 오면 이걸 master 에서 hotfix 브랜치를 만들어 고친후 다시 master와 develop 브랜치로 merge 하고, master에는 새로운 버전 번호 태그를 붙입니다.

    - 이렇게 새로운 버전 번호 태그를 단 커밋이 다시 고객사에 전해집니다.

   

    - 모든 버그 수정되고 배포 확정되면 Develop 을 Master 로 Merge

    - Master Merge 이후 버그 발생했다면 Hotfix Branch 로 버그 수정

    - 기존 Feature Branch 는 필요하다면 Master 혹은 Develop 의 Code 를 Merge 한다

      (Merge 를 하든 안하든 문제가 없어야 한다)

    - 각 Branch 간 코드 교환이 필요하다면 Cherry pick 으로 필요한 코드만 가져온다

퇴근시간이라 그만 쓰겠습니다!