38. TIL (Git Workflow)

1.git flow

• 개발단계에서 진행하는 코드 : develop. 배포단계 쯔음: release 이를 다시 메인으로 push

• feature : 개발단계

• hotfix : 오류가 발생했을 때 다시 브랜치 파서 진행

• 배포단계에서 서버를 안전하게 관리하기 위한 전략이 work-flow. 다섯개를 적재적소에 활용한다.

2. rebase, merge의 차이는 무엇인가?

• brew install tig : 그래프 형태로 커밋 볼 수 있음
  두 브랜치를 합치기 위해 사용하는 것은 똑같으나
  Merge는 기존의 브랜치 작업내용이 메인으로 다 딸려와 다른 브랜치에 메인을 복사해도 같이 따라옴
  불필요한 merge commit이 따라오고, 프로젝트 히스토리가 복잡해진다.

• rebase : 불필요한 merge commit이 사라짐
  같은 작업을 진행한 커밋끼리 모인다.
  git rebase -i main 으로 커밋 정리하기. squash를 사용해 하나의 커밋으로 정리!
  다시 main 기준을 잡아 작업을 진행한다 -
  커밋이 많이 쌓이면 git rebase squash를 통해 정리를 진행해주어야 한다.

3. git rebase를 사용해 불필요한 커밋을 하나로 squash 할 수 있다.

새로운 작업을 모두 마치고 Push 하기 전,
메인으로 이동해 remote main pull 받기 => push 할 브랜치로 이동 => git rebase -i main

rebase 동안 squash 진행하면?
가장 오래된 commit을 고른 후, 다른 커밋 메시지는 가장 오래된 커밋을 기준으로 squash한다.
맨 위의 것만 남기고 s로 바꿈
하나로 녹여 합친 커밋만 남겨놓기 : 앞의 커밋에 내용을 녹여 붙이겠다는 의미!
rebase된 커밋의 내용을 작성하는 창이 하나 더 뜨니, 작성해준다.!
살릴 것만 살리고 현재 수정 내역에 대한 것만 작성하고 저장.
git log로 확인!

- 충돌이 생기면?

충돌 코드 수정.
git add. => git rebase -continue 진행.
다시 commit 하면 내용이 늘어나니 하지 말기!!!!!
'git push origin feature/주소 입력 -f ' :
rebase 했는데 수정해서 오류가 발생하는 경우 강제 푸시!
히스토리가 달라지기 때문에 발생하는 오류이다!