Git-flow

구성원 별로 브렌치를 만들어서 프로젝트 진행

전략을 짜는 이유? Conflict를 방지하기 위함

Git-Flow를 사용한 이유 : 개발 인원이 많아져서 이를 효율적으로 관리하기 위함

Git-flow 전략

master(main) - 제품으로 출시될 수 있는 브렌치

develop - 다음으로 출시할 버전을 개발하는 브렌치

feature - 기능을 개발하는 브랜치(issues 기능을 사용)

pull request 기능으로 관리 - 코드 리뷰를 남기기 위함

1. dev branch -> issues 탭에 추가
2. issues 탭에 미리 정한 To-Do-List를 추가(Zira, Splint)
3. 현재 dev 브렌치를 기준 feature 브렌치를 따온다
4. 작업 완료 후 pull Request를 요청함.
5. pull Request 된 코드에 대한 코드 리뷰함.
6. 리뷰가 끝나면, dev에 합침
7. issues 탭을 close한 뒤 해당 feature 브렌치를 삭제

추가로, 브렌치 보호 정책을 통해 master(main)에 push 되는 것을 방지

Git-flow 테스트

가상 역할 : Controller 코딩

checkout : 브렌치 간 이동 | 커밋 내역 간 이동

• ex) git checkout -b 브렌치명, git checkout 커밋id

git -help : 깃 관련 명령어 확인

😃협업 시 깃헙 사용 과정

1. gitHub에 작업할 이슈 생성(#번호)
2. 로컬 레포지토리에서 develop 브렌치 pull
3. feature#번호 브렌치 생성
4. 이슈 관련 내용 코드 수정
5. add - commit - push
6. feature#번호 -> develop 로 pull request 생성
7. 코드 리뷰
8. develop 브렌치에 merge 후 pull request close
9. 이슈에 수정한 내용 간략히 적은 뒤 close
10. feature# 브렌치 삭제
11. 이 후 작업은 다른 이슈 생성 및 develop 브렌치 pull한 뒤 작업 재개

🌟실습

깃 플로우 테스트