Git 브랜치전략

브랜치전략

git-flow

1. 5가지 브랜치(마스터, 디벨롭 , 피처, 릴리스, 핫픽스)로 관리

2. 메인 브랜치는 master(실 배포용) 브랜치와 develop(개발용) 브랜치로 구성, 항시 유지됨

3. 피처 브랜치는 develop 브랜치로부터 분기되며, 기능 단위로 관리. 해당 기능이 완성될 때까지 유지 → 완성 후 Merge 혹은 Drop → 해당 피처 삭제
1. 일반적으로 피처 브랜치의 네이밍은 feature/기능요약 형식으로 작성됨 feature/login
2. 이슈추적을 사용한다면, feature/{이슈넘버}-{기능요약} 형식으로 작성 feature/#13-login

4. 릴리스 브랜치는 develop 브랜치에서 실 배포 이전 QA를 위한 브랜치 (최종 버그 수정 등). 이후 maseter 브랜치로 Merge하고, 버그 수정 사항은 develop 브랜치에도 적용해주어야 함

5. 핫픽스 브랜치는 배포 버전에서 긴급한 수정이 필요할 때, master 브랜치에서 분기하여 작업하기 위한 브랜치

6. 보조브랜치는 개발자 로컬 저장소에서 보통 관리되며, 원격 저장소에는 Push하지 않는다.

github-flow

1. 하루에 변경사항을 작은 단위로 자주 병합/배포할 수 있는 구조로, CI/CD를 실천하기 위한 브랜치 전략

2. git-flow보다 간소화되어 있고, 메인 이외의 브랜치를 구분하지 않음 → 개발하고자 하는 내용에 대한 명세를 브랜치명에 명확히 작성해주어야 함.

3. 메인(master) 브랜치는 항상 최신 상태이며, 엄격한 Role과 함께 관리
• 모든 커밋은 언제 배포하든 문제가 없어야 하고, 언제든 새로운 브랜치를 만들어도 문제가 없어야 한다.

4. 나머지 브랜치는 항상 master 브랜치로부터 분기되며, 체계적인 분류가 없기 때문에 브랜치명과 커밋 메시지를 명확하게 작성할 필요가 있음.

5. 수시로 메인 브랜치에 Push하여야 함.

6. 피드백이나 도움이 필요할 때, Merge 준비가 완료되었을 때 PR 생성, 리뷰와 논의 후 master 브랜치로 Merge → 즉시 배포***

7. 소규모 팀이고, 단일 릴리즈 버전밖에 존재하지 않는 경우 사용하는 것을 권장

정리

1. 메인(master)브랜치에 얼마나 수시로 Push / 배포하는지

2. 브랜치의 구분이 얼마나 체계적인지 → 이슈, PR 등으로 보완

3. 메인 뼈대만 채택하고 저희끼리 컨벤션을 커스텀해가는 것이 좋을 것 같습니다.

참고자료

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

😎 Git 브랜치를 효과적으로 나누고, 관리하기대표적인 브랜칭(branching) 전략Git-flowGitHub-flow📃Git-flowGit-flow는 브랜치를 크게 4가지로 나누어 개발하는 전략입니다.메인 브랜치(Main branch)피처 브랜치(Feature branch) 또는 토픽 브랜치(Topic branch)릴리스 브랜치(Release branch)핫픽스 브랜치(Hotfix branch) 가장 중심이 되는 브랜치는 master와 develop 브랜치이며, merge된 feature, release, hotfix 브랜치는 삭제하도록합니다. Git-flow 전략은 주기적으로 배포를 해야하는 프로젝트에는 적합하지만,브랜치가 많아 복잡하고 어떤 프로젝트에 따라서는 몇몇 브랜치가 애매한 포지션을 가질 ..

https://hellowoori.tistory.com/56

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

우아한스터디

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

[GIT] 📈 깃 브랜치 전략 정리 - Github Flow / Git Flow

GIT 브랜치 전략 브랜치 전략이란 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 work-flow다. 브랜치의 생성, 삭제, 병합 등 git의 유연한 구조를 활용해서, 각 개발자들의 혼란을 최대한 줄이며 다양한 방식으로 소스를 관리하는 역할을 한다. 즉, 브랜치 생성에 규칙을 만들어서 협업을 유연하게 하는 방법론을 말한다. 만일 브랜치 전략이 없으면? 브랜치 전략이 없을 때 단점은 깃을 사용한지 얼마 안됐던 개발자라면 모두 겪어본 상황들일 것이다. 어떤 브랜치가 최신 브랜치지? 어떤 브랜치를 끌어와서 개발을 시작해야 하지? 어디에 Push를 보내야 하지? 핫픽스를 해야하는데 어떤 브랜치를 기준으로 수정해야할까? 배포 버전은 어떤 걸 골라야하지? 규모가 어느정도 이상 ..

https://inpa.tistory.com/entry/GIT-⚡️-github-flow-git-flow-📈-브랜치-전략#git-flow_브랜치_구조

팀 문화

1. 적극적으로 의견을 제시했으면 합니다. 사소한 것이라도 좋습니다 👍
1. 결국 제품이나 개발과정을 좋은 방향으로 발전시키기 위함이라는 같은 목적을 갖고 있기 때문에, 충분한 의견 교류로 합의점을 찾아나가면 좋을 것 같습니다.

2. 궁금한 부분이나 막히는 부분이 있다면 즉시 공유했으면 합니다. 또한 본인이 설명할 수 있거나 도움을 줄 수 있다면 적극적으로 교류했으면 합니다.

3. 디스코드 이모지를 통한 멘트 교통정리..

기타의견

1. 개발서버 선택도 얘기해보면 좋을 듯 합니다! (CRA / Vite)

2. 깃허브 이슈트래커 (마일스톤, 프로젝트 보드 활용)
1. 너무 본격적으로 활용하지 않아도, 다들 기본적으로 Task를 Issues에서 관리하고 PR/Commit과 연동을 하고 있더라고요.
2. 노션에서는 가볍게 링크만 걸어주는 식으로 관리해도 좋을 것 같습니다.

3. 이전 기수들 노션 페이지와 깃헙 레포를 정리해놨는데, 본격적으로 시작하기 전에 읽어보면 도움이 될 것 같습니다.

4. 프로젝트의 공통 목표 + 각자 생각하는 목표, 얻어갔으면 하는 것

5. 실제로 본인의 개발 브랜치를 분기한 시점에서, 협업이 어떻게 이루어지는지 디테일한 사례를 여쭤봐도 좋을 것 같습니다. → 커피챗 질문방에 작성함

6. 내일 QR은 13시 입실 14시 퇴실이라고 합니다! 회의나 코어타임 시간 자유롭게 정하면 될 것 같습니다.

🗑️

(번역) ‘Create React App 권장을 Vite로 대체’ PR 대한 Dan Abramov의 답변

PR 링크: https://github.com/reactjs/reactjs.org/pull/5487

https://junghan92.medium.com/번역-create-react-app-권장을-vite로-대체-pr-대한-dan-abramov의-답변-3050b5678ac8