Git flow의 운영방식
Git flow
Main branch(시작) ➡️ Develop branch 생성 ➡️ feature(F1/F2) branch 생성(개발 진행) ➡️ Develop branch로 이동(feature F1 개발완료시) ➡️ feature F2 개발 준비 ➡️ Develop에서 pull을 받는다.(F1의 내용을 알아야 하기 때문에) ➡️ feature F2까지 개발완료 ➡️ Develop branch 개발완료 ➡️ Release/ v2.0.0(Develop 브랜치에서 생성) ➡️ QA과정(버그를 잡는 과정 : 각각의 브라우저(핸드폰, 인터넷익스플로러 등)에서 버그를 발견하고 수정한 뒤 Release branch에 남긴다.) ➡️ 최종체크 완료 ➡️ Main 브랜치 이동(V2.0.0) ➡️ 배포 후 에러발생 ➡️ Hotfix branch 생성(Main branch에서) ➡️ 에러수정 후 main으로 merge(v2.0.1) ➡️ 다음 개발을 위해 hotfix branch 작업내용 Develop으로 내려줌
Git flow를 사용하는 이유는?
개발단계에서 테스트를 거쳐 테스트가 완료된 안전한 코드만을 Main에 보관하기 위해서
branch를 병합하는 방식(rebase & merge)의 차이점
Git merge
- 베이스 커밋을 기점으로 각각의 브랜치를 생성하고 merge시 merge commit이 생긴다.
- 문제점 : 불필요한 merge commit 생성되어서 프로젝트의 규모가 크면 branch history(어떤 내용이 추가되고 언제 추가되었는지 수정되었는지 작업내용을 확인하기 어렵다)가 지저분해지기 쉽다.
Git Rebase
- 베이스 커밋의 위치를 옮겨주는 컨셉
- merge의 단점을 보완하기위해 탄생, 불필요한 merge commit을 제거하고 같은 작업을 진행한 commit끼리 모아줄 수 있다.
- 개발자의 편의에 맞게 커밋의 순서를 바꿀 수 있음.
- 기능개발 히스토리를 추적하는데 쉽다.
- 커밋들이 한 번에 충돌 날 가능성이 있다.(Conflicts)
Git rebase 실습
1. 커밋메시지를 3개 남긴 것을 확인할 수 있다.
2. git rebase -i main
3. squash를 통해 커밋로그 하나로 묶기
4. squash 후 커밋 하나로 만들기
5. Rebase 완료(Successfully rebased --- 메시지 확인할것)
6. git log로 확인
7. push 전 npm start로 다시 한번 확인
8. git push origin "브랜치명"
만약 충돌이 난다면?
- master 브랜치로 이동하여 pull을 받는다
- 충돌(conflict)이 발생한 브랜치로 넘어간 git rebase -i main을 입력하고 충돌부분을 확인하고 수정한다.
- 수정 후 git add. 후 commit은 따로 진행하지 않고, git rebase --continue를 진행한다.
- git push origin "브랜치명" 진행 이후 rejected 발생하면, git push origin "브랜치명" -f를 통해 푸쉬한다. (여기서 주의할 것, 충돌이 나고 rejected가 났다고 해서 무조건 force push를 하면 안되고 수정 내용들을 확인하고 해야함)
