ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • GIt-flow, GitLab-flow, Github-flow란?
    git 2021. 9. 24. 09:17

    Git-Flow


    2010년에 Vincent Driessen 이라는 사람의 블로그 글에 의해 널리 퍼지기 시작했고 현재는 Git으로 개발할 때 거의 표준과 같이 사용되는 방법론

    A successful Git branching model

    [A successful Git branching model

    In this post I present a Git branching strategy for developing and releasing software as I’ve used it in many of my projects, and which has turned out to be very successful.

    nvie.com](https://nvie.com/posts/a-successful-git-branching-model/)

    GIt-flow

    기본 브랜츠는 5 가지가 있다. featuredevelopreleasehotfixmaster

    머지 순서는 왼쪽에서 오른쪽으로 진행된다.

    구조

    develop 브랜치와 master 브랜치가 가장 중심이된다. 머지된 feature, release, hofix 브랜치는 삭제한다.

    • feature
      • branch from: develop
      • merge to: develop
    • 새로운 기능을 추가하는 브랜치이며, origin 에는 반영하지 않고 local repository에만 존재한다.
    • releaserelease 브랜치에서 커밋 시에는 오직 bug fix에 대한 부분만 한다.master에 머지 후 tag를 통해 배포 버전을 명시하고 그 후 develop 브런치로 머지해서 release의 수정된 내용(오직 bugfix)을 반영한다
      • branch from: develop
      • merge to: develop, master
    • 배포할 준비가 다 되었다면 master 브랜치에 머지한다
    • 새로운 프러덕션을 배포하기 위한 브랜치이다. 지금까지 만든 기능들을 develop 브랜치에서 가져오고 develop 브랜치는 다음 배포 시 필요한 기능들을 만든다.
    • hotfix
      • branch from: master
      • merge to: develop, master or release
    • 실서버에서 나오는 버그들을 수정하는 브랜치이다. 수정이 완료되면 develop, master 에 머지하여 반영하고 mastertag를 추가한다. 만약 release 브랜치가 있다면 master 말고 release 머지하여 다음 배포 때 반영되도록 한다.

    확장 모듈

    git-flow 방법론을 그대로 사용하기 쉽도록 오픈소스에 제공되어 있다.
    https://www.notion.so/hellowoot/59740f849f404f56bd2468d12d89d486#357b9aa66be44b0492d25df708d484f1

    GitHub-Flow


     

    2011년에 Scott-Chacon이 기존의 Git Flow는 훌륭하고 좋은 워크플로우이지만, 어렵기 때문에 보다 쉽게 적용할 수 있도록 단순화 하여 만들어진 워크플로우 방식이다.

     

    GitHub에서는 GIt-flow 방식을 사용하지 않는다.

     

    그 이유는 항상 배포하기 때문인데, Git-Flow에서는 release 브랜치 중심으로 설계되어있어 매일 배포하는 개발팀에게는 필요가 없다.

     

    GitHub 자체의 서비스 특성상 배포의 개념이 없는 시스템으로 되어있기 때문에 이 flow가 유용하다.

     

    CI를 필수 조건으로 도입하여 항상 master 브랜치는 지속적으로 배포가 가능하도록 유지한다. Develop 브랜치가 따로 있지 않다.

    방법

    1. 마스터 브랜치는 배포 가능한 브랜치이다.
    2. 새로운 작업을 하기 위해 해당 작업을 master로부터 브랜치를 생성한다. (i.e new-oauth2)
    3. 로컬 브랜치에서 커밋 후 정기적으로 origin 에 push한다.
    4. 코드 리뷰를 받거나 머지할 준비가 되면 p-r을 연다.
    5. 리뷰를 받고 master 로 푸쉬되면, 즉시 배포한다.

    GitLab-Flow


    GItLab-flow

    단순해진 GitHub-Flow를 보완하기 위해 제안된 워크플로우이다.

     

    GitLab에는 production 브랜치가 존재한다. 이 브랜치는 master와 같은 역할이다.

     

    GitLab-Flow의 master 브랜치는 production 브랜치에 머지된다. 이렇게 되면 production 브랜치가 항상 최신일 필요가 없어진다.

    ( 깃과 깃허브의 중간 느낌)

    'git' 카테고리의 다른 글

    Git best practice  (0) 2021.09.08
    Git: pull strategy(전략, 종류)  (0) 2021.05.23

    댓글

Designed by Tistory.