GIT flow & GIT rebase 🎃

👻 GIT flow & GIT rebase 👻
(내가 보려고 정리하는 git flow & GIT rebase)

🐨 git flow란? 🐨

* 크게 main branch / feature branch로 나눠서 관리

• 여기 중간에 develop branch가 들어옴! (main branch라고 생각해도됨..!)
  ⚒ develop branch 찐 배포를 위한 마지막 단계의 브랜치라고 생각하면 됨! ⚒

• 실제 돌아가는 코드를 main branch

• 그 배포 바로 직전 단계에서 쓰는 develop branch

• 여기서 버그 고치면서 수정해나갈 수 있는 release branch

• 계속 고쳐나가면서 쓰는 feature branch
  (🫐 기본적으로 feature에서 수정할거 다 하고 develop으로 가는데, 그 와중에서 버그가 발견되면 release를 만들어서 버그 마무리하고 main으로 감.)
  (🫐 develop에서 머지를 하고 main으로 올림)

• 마지막으로 Htfix branch를 만들어서 최종 수정해서 Main으로 머지.

🐨 git rebase이란? 🐨

• git merge vs git rebase?
  둘다 코드를 합치는 명령어

• merge 명령어를 사용하는 이유?
  a branch와 b branch를 합치기 위해 사용. 내가 작성한 코드를 main에 합치려고.

• git merge의 단점

1. 불필요한 merge commit들이 생성
   (모든 feature branch마다 merge commit이 남아.. 프젝 규모가 크면 진짜 정신없겠찌.)
2. 복잡한 프로젝트 history
   (정신없는 merge commit때문에 버전관리두 힘들어짐)

• git rebase의 장점
  Rebase는 내 commit의 base를 변경하여 commit history를 일렬로 정리해준다.
  (<-> 반면 merge는 그대로 포개듯 겹쳐져서 모든 commit을 다 흡수하는 늬끰)

🐨 git squash란? 🐨

• 여러개의 커밋을 하나로 합쳐주는 것
  

🐨 Rebase replaces Merge 🐨

🫐 새로운 작업을 모두 마치고 push하기 전에는!

1. Main branch로 이동해 remote main을 pull 받기
2. 내가 push 할 feature branch로 이동
3. git rebase -i main 을 진행
4. 그다음 🌹push🌹

🫐 rebase 하는 동안 squash 진행할 때에는!

1. 가장 오래된 commit을 선택한다 (요걸 pick)
2. 다른 커밋 메시지는 가장 오래된 commit을 기준으로 squash한다!
(요걸 S라고해) -> 그렇게하면 세개의 커밋이 하나로 합쳐지는 것! 😎리베이스!😎
3. 다른 커밋의 작업 내역이 없어지는 것이 아님
4. ESC -> :wq로 빠져나오기

🐨 Example! 🐨

1. 내가 feature에서 작업중!
2. 내 옆 팀원A가 merge가 됐음.(코드가 업데투 되었어.)
3. git checkout main / git pull origin main 해서 받아오기
4. 그상태에서 다시 내 feature branch로 옴
5. 그럼 이제 내꺼 A꺼 같이 합쳐줘야 내 코드가 업데투 되겠지?
6. git rebase -i main 이라고 치면 -> 위 사진처럼 pick, pick, pick처럼 뜨겠지?
7. 가장 위에꺼만 pick으로 남기고 나머지는 s로 남기고(squash) :wq!해서 저장!
8. 그러면, 아까 commit3개를 합쳤으니까 각각의 내용이 있을거아냐?
9. 그럼 그거에 대해서 새로운 메시지를 하나 만들어서 최종 commit message를 만들어줘야해.
   
10. 이렇게 commit message 깔끔하게 정리해줘야함! :wq하고 빠져나오기.
11. "Successfully rebased!"라고 메시지가 뜨면 구웃~
12. git log 로 쫘악 확인해주고!
13. 다음 작업 이어나가주기.

🐨 rebase 후 push! 🐨

• 다시 한 번 말하지만 rebase는 commit history를 정리하는 역할.
  commit message를 정리해주니까 새로운 커밋으로 생각해서 아래와 같은 오류가 나올 수 있음 !

• 그럴 때는 <git push origin feature/login -f> 명령어!
  

