Skip to content

Git flow

Jump to bottom
Mingwan Choi edited this page Oct 16, 2022 · 2 revisions

master → main

IT업계에서 master와 slave라는 단어는 기술적으로 메인과 그 외의 것을 지칭하는 용어로 사용되어 왔고 그 어원이 노예제에서 왔다는 이유로 다른 용어로 대체되기 시작하였다.

Git flow

아래의 5개 특성의 브랜치를 사용하며 협업하는 방식

  • main
  • develop (defualt)
  • feature
  • release
  • hotfix

image https://techblog.woowahan.com/2553/

1. Main Branch

제품으로 출시될 수 있는 브랜치

배포(Release) 이력을 관리하기 위해 사용. 즉, 배포 가능한 상태만을 관리한다.

image

2. Develop Branch (Default branch)

다음 출시 버전을 개발하는 브랜치

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

평소에는 이 브랜치를 기반으로 개발을 진행한다.

image

3. Feature Branch

기능을 개발하는 브랜치 (일반적으로 작업하는 브랜치)

feature 브랜치는 새로운 기능 개발 및 버그 수정이 필요할 때마다 ‘develop’ 브랜치로부터 분기한다.

개발이 완료되면 PR을 통해 merge를 준비한다.

  1. ‘develop’ 브랜치에서 새로운 기능에 대한 feature 브랜치를 분기한다.
  2. 새로운 기능에 대한 작업 수행한다.
  3. 작업이 끝나면 pull reqeust를 생성한다.
  4. merge 후 브랜치를 삭제한다
  5. 새로운 기능에 대한 ‘feature’ 브랜치를 중앙 원격 저장소에 올린다.(push)

image

// 'develop'브랜치에서 분기('main' 브랜치에서 따는 것이 아니다!)

$ git checkout -b feature/login develop

4. Release Branch

이번 출시 버전을 준비하는 브랜치

QA를 진행하는 브랜치

  1. ‘develop’ 브랜치에서 배포할 수 있는 수준의 기능이 모이면 또는 정해진 배포 일정이 되면, release 브랜치를 분기한다. release 브랜치를 만드는 순간부터 배포 사이클이 시작된다. release 브랜치에서는 배포를 위한 최종적인 버그 수정, 문서 추가 등 릴리스와 직접적으로 관련된 작업을 수행한다. 직접적으로 관련된 작업들을 제외하고는 release 브랜치에 새로운 기능을 추가로 병합(merge)하지 않는다.
  2. ‘release’ 브랜치에서 배포 가능한 상태가 되면(배포 준비가 완료되면), 배포 가능한 상태: 새로운 기능을 포함한 상태로 모든 기능이 정상적으로 동작 하는 상태 ‘master’ 브랜치에 병합한다. (이때, 병합한 커밋에 Release 버전 태그를 부여!) 배포를 준비하는 동안 release 브랜치가 변경되었을 수 있으므로 배포 완료 후 ‘develop’ 브랜치에도 병합한다.

image

5. Hotfix Branch

출시 버전에서 발생한 버그를 수정하는 브랜치

배포한 버전에 긴급하게 수정을 해야 할 필요가 있을 경우, ‘main’ 브랜치에서 분기하는 브랜치이다. ‘develop’ 브랜치에서 문제가 되는 부분을 수정하여 배포 가능한 버전을 만들기에는 시간도 많이 소요되고 안정성을 보장하기도 어려우므로 바로 배포가 가능한 ‘main’ 브랜치에서 직접 브랜치를 만들어 필요한 부분만을 수정한 후 다시 ‘main’브랜치에 병합하여 이를 배포해야 하는 것이다.

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

image

요약

  • main(master) 브랜치에서 develop 브랜치 생성

    default 브랜치

  • develop 브랜치에서 feature 브랜치 생성

  • main(master) 브랜치는 배포 가능한 상태의 브랜치

  • develop에서 작업후 release브랜치로 이동 후 QA 진행

    release 브랜치에서는 배포를 위한 최종적인 버그 수정, 문서 추가 등 릴리즈와 직접적으로 관련된 작업을 수행한다. (리젝되면 release 브랜치의 버전을 수정하며 추가로 수정 ex) release/v1.0.0(2) )

    배포가 완료되면 main(master)에 merge

    배포후 급하게 수정해야할 사항이 있다면 main 브랜치에서 hotfix 브랜치 생성

    hotfix 브랜치는 무조건 main에서만 만들어야함 !

[[GitHub] GitHub로 협업하는 방법[3] - Gitflow Workflow - Heee's Development Blog](https://gmlwjd9405.github.io/2018/05/12/how-to-collaborate-on-GitHub-3.html)

[[GitHub] Git 브랜치의 종류 및 사용법 (5가지) - Heee's Development Blog](https://gmlwjd9405.github.io/2018/05/11/types-of-git-branch.html)

++) 원격 저장소에서 로컬 저장소로 불러오는 방법

$ git clone [중앙 remote repository URL]
  • git clone 명령은 아래의 명령들을 포함한 작업이다.
// 해당 디렉터리를 빈 Git 저장소로 만드는 작업
$ git init
// 현재 작업 중인 Git 저장소에 팀의 중앙 원격 저장소를 추가한다. 이름을 origin으로 짓고 긴 서버 주소(URL) 대신 사용한다.
$ git remote add origin [중앙 remote repository URL]
// 중앙 원격 저장소(origin)의 master 브랜치 데이터를 로컬에 가져오기만 하는 작업
$ git fetch origin master

  • fetch와 pull의 차이

    fetch: 원격 저장소의 데이터를 로컬에 가져오기만 하기 pull: 원격 저장소의 내용을 가져와 자동으로 병합 작업을 실행 즉, 단순히 원격 저장소의 내용을 확인만 하고 로컬 데이터와 병합은 하고 싶지 않은 경우에는 fetch 명령어를 사용한다. pull = fetch + merge

Maddori.Apple

Clone this wiki locally