Rebase

choi seung-i·2022년 5월 15일
0

공부로그

목록 보기
14/25
post-thumbnail

Rebase

Git Flow

Main(v1.0.0) - (Release) - Develop - Feature

Main : Release에서 Main으로 넘어온 이후에 발견된 문제는 Hotfix 브랜치 생성하여 바로 고쳐서 적용해줌 > 이후 다시 작업하는 브랜치(Develop, Feature)로 이동하여 작업

Release : 버그가 생기면 Develop으로 다시 보내주고 버그픽스(Bugfix)가 끝나면 배포를 위해 Main으로 보냄

Develop : 브랜치를 한개 더 생성하여 작업자들끼리 미리 맞춰볼 수 있음 (QA를 거치기 위해 완성되면 Release으로 보냄)

Feature : Develop에서 feature를 만들어서 작업

git flow init


merge와의 차이점

둘다 병합이지만 다르다

merge

브랜치들에서 작업한 커밋메세지들이 merge할 때 Main(base)으로 다 들어오고, merge 커밋이 시간 순서대로 작업 브랜치 커밋이 섞여서 들어온다.
-> 문제가 생겼을 때 history의 많은 커밋 중 해당 커밋을 찾기가 어려움

Rebase

불필요한 머지 커밋이 남지 않음
같은 작업을 한 브랜치의 커밋끼리 모임 (들어가는 기준점이 마지막 커밋이 있는 곳으로 바뀌는 것)

커밋이 변경되기 때문에 커밋마다 conflicts가 일어날 수 있으므로 커밋을 많이 쌓아두지 말고 rebase를 자주 해주는게 좋음

Squash

명령어가 따로 있는것이 아니라 Rebase 과정에서 커밋을 한개로 합칠 수 있다.

Rebase하는 동안 squash진행할 때에는
가장 오래된 commit을 pick 한다(맨 위에)
나머지는 s 붙여서 squash 한다.

pick 커밋메세지
pick 커밋메세지
s, 커밋메세지
s, 커밋메세지

:wq 입력하고 나오면 끝

-> 이후 수정용 에디터가 하나 더 나타나는데 현재까지의 커밋 메세지가 전부 나타남 (합친 커밋에 대한 내용을 작성) :wq로 저장하고 빠져나옴

-> 커밋메세지 수정 후 깃헙에 push하려고 하면 오류남 (rebase되면 history가 달라지기 때문에)

error: failed to push some refs to '~~~' 오류가 나는건?

git push origin feature/login -f : -f 옵션을 사용하여 강제로 push 진행

깨끗해진 커밋!

Rebase 후 push해서 commits(1)

깃 로그에는 살아있다~~



공부하며 정리&기록하는 ._. 씅로그

profile
Front-end

0개의 댓글