Skip to content

Instantly share code, notes, and snippets.

@ljlm0402
Last active March 12, 2024 10:29
Show Gist options
  • Save ljlm0402/5f69a1e831d8a50bb1b9f4f1fba71f7f to your computer and use it in GitHub Desktop.
Save ljlm0402/5f69a1e831d8a50bb1b9f4f1fba71f7f to your computer and use it in GitHub Desktop.
배포전략

image


image


image


배포 브랜치 'master'

  • 제품으로 출시될 수 있는 브랜치
  • 'develop' 브랜치를 merge(병합) 을 통해 최종본을 릴리즈한다.
  • 해당 브랜치에 CI / CD 트리거를 걸어서 자동화 배포를 진행한다.

개발 브랜치 'develop'

  • 프로젝트를 진행하는 브랜치이다.
  • 각 'feature' 브랜치로 issues(이슈), feat(기능) 별로 분배한다.
  • 분배한 'feature' 브랜치를 Pull requests(검토 및 병합)을 통해 관리한다.

기능 별 브랜치 'feature'

  • 각 기능, 이슈로 브랜치를 나뉘어서 개발하는 브랜치이다.
  • 개별적인 push(배포)를 하며 'develop' 브랜치에서 개별적 통합을 진행한다.

GIT을 기반으로 한 프로젝트 개발프로세스

우린 Git-flow를 사용하고 있어요


image

Git Flow를 사용하여 branch를 관리 모든 branch는 pull request 리뷰 완료후 merge

  • master: 개발, 테스트 완료후 검증이 완료된 코드가 있는 branch
  • develop: 개발이 끝난후 issue branch를 merge
  • issue(feature): develop에서 새로운 기능을 개발 진행
  • release: issue에서 develop으로 merge하여 master에 merge전 배포하여 테스트를 진행
  • hot-fix: release, master에서 발생한 버그를 수정

Gitflow 워크 플로우

GitHub Flow

image

Git-flow가 Github에서 사용하기에는 복잡하다고 나온 브랜칭 전략입니다, 흐름이 단순한 만큼 role도 단순합니다.

master 브랜치에 대한 role만 정확하다면 나머지 브랜치들에 대해서는 관여하지 않습니다.

즉, hotfix 브랜치나 feature 브랜치를 구분하지 않습니다. 다만 우선순위가 다를 뿐입니다. pull request 기능을 사용하도록 권장합니다.

이 브랜칭 전략은 수시로 배포가 일어나며, CI와 배포가 자동화되어있는 프로젝트에 유용합니다.


사용법

1. master 브랜치는 어떤 때든 배포가 가능하다.

  • master 브랜치는 항상 최신 상태며, stable 상태로 product에 배포되는 브랜치
  • 이 브랜치에 대해서는 엄격한 role과 함께 사용한다
  • merge하기 전에 충분히 테스트를 해야한다. 테스트는 로컬에서 하는 것이 아니라 브랜치를 push 하고 CI 테스트 한다.

image

2. master에서 새로운일을 시작하기 위해 브랜치를 만든다면, 이름을 명확히 작성하자

  • 브랜치는 항상 master 브랜치에서 만든다
  • Git-flow와는 다르게 feature 브랜치나 develop 브랜치가 존재하지 않음
  • 새로운 기능을 추가하거나, 버그를 해결하기 위한 브랜치 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성해주도록 하자
  • 커밋메시지를 명확하게 작성하자

image

3. 원격지 브랜치로 수시로 push 하자

  • Git-flow와 상반되는 방식
  • 항상 원격지에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 해준다
  • 이는 하드웨어에 문제가 발생해 작업하던 부분이 없어지더라도, 원격지에 있는 소스를 받아서 작업할 수 있도록 해준다

4. 피드백이나 도움이 필요할 때, 그리고 merge 준비가 완료되었을 때는 pull request를 생성한다

  • pull request는 코드 리뷰를 도와주는 시스템
  • 이것을 이용해 자신의 코드를 공유하고, 리뷰받자
  • merge 준비가 완료되었다면 master 브랜치로 반영을 요구하자

image

5. 기능에 대한 리뷰와 논의가 끝난 후 master로 merge한다

  • 곧장 product로 반영이될 기능이므로, 이해관계가 연결된 사람들과 충분한 논의 이후 반영하도록 한다
  • 물론 CI도 통과해야한다!

image

6. master로 merge되고 push 되었을 때는, 즉시 배포되어야한다

  • GitHub-flow의 핵심
  • master로 merge가 일어나면 자동으로 배포가 되도록 설정해놓는다

image

Git 브랜칭 전략 : Git-flow와 Github-flow

GitHub Flow

Understanding the GitHub flow

Git Workflows

@WhiteHyun
Copy link

좋은 글 잘 봤습니다 😊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment