Git flow & Git rebase

hazel's·2022년 5월 10일

목록 보기

6/8

Git Flow

실제로 배포되고 보여지는 브랜치가 main or master branch이고,develop branch는 우리가 실제로 작업하는 브랜치이다.다음버전의 코드를 위해서 우리가 여기서 작업을 한다. 기능별로 feature 파서 작업하는 것마다 커밋을 쌓일것이고 완료하면 머지가 될것이다. 동료의 PR이 머지가 되었을 경우, 내 브랜치에도 동료가 하는 작업을 받아와야 한다. develop 브랜치내용을 메인에 바로 보내는 것은 아니다. 중간에 테스트하는 단계가 필요하다. 그래서 release라는 브랜치를 생성을해서 테스트해본다.

사전에 relaease bugfix를 하고 완료된 내용들은 우리가 작업하는 것과 싱크를 맞춰야 한다. 맞춘 것을 반영해서 최신화를 해야한다. 이 과정을 거쳐 실제로 배포를 해도 괜찮겠다는 결과가 나오면 main branch로 배포한다.

근데 서비스가 되고 있는 상태에서 로그인이 안되는 문제가 생긴다면?

다시 전 과정을 하기에는 너무 번거롭기 때문에 main에서 hotfix브랜치를 파서 빨리 적용한다. 적용을 한뒤 바로 main에 다시 배포한다.

지금까지 했던 방식은 main이랑 feature만 진행을 했었다.

Git Rebase

merge와 rebase 둘다 병합시키기위해서 사용하는 방법이지만, 두가지는 다르다.

실행결과는 같지만 commit history가 달라진다.
merge는 쉽고 안저하지만 commit history가 지저분할 수 있다 반면 rebase는 잘 모르고 사용할 경우 위험할 수 있어 까다롭지만 commit history를 깔끔하게 관리가능.

Merge

main에서 사인업 브랜치와 사인인 브랜치가 있다.
둘다 커밋을 한 시점은 시간의 흐름에 따라 다르다.
사인업이 머지가 되면 커밋이 메인브랜치에 딸려온다 머지커밋까지 추가가 된다.
그다음에 사인인에서 작업을 진행을 하고 메인브랜치 변경된 내용도 내 브랜치에도 최신화를 시켜줘야 한다.
merge1

merge2

1번과 2번 사이로 들어온다.
merge3

merge4

붙었던 머지커밋도 기록되어 있을 것이다.
merge5

merge6

단점: 머지가 많아서 파악하기가 힘들수 있다.

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

rebase

기준점을 다시 만든다. 기준베이스를 바꾸는 것이다.
처음은 기준은 메인브랜치임. 리베이스를 진행하게 되면 머지커밋이 있는것이 없어지고 기준이 사인업이 붙은 시점이 되어 버린다. 베이스를 새로 설정하는 의미라고 생각하면 편하다.

conflict
confilct는 커밋과 커밋사이에서 일어나는 작업 내용 사이의 충돌이므로, 세개의 커밋이 한 번에 충돌 날 가능성이 있다.

컨플릭트를 줄이기 위해서는 커밋을 줄여야 하는 것은 아니고 커밋이 많이 쌓이기 전에 리베이스를 진행하는 것이 좋다.

squash

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

git add.
git commit -m "수정내용"
git checkout master
git pull origin master
git checkout feature/파일이름
git rebase -i master

[Rebase 하는 동안 squash 진행할 때에는]
1. 가장 오래된 commit을 pick한다.
2. 다른 커밋 메세지는 가장 오래된 commit 기준으로 squash 한다.
2-1. i 누르고 두번째 pick부터 지우고 s로 변경.
3. 다른 커밋 작업 내역이 없어지는 것은 아니다.
4. esc -> :wq 로 창에서 빠져나온다.

[수정용이 또하나 나옴]

1.최종적으로 rebase된 커밋의 내용을 작성하는 부분.
2.현재까지 적은 커밋 메세지가 나타난다.
3.i 누르고 불필요한 내용을 제거하고 현재 수정 내역에 대한 커밋 메세지를 작성한다.
4.esc -> :wq 저장하고 나온다.

[Rebase후 push하기]
1. git log으로 commit이 하나인지 확인.
2. git push origin feature/작업이름
3. rebase는 commit history를 정리하는 역할을 한다.
4. 같은 브랜치에서 리베이스를 할때마다 history는 달라질 수 있다.
5. 수정 사항이 추가로 생긴 후 다시 리베이스하면 history가 무조건 달라진다.
6. git과 history가 다른 branch의 push를 허용하지 않는다.
7.'git push origin feature/login -f => -f 옵션을 사용하여 force push를 진행한다.

git push origin feature/작업이름