'우리 이거 삭제하지말자' 프로젝트를 진행하며 초기에 rebase를 활용하여 branch를 병합했었다. 하지만 충돌해결에 어려움을 겪었었고, branch들을 깔끔하게 보여줄 수는 있지만, 너무 많은 시간들을 소요한다는 단점 때문에 rebase를 포기하고 merge를 활용하여 branch를 관리했었는데, 그에 대해서 알아보자.

main 브랜치로 branch-1 브랜치를 병합하고 싶다면, main브랜치로 이동한 후, git merge branch-1을 입력해야한다.

branch-1 브랜치를 main브랜치로 옮기고 싶다면, branch-1브랜치로 가서 git rebase main 을 입력해주면 된다. 이 경우, main 브랜치의 HEAD는 최종 커밋보다 뒤에 있다.(위 사진 참조)
이 경우, main브랜치로 이동해서 git merge branch-1 명령어를 실행해주면 된다.
만일 branch-1 브랜치의 여러 커밋을 main브랜치로 rebase하는 경우 충돌이 발생한다면, 각 커밋마다 충돌을 해결해주고 git rebase --continue를 입력해주어야한다.
충돌을 해결하는 과정에서 main브랜치의 내역을 선택한다면 main브랜치 입장에서는 변경된 내용이 없으므로 커밋이 따로 남지 않을 수 있다.(branch-1의 2개 커밋을 rebase했으나 1개의 커밋만 main브랜치 이후에 생성될 수도 있다는 의미)
공유된 브랜치에서는 사용 자제: 이미 원격 저장소에 푸시된 커밋을 rebase로 변경하면 히스토리가 재작성되어 다른 팀원들에게 혼란을 줄 수 있습니다.
히스토리 재작성 위험: rebase는 기존 커밋의 해시를 변경하기 때문에, 다른 사람이 해당 커밋을 기반으로 작업 중이라면 충돌이 발생할 수 있습니다.
로컬 브랜치에서만 사용: 로컬에서 작업 중인 브랜치를 업데이트하거나 커밋을 정리할 때 rebase를 사용합니다.
예: git pull --rebase로 최신 변경 사항을 가져옵니다.
공유 전 커밋 정리: 원격 저장소에 푸시하기 전에 rebase를 통해 커밋 메시지를 수정하거나 커밋을 합칠 수 있습니다.
팀 내 규칙 설정: 팀원들과 rebase 사용에 대한 가이드라인을 정해 혼란을 최소화합니다.
안전성: merge는 히스토리를 재작성하지 않으므로 협업 시 안전하게 사용할 수 있습니다.
명확한 기록: 병합 커밋이 생성되어 어떤 브랜치가 병합되었는지 명확하게 알 수 있습니다.
협업 환경에서 rebase는 신중하게 사용하면 유용한 도구입니다. 하지만 히스토리 재작성으로 인한 문제를 방지하기 위한 방법은 다음과 같습니다.