Rebase
Main
: Release에서 Main으로 넘어온 이후에 발견된 문제는 Hotfix 브랜치 생성하여 바로 고쳐서 적용해줌 > 이후 다시 작업하는 브랜치(Develop, Feature)로 이동하여 작업
Release
: 버그가 생기면 Develop으로 다시 보내주고 버그픽스(Bugfix)가 끝나면 배포를 위해 Main으로 보냄
Develop
: 브랜치를 한개 더 생성하여 작업자들끼리 미리 맞춰볼 수 있음 (QA를 거치기 위해 완성되면 Release으로 보냄)
Feature
: Develop에서 feature를 만들어서 작업
git flow init
둘다 병합이지만 다르다
브랜치들에서 작업한 커밋메세지들이 merge할 때 Main(base)으로 다 들어오고, merge 커밋이 시간 순서대로 작업 브랜치 커밋이 섞여서 들어온다.
-> 문제가 생겼을 때 history의 많은 커밋 중 해당 커밋을 찾기가 어려움
불필요한 머지 커밋이 남지 않음
같은 작업을 한 브랜치의 커밋끼리 모임 (들어가는 기준점이 마지막 커밋이 있는 곳으로 바뀌는 것)
커밋이 변경되기 때문에 커밋마다 conflicts가 일어날 수 있으므로 커밋을 많이 쌓아두지 말고 rebase를 자주 해주는게 좋음
명령어가 따로 있는것이 아니라 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)
깃 로그에는 살아있다~~
공부하며 정리&기록하는 ._. 씅로그