Git Flow
-현업에가면 굉장히 자주 사용 될 것이다.
-
Main branch is used for profuction releases
우리가 1.0.0버전을 사용하는 동안 개발자들은 그 후를 준비한다. -
A develop branch is created from main
-
The develop branch contains stable features for the next release
-
Create as many feature branches as you like
-
Integrate when the feature is stable
디벨롭 브랜치 : 피처브랜치의 푸쉬용 (그래서 수정할 수 없음)
총 다섯개의 브랜치를 쓴다.
개념만 알며 넘어가고 현업에서 배포하며 익히기!
Git Rebase
Git rebase로 넘어가기전에 Git merge를 짚고 넘어가야한다.
MERGE : 어떤 브랜치랑 다른 브랜치하나를 합칠때 사용.
-Both of these commands are designed to integrate changes from one branch into another branch
problems
-불필요한 merge commit 생성
모든 feature branch 마다 "merge commit"이 남는다. 만약 main 브랜치를 공유하는 개발자가 많고, 프로젝트의 규모가 크다면, branch history가 지저분해지기 쉽다.
-복잡한 프로젝트 history
독립된 브랜치에서 로직 하나를 작업하고 수정하더라도, 다른 작업과 그 내역이 겹쳐 구분하기 어려워진다. 이런 상황을 프로젝트 history가 복잡하다고 표현.
git merge 는 사이사이에 다른사람들 커밋이 들어온다.
- 브랜치 상관없이 하나의 시간순대로 정렬
git rebase 는 내 메인브랜치에 나보다 먼저 된 커밋들이 있을 때 (내 브랜치가 처음 생긴 부분을 베이스라 함) 2!#@#!// 베이스가 같은 커밋은 형제이다.
다른 브렌치의 완전한 작업이 끝난 커밋을 합쳐서 다시 베이스화 한 후 커밋 내역을 일렬로 잘 정리하는 것이 rebase!
프론트는 리베이스를 더 더더욱 자주해야한다.
결국 같은 파일을 수정한 것이 아니라면 conflict 날 일이 없는 것은 merge와 비슷하지만 git history의 깔끔함을 생각했을때 rebase가 나은 것이다
git more anymore...
새로운 작업 모두 마치고 push 하기 전에는 -
-1.main branch로 이동하여 remote main을 full받는다.
2.push 할 feature branch 로 이동한다.
3. 'git rebase -i main' 를 진행한다.
rebase 하는 동안 squash 진행할 때는 -
- 1.가장 오래된 commit을 pick 한다.
- 2.다른 커밋 메세지는 가장 오래된 commit을 기준으로 squash 한다.
- 3.다른 커밋의 작업 내역이 없어지는 것이 아니다.
- 4.Esc -> :wq!로 창에서 빠져나온다.
----스쿼시는 리베이스를 할때 하나만 뒤로 보낼래 몽땅 뒤로보낼래?라고 물어보는 것
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를 진행하기 전 상황으로 돌아갈 수도 있다.
(내용 더 추가 예정)
