Git Workflow & Rebase

Git Flow

1. main branch is used for production releases
2. a develop branch is created from main
3. the develop branch contains stable features for the next release
4. create as many feature branches as you like
5. integrate when the feature is stable
6. changes on the develop branch must be merged back into feature brannches
7. use a realse branch to isolate and stabilize the release (develop branch에서는 수정할수가없다. 그래서 release 에서 버그픽스를 한다)
8. main brach에서 merge가됬다. v2.0.0
9. 에러가 생기면 create hot fix branch to patch a production release (급한 기능)
10. v2.0.1 Hot fixes are integrated into both main and develop

master : 제품으로 출시될 수 있는 브랜치
develop : 다음 출시 버전을 개발하는 브랜치
feature : 기능을 개발하는 브랜치
release : 이번 출시 버전을 준비하는 브랜치
hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치

Git Rebase

Merge and Rebase

• Git Merge는 시간에 맞게 사이사이에 들어온다.
• Git Rebase는 본인 브랜치가최상단으로 보여주는게 깃 리베이스다.
• both of these commands are designed to integrate changes from one branch into another branch- they just do it in very different ways.
  

problems

• 불필요한 merge commit 생성: 모든 feature branch마다 "merge commit"이 남습니다. 만약 main 브랜치를 공유하는 개발자가 많고 프로젝트의 규모가 크다면, 브랜치 히스토리가 지저분해지기 쉽습니다.
• 복잡한 프로젝트 히스토리: 독립된 브랜치에서 로직하나를 작성하고 수정하더라도, 다른 작없과 그내역이 겹쳐 구분하기 어려워집니다. 이런 상황을 프로젝트의 히스토리가 복잡하다고 표현합니다.
  

Git Rebase

커밋 고유 번호의 앞 6자리만으로도 어떤 커밋을 지칭하는 지 알 수 있습니다.
여기서 sign-in branch의 최신 커밋 고유 번호는: 2eb2d9
Rebase는 내 commit의 base를 변경하여, commit history를 일렬로 잘 정리해줍니다.해당 브랜치의 base commit을 확인하는 방법 : git merge-base main feature/sign-in (필수 아님)
conflicts: Conflict는 commit과 commit 사이에서 일어나는 작업 내용 사이의 충돌이므로, 세 개의 커밋이 한 번에 충돌 날 가능성이 있습니다.

Squash

[새로운 작업을 모두 마치고 push 하기전에는]1. main branch로 이동하여 remote main을 pull 받는다.
2. 내가 push 할 Feature branch 로 이동한다.
3. git rebase -i main를 진행한다.

[rebase 하는 동안 squash 진행할때에는]1. 가장 오래된 commit을 pick한다.
2. 다른 커밋 메세지는 가장 오래된 commit을 기준으로 squash한다.
3. 다른 커밋의 작업 내역이 없어지는 것이 아닙니다.
4. esc -> :wq! 로 창에서 빠져나온다.

[수정용 에디터가 하나 더 나타납니다.]1. 최종적으로 이 rebase된 커밋의 내용을 작성하는 부분.
2. 현재까지 적은 커밋 메세지가 전부 나타난다.
3. 불필요한 내용을 제거하고 현재 수정내역에 대한 커밋 메세지를 정성껏 작성한다.
4. esc -> :wq! 로 에디터에서 빠져나온다.

[successfully rebase]1. 성공했다면 git log로 깔끔해진 커밋 메세지를 한번 감상한다.
2. push를 합니다.

[rebase후 push하기]1. rebase는 commit history를 정리하는 역활을한다.
2. 같은 브랜치에서 rebase를 할때마다 history가 달라질수있다.
3. 수정사항이 추가로 생긴후 다시 rebase하면 히스토리가 무조건 달라진다.
4. git은 history가 다른 브랜치의 푸쉬를 허용하지않는다.
5. git push origin feature/login -f -f옵션을 사용하여 force push를 진행한다.

[Rebase 중 충돌 해결하기]1. 충돌이 일어난 경우 Rebase가 진행되지도, 끝나지도 않고 도중에
멈춰 있어, 매우 당혹스럽다.
2. 터미널이 (rebase ~ 1/6) 과 같은 메세지로 rebase가 진행중임을
알려주니 겁먹지 않도록 하자!
3. 충돌은 충돌일 뿐, 해당하는 코드를 수정 후
4. Git add .
5. (Git commit은 하지 않는다. 수정 사항이 없으니까)
6. Git rebase ㅡㅡcontinue를 진행한다
7. 멈춰 있던 리베이스가 진행된다.
8. 충돌이 여러번 나면 그 때마다 충돌을 해결하고
git add . / git rebase ㅡㅡcontinue를 반복한다.
9. 계속 해결이 안된다면, git rebase ㅡㅡabort로 아예 rebase를
진행하기 전 상황으로 돌아갈 수도 있다.

Git 명령어

• Git reset soft vs hard
• Git log
• Git reflog
• Git checkout
• Git stash & git stash apply & git stash clear

rebase 사용하는방법

1. 일단 시작하기전에 백업을 해둔다 혹시모를 불상사때문에
   -->cp -rpv 현재폴더명 새로생성할폴더명
2. tig를 깔아준다. (내역을 다 볼수가있다.)
   -->apt-get install tig
3. rebase하기전에 로컬에있는 main branch를 업데이트해야합니다.
   -->git checkout main git pull origin main
4. 두가지 방법중에 첫번째 방법은 커밋 리스트개수 세는 rebase방식이다.
   -->git rebase -i HEAD~3
   한다음 목록세개가 나온다 처음에는 전부 pick으로 되어있는데 pick은 하나만 남겨두고 다 s(squash)로 바꿔준다. 그리고 커밋메세지를 제대로 작성하여야한다.
   4.1 master 브랜치에 직접 접근하는 방식
   -->git rebase -i main 병합할 브랜치명 (i (interactive))
   한다음 목록세개가 나온다 처음에는 전부 pick으로 되어있는데 pick은 하나만 남겨두고 다 s(squash)로 바꿔준다. 그리고 커밋메세지를 제대로 작성하여야한다.
   4.2 만약 충돌이 나면 git add . git rebase --continue
5. successfully rebased and updated 이렇게 뜨면 성공

기술 블로그: https://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html