Merge와 Rebase 비교

Rebase와 Merge는 서로 다른 branch에서의 변화들을 병합하기 위한 명령어임.
git merge는 모든 커밋의 시점을 유지한 상태에서 합집합을 만드는 명령어이고, git rebase는 시간 순서가 아닌 branch 기준으로 commit을 모아주고, 해당 브랜치의 첫 출발(기준) 커밋(base)을 변경해 줌 (동시에 squash 기능으로 하나의 commit으로 정리 가능)

git merge의 문제점

📍 불필요한 merge commit 생성
모든 feature branch마다 “merge commit” 이 남음/ 만약 main 브랜치를 공유하는 개발자가 많고, 프로젝트의 규모가 크다면, branch history가 지저분해지기 쉬움
📍 복잡한 프로젝트 history
독립된 브랜치에서 로직 하나를 작성하고 수정하더라도, 다른 작업과 그 내역이 겹쳐 구분하기 어려워짐/ 이런 상황을 프로젝트의 history가 복잡하다고 표현

유의 사항

• 해당 branch에서 여러 커밋이있는 상황이면, rebase하려는 대상 브랜치에 많은 변동사항이 생겼을 경우, 해당 branch의 각 커밋별로 모두 수많은 conflict를 해결해야하는 문제 발생하므로, commit 개수는 2~3개 이상 생성 하지 않도록 유의
• 혹시 local main의 history가 remote main의 history와 달라지면, pull 받으면됨

Git reset soft vs hard

--soft: uncommit changes, changes are left staged (index).
--mixed (default): uncommit + unstage changes, changes are left in working tree.
--hard: uncommit + unstage + delete changes, nothing left.

Git log
Git reflog : 모든 행위에 대한 log를 확인 가능, 해당 시점으로 이동 가능
Git stash & git stash apply & git stash clear
: 작업 중 다른 branch로 잠시 이동해야 하는데, commit 하지 않으면 이동 불가
: 이러한 경우, git stash를 통해, 작업중인 내용을 임시 저장 후, 돌아와서 복원 가능 (git stash apply)

git rebase -i main
: 원격 저장소의 main에 변경사항이 되어서 local branch의 base 변경이 필요할 때만 사용

git rebase -i HEAD~숫자
: git log에서 나오는 main 이후의 로그 숫자를 입력(맨 처음 commit만 남기고 sqush 할 것)
: 타인과 공유하는 branch의 commit은 최종 커밋 1개로만 유지할 것