• 일단 먼저 push 해보고 오류가 생길경우, push -f 해주기!

🐨 충돌이 나면? 🐨

1. 충돌이 일어난 경우 당황하지말고!
   
   이런식으로 충돌난 커밋에 대해 오류메시지가 뜰거야.
   그럼 그 충돌난 부분을 해결해주면 됨.
2. git add 하기. (git commit까지 할필요는 없어.)
3. git rebase __continue 를 진행하기
4. 근데 또 충돌나면? 또 git add -> git rebase __continue.. 반복!
5. 마지막 충돌까지 해결되면 successfully rebased! 하고 끝남!
6. 근데 계속 해결이 안되면, git rebase __abort 로 아예 rebase를 진행하기 전 상황으로 돌아갈 수도 있다!

• 메인브랜치에서 작업 노!
  😭 거기서 작업하면 안돼.. 정말류 😭
• 리베이스 상황알고 싶으면 git status 쳐보면 알 수 있음.

🐨 git 명령어 🐨

git reset soft vs hard
git log
git reflog
git checkout
git stash & git stash apply & git stash clear

🐨 git 실습! 🐨

1. clone먼저 받고!
2. 파일들어가서, feature/rebase 만들어서 거기루 들어가
3. commit 5개 정도 만들기
   
4. 누군가 메인에서 새로운 변경사항을 만들어서 푸시함.
5. 그걸 풀받아오기 위해 git checkout main 해서 git pull origin main 받아오기(main에서 풀받는거야..)
6. 그리고 다시 내 feature/rebase로 돌아오기
7. 내가 한 5개 커밋이랑 풀받아온거 다 합쳐줘야하니까 git rebase -i main하면! 스쿼시 s로 바꿔주기~~
   
8. :wq하고 나가면 아래 화면처럼 뜬다.
   
9. 이제 여기에 최종 commit message를 적어주면됨!
   
   tip) esc누른상태에서 dd 눌러주면 한번에 지워짐~!
10. 쨔란- 성공적이라고 뜨지? 훟ㅎㅎㅎ....^^
    
11. 요기서 git push origin feature/rebase 를 하고, pr을 올리면,
    
    요렇게 잘 뜸 ^^

• 이미 다 끝난 상태에서, 한번 더 커밋할 일이 생겼다?
  
• 똑같이 수정해주고 add commit rebase 해주면 됨 -> 이제 push! git push origin featrue/rebase :>
  
• 에러가 뜨니까 git push origin featrue/rebase -f 로 진행해주면됨!
  🐌 git rebase 완료 추카포카! 🐌

👽 면접질문?

🐥 깃 리베이스 / 머지의 차이점

• git rebase는 git merge와 같이 코드를 합치는 명령어입니다. 하지만 git rebase를 사용한다면 git merge로 merge하는 것보다 커밋 히스토리가 훨씬 깔끔하게 남기 때문에 다른 사람들의 작업을 보기가 편해집니다.
  Merge는 Merge commit 기록이 추가로 남게 되지만 Rebase의 경우에는 branch 병합 시 Merge commit 기록이 남지 않아 마치 하나의 브랜치에서 작업한 것처럼 보여진다.

🐙 rebase 🐙

🐙 merge 🐙

🐥 깃 스쿼시는 어떻게 동작하고, 왜쓰는가?

• git squash는 여러개의 커밋을 하나로 합쳐주는 것으로 git rebase의 과정 중 하나로 볼 수 있습니다. 깃 스쿼시는 깃 리베이스를 통해 사용할 수 있는데 여러 커밋들을 's'로 변경한 다음 저장하면 여러개의 커밋을 하나로 만들 수 있음.

🐣 좀 더 자세히!
git rebase는 말 그대로 커밋의 base를 다시(re) 정하는 작업입니다. 우리가 입력했던 $ git rebase master dev라는 명령어를 풀어서 설명하자면 “master와 dev 브랜치의 공통 조상 커밋부터 dev 브랜치까지의 모든 커밋의 base를 master 브랜치의 위치로 바꾸어라”라는 의미인 것이죠. 그렇기 때문에 master와 dev의 공통 조상 커밋인 C1부터 dev에만 있었던 C4, C5 커밋들이 master 브랜치가 가리키고 있던 C3을 base로 하여 다시 적용된 것입니다.