GIT REBASE

우리가 기존에 사용하던 머지방식

initial-->1--> B
 	   \
            A-->B
아무도 수정을 안했을경우

initial-->1--> C(마스터가변함)-->M
 	   \              /
            A----------->B
그사이에 변화가있으면 머지 커밋메시지를 남김

근데
이렇게하면 당장 머지는 잘되지만 나중에 히스토리를 파악하기 굉장히 번거롭다. 이런부분을 시간상으로 아주 잘 정리되게끔 커밋을 쌓는 방법이 rebase이다.

REBASE

애초에 리베이스를 하게되면 기준을 바꾸게 된다.
1의 기준을 가지고 있던걸 d다음으로 베이스(기준)을 가장 최근으로 하고싶으니까 바꾸는거임 가장 최근의 마스터로
그럴려면 마스터의 변화사항을 알아야한다.
마스터의 변함을 감지한다음 리베이스를 해야함.

initial-->1--> C(마스터가변함)-->D---Rebase
 	   \              /
            A----------->B

리베이스를 했다는건 내가 가장 최근에 마스터가 된다는것임. 옛날에 브랜치는 여기서 땃는데 기준을 바꿔서 가장 최근의 마스터로 기준을 바꾸는게 리베이스임.
가장 최근의 위치로 오게되니까

initial-->1--> C(마스터가변함)-->D---A---B
 	   \              /
            A----------->B

문제

conflict가 엄청난다
시간의 갭동안 상당한 수정사항들이 누적되어있을것이고 대부분은 겹치기 떄문에
리베이스 대상이 된 것들은 일반적으로 컨플릭트가 나게됌.
컨플릭트를 잘 조심히 하도록하자

squash

커밋이 여러개면 시간상 히스토리를 간편히 보기위해서 쓰는건데 커밋이 여러개 있으면 이미 간편한게 아니기 떄문에
항상 하나로 합침 squash이라는 기능을 이용함.
스쿼시 써서 하는데 깃에서는 커맨드창에서 -i 인터렉티브 모드써서 스쿼시 편하게 쓰고 리베이스할떄 편함

Git Flow

지금까지는 브랜치를 master하나있고 거기에서 feature브랜치하나따는식으로 했다.
마스터를 드고 develop이라는 브런치를 하나쓰고 이건 개발기간동에 feature는 기능기간떄
마스터로 배포를 할수는 없음 가장소중해서 출시할떄는 release브랜치를 써서 릴리즈 버젼이랑 디벨롭버젼은 당연히 다를것. 개발과정중에 릴리즈랑 머지해서 중간에 한번 배포해보고 픽스를해주는데 그렇기 떄문에 hotfix라는 브랜치를 또만듬.그러면 릴리즈간에 일어났던 버그들을 핫픽스 브랜치를 통해 릴리즈에 반영하고 이게 이제 안정적이면 깃 디벨롭에 반영함. 하나의 흐름이니까 걍 알고가면됌

무조건 디벨롭이 안정적이라고 해서 바로 마스터로가는것이 아니라 일단 릴리즈하고 일단 거기서 테스트하고 핫픽스까지 다하고 최종적으로 마스터로간다. 마스터는 그만큼 중요하고 무결하다.