*🔐Study Keyword :

✅ Rebase를 알아보자

- Git flow

• WHAT IS❓

• main-feature 사이에 develop 브랜치를 하나 더 만들어서 개발용 브랜치를 통해 merge 과정을 거친다.
• 이후 release 브랜치에서 테스트를 거쳐 버그를 찾아내고 merge를 한다
• 그렇게 v2.0.0이 탄생한다.
• main에서 버그가 다시 발생하면 Hot fix 브랜치를 만들어, 빨리 에러를 잡고 develop 브랜치가 아닌 main 브랜치로 바로 merge를 하게된다.
• 수정이 되면 모든 브랜치, develop, feature 브랜치에서 pull을 받아서 수정사항을 반영한다.

• WHY & WHNE USE❔❕

• brew install git-flow-avh을 통해 git flow 설치하기
  

• git flow 명령어를 통해서 해당 브랜치 명명해주기
  gitflow를 이용해서 만들 수 있는 branch들
• 1. master : 최종 릴리즈에 사용되는 안정된 버전
• 2. develop : 다음 릴리즈를 위해 개발중인 최신 버전
• 3. feature : 특정 기능 개발을 위한 branch
• 4. release : 릴리즈 점검을 위한 branch
• 5. hotfix : 긴급 버그 픽스를 위한 branch
• 6. support : 버전 호환성 문제를 처리하기 위한 branch

- Git rebase

• rebase도 결국 commit을 합치는 기능이다.
• 팀원마다 commit을 하는 횟수도 다르고 merge를 하는 순서도 다르다.
  
• 메인 브랜치입장에서 commit과 merge된 과정을 보면
• 불필요한 merge commit이 생성되고
• 프로젝트의 hisory가 복잡해지는 단점이 있다.

• git rebase의 목적은 늦게 merge한 사람의 commit을 제거하고

• rebase를 하며 commit을 정리해준다. `
  실제로는 main 베이스에서 시작된 브랜치들에서
  늦게 merge를 한 브랜치의 베이스가 변경된다.
  따라서 가장 마지막 commit의 베이스가 변경되어 commit history가 일렬로 정리된다.
  

• 중요하지 않은 commit들은 커밋의 흐름을 방해한다.
  따라서 불필요한 commit들은 하나로 합치는 게좋고 이러한 과정을 squash한다고 한다.
  

[새로운 작업 모두 마치고 push하기 전에]

• main 브랜치로 이동해 remote main을 pull받고
• push할 feature 브랜치로 이동하고

- git rebase -i main 명령어를 통해 main pull받고 merge를 한다.

[rebase 하는 동안 squash 진행할 땐]

- 가장 오래된 commit을 pick하여 다른 커밋 메세지는 오래된 commit 기준으로 squash 한다.

[수정용 에디터]

[Reabase 후 push]

• 리베이스는 커밋 히스토리를 정리하여 나의 마지막 커밋이 뒤로밀린다
  [rebase 중 충돌 해결]

- 충돌나면 git rebase --continue로 해당 코드 수정을 진행하고 git add, commit은 하지 않는다.

💡TIP) git rebase __abort 하면 rebas전으로 돌아간다

*💡conclusion

• 이제 merge는 잊어라 rebase가 시작된다!
• 추가로 공부하면 좋은 키워드가 넘친다~
  -

#📑Study Source

• 휴가에서 돌아온 소헌님의 열정 키노트를 활용한 강의 중 :)