gitflow workflow

master(main) : 배포용
hotfixes : 급한 수정용
release : 임시 배포용(디버깅)
develop : 개발용
feature : 실제 API별 기능개발

git fork workflow - forking repository

회사 레포지토리(upstream)에는 직접 push를 할 수 없고 fork를 떠서 복제본을 내 깃허브(origin)에 가져온 뒤,
작업 후에 커밋후 push(git push origin feature-#1) pull(merge) request(요청) (PR)하여 확인후 합치는 방식입니다.
매일 아침 스크럼회의(merge 결정등) 후 회사 레포지토리에 합쳐진 소스코드를 pull(git pull upstream develop)로 다운받습니다.

순서

UPSTREAM

1. 초기셋팅 add commit 후 push
2. git checkout -b develop

ORIGIN

1. fork
2. git clone 주소
3. git checkout -b feature-#1 (#1은 issue(담당 기능)의 번호)
4. 개발
5. git push origin feature-#1
6. Compare & pull request (develop으로 PR요청)

UPSTREAM

1. 변경사항 확인 후 merge or reject 결정

ORIGIN

1. git remote add upstream 주소
2. git checkout -b develop
3. git pull upstream develop
4. git checkout -b feature-#2 (develop에서 브랜치 따야함)

~ 반복

• 주의사항

1. 충돌이 나지않게 팀원별로 각자 다른 기능을 개발해야한다.
2. merge전에 기능을 하나 더 개발할 경우 기능단위로 develop에서 브랜치를 새로 따야한다. - 충돌이 나지않게 기존 브랜치에서 수정한 부분외에 개발을 해야함.
   (따라서 연계된 기능 말고 다른 기능을 개발해야 함 - 연계된 경우 develop에는 전 개발기능이 없음)