[Git] Git flow? Github flow?

 

 

Git flow Workflow Branch

Gitflow Workflow에서는 항상 유지되는 메인 브랜치들(master,develop)과
일정 기간 동안만 유지되는 보조 브랜치들(feature,release,hotfix)을 포함하여 총 5가지의 브랜치를 사용한다.
주로 대형 팀, 긴 호흡의 프로젝트에서 사용하는 비교적 엄격한 브랜치 전략이다.
브랜치 관리가 용이하고 배포, 협업, 버전관리와 롤백, 유지보수에 장점이 있다.
하지만 그만큼 추가 검증이나 테스트과정이 포함되기 때문에 릴리즈속도가 느리고,
작은 프로젝트에서 불필요하게 많은 브랜치과정이 적합하지 않을 수 있다.

 

그래서 더 작은 프로젝트를 위해 전략을 간소화 시킨 것이 `Github flow` !
기본적으로 브랜치에 대한 설명은 동일하므로 각 브랜치에 대해 이해하고, 아래에 Github flow 확인하기.

 

1. Master Branch

   제품으로 출시될 수 있는 브랜치로, 배포(Release) 이력을 관리하기 위해 사용한다.(배포 가능한 상태)

 

 

2. Develop Branch

   기능 개발을 위한 브랜치들을 병합하기 위해 사용한다.
   모든 기능이 추가되고 버그가 수정되어 배포 가능한 안정적인 상태라면 develop 브랜치를 'master' 브랜치에 병합(merge)한다.

 

 

3. Feature branch

   새로운 기능 개발 및 버그 수정이 필요할 때마다 'develop'브랜치로부터 분기한다.
   (기본적으로, 공유하지않고 로컬저장소에서 관리)

  ① `develop` 브랜치에서 새로운 기능에 대한 `feature` 브랜치를 분기함 

      `$ git branch feature/기능` 또는 `$ git flow feature start 브랜치이름`

  ② 새로운 기능에 대한 작업을 수행
  ③ 작업이 끝나면 develop 브랜치로 병합(merge)

`$ git checkout develop`
`$ git merge --no-ff feature/login`

  ④ 더 이상 필요하지 않은 feature 브랜치는 삭제

`$ git branch -d feature/login`

  ⑤ 새로운 기능에 대한 feature 브랜치를 중앙 원격 저장소에 올림(push)

`$ git push origin develop`

 

또는 `$ git flow feature publish 이름`를 통해 feature브랜치를 원격저장소에 바로 공유해준다.
그리고 작업이 완료되면 `$ git flow feature finish 브랜치이름`를 사용해서 branch를 병합후 삭제해준다.

 

4. Release Branch

   이번 출시 버전을 준비하는 브랜치
   배포를 위한 전용 브랜치를 사용함으로써 한 팀이 해당 배포를 준비하는 동안 다른팀은 다음 배포를 위한 기능 개발을 계속할 수 있습니다.
   즉, 딱딱 끊어지는 개발 단계를 정의하기에 좋다.

  ①‘develop’ 브랜치에서 배포할 수 있는 수준의 기능이 모이면 또는 정해진 배포 일정이 되면, release 브랜치를 분기한다.

 release-RB\__ 또는 release-_ 또는 release/_ 처럼 이름 짓는 것이 일반적인 관례
[release-_ ] 형식을 추천 EX) release-1.2
또한 feature브랜치와 동일하게 `develop` 브랜치에서 분기한다.

      release 브랜치를 만드는 순간부터 배포 사이클이 시작된다.
      release 브랜치에서는 배포를 위한 최종적인 버그 수정, 문서 추가 등 릴리스와 직접적으로 관련된 작업을 수행한다.
      직접적으로 관련된 작업들을 제외하고는 release 브랜치에 새로운 기능을 추가로 병합(merge)하지 않는다.

  ② ‘release’ 브랜치에서 배포 가능한 상태가 되면(배포 준비가 완료되면),
      배포 가능한 상태: 새로운 기능을 포함한 상태로 모든 기능이 정상적으로 동작 하는 상태
      ‘master’ 브랜치에 병합한다. (이때, 병합한 커밋에 Release 버전 태그를 부여!)

