DevPrep 하면서 브랜치 안나누고 작업하다 보니까 충돌이 자주 발생하는거 같아서
https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-github-flow-git-flow-%F0%9F%93%88-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%A0%84%EB%9E%B5
해당 블로그 글에서 많이 참고하고 배움
git branch 전략에 대해서 생각해보자
이것은 HUFTING 때 잘하는 분들과 함께 할 때의 branch 구조이다.
HUFTING 때의 Branch 구조
그러면 이제 dev 브랜치를 만들고 그 주변에 각자 개발할만한 feat 브랜치를 생성하면 되겠다
feature 브랜치에서 보조기능을 다 완성하고 나면 develop 브랜치로 merge를 한다.
결과가 안좋으면 해당 feature 브랜치를 버린다.
(main 브랜치에서 dev 브랜치를 만들고, dev 브랜치에서 feat 브랜치를 만든다.)
현재 main 밖에 없다
그런데 dev에서 main으로 merge하는 것은 언제언제 하는 것이지??
(밑에 GPT 답변)
어떤 branch를 만들까?? (DevPrep 프로젝트)
- main
- dev
- feat/기본-component-제작
- feat/IKpages
- feat/JWpages
이렇게 하는 것은 어떨지
기본 컴포넌트 제작시
[feat/기본-component-제작]에 코드 작성 후
문제 없을 시 [dev]로 merge
일반적인 page 및 파일 수정
[feat/이름pages]에 코드 작성 후
문제 없을 시 [dev]로 merge
언제 [dev] -> [main]으로 merge 하는가?
회의있는 날 당일 merge하기
근데 이렇게 되면 fork한 레포지토리에 코드를 올리고
원본 레포지토리에 풀리퀘를 보내는게 아니고
이렇게 원본 레포지토리의 브랜치 → 브랜치로 바로
pull request를 보내면 될 것 같다
이것도 review 신청이 되나??
→ 다른 브랜치 생성 후 review 모드 뜨는지 확인해보기
