Git Workflow & Rebase

kh6619·2021년 10월 23일
1

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 "브랜치명"

만약 충돌이 난다면?

  1. master 브랜치로 이동하여 pull을 받는다
  2. 충돌(conflict)이 발생한 브랜치로 넘어간 git rebase -i main을 입력하고 충돌부분을 확인하고 수정한다.
  3. 수정 후 git add. 후 commit은 따로 진행하지 않고, git rebase --continue를 진행한다.
  4. git push origin "브랜치명" 진행 이후 rejected 발생하면, git push origin "브랜치명" -f를 통해 푸쉬한다. (여기서 주의할 것, 충돌이 나고 rejected가 났다고 해서 무조건 force push를 하면 안되고 수정 내용들을 확인하고 해야함)
profile
발전하고 싶은 프론트엔드 개발자 입니다 :)

0개의 댓글