$ git checkout master        // 'master' 브랜치로 이동한다.
$ git merge --no-ff release-1.2      // 'master' 브랜치에 release-1.2 브랜치 내용을 병합(merge)한다
$ git tag -a 1.2     // 병합한 커밋에 Release 버전 태그를 부여한다.

 
      배포를 준비하는 동안 release 브랜치가 변경되었을 수 있으므로 배포 완료 후 ‘develop’ 브랜치에도 병합한다.

$ git checkout develop      // 'develop' 브랜치로 이동한다.
$ git merge --no-ff release-1.2        // 'develop' 브랜치에 release-1.2 브랜치 내용을 병합(merge)한다.
$ git branch -d release-1.2          // -d 옵션: release-1.2에 해당하는 브랜치를 삭제한다.

 

   ③ 이때, 다음 번 배포(Release)를 위한 개발 작업은 ‘develop’ 브랜치에서 계속 진행해 나간다.

5. Hotfix Branch

출시 버전에서 발생한 버그를 수정하는 브랜치
배포한 버전에 긴급하게 수정을 해야할 필요가 있을경우, `master`브랜치에서 분기한다.

      ① 배포한 버전에 긴급하게 수정을 해야 할 필요가 있을 경우,
         ‘master’ 브랜치에서 hotfix 브랜치를 분기한다. (‘hotfix’ 브랜치만 master에서 바로 딸 수 있다.)
      ② 문제가 되는 부분만을 빠르게 수정한다.
         다시 ‘master’ 브랜치에 병합(merge)하여 이를 안정적으로 다시 배포한다.
         새로운 버전 이름으로 태그를 매긴다.
      ③ hotfix 브랜치에서의 변경 사항은 ‘develop’ 브랜치에도 병합(merge)한다.

 

 

 

Github flow

Git flow와 달리 일반적으로 master와 develop 두 개의 브랜치만 사용한다.

Github flow는 Git flow에 비해 release branch가 명확히 구별되지 않기 때문에
수시로 release되어야하거나 단일 release 버전만 존재할 경우 github flow가 더 적합하다고 할 수 있다.
깃허브 기반의 간단하고 유연한 개발워크플로우로 주요 목표는 신속한 배포와 효율적인 협업을 지원하는 것이다.

Github Flow는 Git Flow와 달리 `단일 브랜치`를 사용하여 개발하는데, 이는 하나의 버전이 만들어지면 바로 배포될 수 있다는 의미이다.
간단하고 직관적인 구조를 가지므로 작은 단위로 개발한 기능이나 수정사항을 빠르게 테스트하고 배포할 수 있다.
또한 여러 개발자가 동시에 develop 브랜치에서 작업하고, 
독립적인 브랜치에서 작업이 진행되기 때문에 충돌이 발생할 가능성이 줄어든다.
하지만 그만큼 적은 검증절차와 세밀한 버전관리에 어려움이 있기 때문에 대규모 프로젝트에 적합하지 않고 항상 잠재적인 위험성을 가지고 있다.

 

① Branch 생성

새로운 기능이나 버그 수정 작업을 수행하기 위해 브랜치를 생성한다.
이 브랜치는 작업의 컨텍스트를 제공하고, 기능의 독립성을 보장한다.
: 일반적으로 master와 develop 두 개의 브랜치만 사용하는 간단한 구조를 가지므로 전략에 대한 이해와 사용이 쉽고,
프로젝트를 빠르게 시작할 수 있다.

② Commit 작성

브랜치에서 변경 사항을 커밋으로 저장한다.
커밋은 작업의 단위이며, 코드 변경 내용을 기록한다.

③ Pull Request

변경 사항을 본래 브랜치로 병합하기 위해 풀 리퀘스트를 생성한다.
이를 통해 코드 검토, 토론, 테스트 등을 수행할 수 있다.

④ 리뷰 및 피드백

풀 리퀘스트를 생성한 후 다른 개발자들이 코드를 검토하고 피드백을 제공한다.
이를 통해 코드 품질을 높이고 버그를 발견하고 수정할 수 있다.

⑤ 병합

풀 리퀘스트가 승인되면 변경 사항을 본래 브랜치로 병합한다.
이를 통해 작업한 내용이 제품의 다른 부분과 통합된다.

⑥ 배포

병합된 변경 사항은 배포를 위한 브랜치로 이동하고, 자동 또는 수동으로 배포 프로세스를 시작한다.
배포 단계에서 테스트, 빌드, 배포 작업 등이 수행된다.

 

 

참고 
https://velog.io/@gmlstjq123/Git-Flow-VS-Github-Flow