[Git] rebase

목차

1. Git flow가 어떤 방식으로 운영 되는 방법과 main, develop, feature, release, hotfix 브랜치를 각각 구분하는 방법

2. branch를 병합하는 두 가지 방식인 rebase와 merge의 차이점

3. rebase 명령어를 사용하여 불필요한 커밋을 하나로 squash 하는 방법

---

Git Flow

1. Hotfix: Main에서 minor한 에러 발생시 Main에서 바로 브랜치를 만들어서 디버깅 하는 브랜치. 디버깅 후 Main에 merge.

2. Main: 서비스 배포용 브랜치.

3. Release: Develop에서 Main으로 올라가기 전에 QA 등을 하는 브랜치.

4. Develop: 중간 Feature merge용 브랜치.

5. Feature: 실제 기능 작업 브랜치, 중간 중간에 계속 Develop 브랜치를 pull 하여 최신화 해야 함.

git flow init: 위 형식 그대로 branch가 만들어지는 명령어

---

Git rebase

Git merge

• 불필요한 merge commit 생성
  signin bracnh에서 git merge main 할 경우 signup branch에서 commit 이력의 시간을 바탕으로 merge 된다. 모든 feature branch마다 merge commit 남아서 history가 지저분해 진다.

• 복잡한 프로젝트 histroy
  위와 같이 하게 되면 commit 이력 파악을 하기가 매우 어려워진다. 이를 방지하고자 rebase를 사용한다.

Git rebase

• sigin branch의 base가 initial-setting에서 rebase한 시간대로 기준으로 바뀐다.
• 하지만 rebase하면 conflict가 발생할 가능성이 높다. 또한 모든 commit에 대해서 conflict를 해결해야 한다.

Squash

• git rebase -i main: squash 하는 과정이 나옴
• pick: 살려둘 commit을 뽑는 것, 되도록 가장 오래된 commit을 살리고 그 이후의 것은 s로 바꾸는 것이 좋음
• s: squash의 약자. pick한 commit에 합쳐질 commit을 뽑는 것

• "#" 주석으로 된 부분은 신경쓰지 말고 주석이 없는 부분만 수정하면 됨.

• git push origin {branch} -f : 강제 푸쉬
• git rebase -i main: 강제 푸쉬 후 conflict 나는 부분을 rebase에서 수정할 수 있다.

<이전 상태로 돌아갈 경우>

• git rebase --abort: rebase 이전 상태로 돌아감

<rebase 에서 수정할 경우>

• git add .
• git rebase --continue: commit 이력이 많으면 이력만큼 rebase 수정을 해야할 수 있음.
• git add .
• git rebase --continue: conflict가 없으면 rebase 창이 나타나지 않음
• git push origin {branch} -f: conflict가 없음에도 불구하고 에러가 나서 force push하는 이유는 rebase 하면 이전 commit이 없어지고 새로 commit 만들어지기 때문이다. 여기서 발생하는 에러에 대해서 크게 문제가 되지 않는다.