Merge와 Rebase

[paiwhy]

📆 일자: 26년 9월 14일(금)

여러 명이 함께 개발할 때는 각자의 브랜치에서 작업한 내용을 하나로 합치는 과정이 필수적입니다. Git에서는 이를 위한 방법으로 merge와 rebase 두 가지를 제공하는데, 두 방식은 단순히 명령어만 다른 것이 아니라 결과로 남는 커밋 히스토리의 모양과 협업 시 발생할 수 있는 문제까지 다르게 만듭니다. 상황을 고려하지 않고 아무 방식이나 사용하면 히스토리가 지저분해지거나, 팀원 간 커밋 충돌 같은 예상치 못한 문제가 생길 수 있습니다. 이에 따라 이번 스터디에서는 merge와 rebase가 각각 어떻게 동작하는지 이해하고, 실제 협업 상황에서 어떤 기준으로 선택해야 하는지 알아보고자 합니다.

🤔오늘의 질문

1. Merge와 Rebase는 각각 어떻게 동작하며, 커밋 히스토리에는 어떤 차이를 남기나요?
2. 이미 원격 저장소에 push된 브랜치를 rebase하면 어떤 문제가 발생할 수 있으며, 그 이유는 무엇인가요?
3. 팀 프로젝트에서 merge와 rebase 중 어떤 방식을 선택해야 하며, GitHub의 Merge commit·Squash and merge·Rebase and merge는 각각 어떤 상황에 적합한가요?

[k9425mino]

1. Merge와 Rebase는 각각 어떻게 동작하며, 커밋 히스토리에는 어떤 차이를 남기나요?

Git에서 Merge와 Rebase는 서로 다른 브랜치의 변경 사항을 통합하는 방법이다. 차이는 기존 커밋의 분기 구조를 보존하느냐, 커밋을 새 기준 위에 다시 쌓느냐에 있다.

다음처럼 feature와 main이 갈라졌다고 가정해 보겠다.

A──B──C  main
   └──D──E  feature

[ Merge ] : 분기와 통합 기록을 보존

feature를 main에 병합한다.

git switch main
git merge feature

두 브랜치의 변경 사항을 합치는 병합 커밋 M이 만들어진다. M은 C와 E를 부모로 가진다.

A──B──C────M  main
   └──D──E─┘

• 기존 커밋과 커밋 ID가 유지된다.
• 브랜치가 갈라지고 합쳐진 구조가 기록된다.
• 단, 분기 없이 대상 브랜치가 앞서 있기만 하면 Fast-forward로 포인터만 이동할 수 있어 병합 커밋이 생기지 않는다.

[ Rebase ] : 새 기준 위에 커밋을 다시 생성

feature의 기준을 최신 main으로 옮긴다.

git switch feature
git rebase main

Git은 feature에만 있는 D, E의 변경 사항을 C 위에 순서대로 다시 적용한다.

A──B──C  main
      └──D'──E'  feature

• D, E 대신 새 커밋 D', E'이 만들어져 커밋 ID가 바뀐다.
• 이 예에서는 분기 없는 일직선 히스토리가 된다.
• main은 그대로이다. 이후 main에서 feature를 병합하면 Fast-forward로 이동할 수 있다.

함께 작업 중인 공유 브랜치는 Merge를, 아직 공유하지 않은 개인 커밋을 정리할 때는 Rebase를 쓰는 것이 무난하다. 이미 공유한 커밋을 Rebase하면 다른 사람의 히스토리와 어긋날 수 있으므로 팀과 조율해야 한다.

2. 이미 원격 저장소에 push된 브랜치를 rebase하면 어떤 문제가 발생할 수 있으며, 그 이유는 무엇인가요?

이미 원격에 push한 브랜치를 Rebase하면 다른 사람이 가진 커밋 히스토리와 어긋날 수 있다. Rebase가 기존 커밋을 이동하는 대신, 새로운 ID를 가진 커밋으로 다시 만들기 때문이다.

예를 들어 원격의 D─E를 Rebase하면 다음과 같이 달라진다.

원격 및 동료: A─B─D─E
내 로컬: A─B─C─D'─E'

이때 발생할 수 있는 문제는 다음과 같다.

1. 일반 push가 거부된다: 새 히스토리가 원격의 기존 커밋 E를 포함하지 않아, Git은 기존 기록을 덮어쓰는 업데이트로 판단한다.
2. 강제 push로 동료의 작업을 덮어쓸 수 있다: 동료가 원격에 추가한 커밋을 확인하지 않고 git push --force하면 해당 커밋이 브랜치 기록에서 빠질 수 있다.
3. 동료가 히스토리 다시 맞춰야 한다: 기존 D, E 위에서 작업하던 동료는 새 D', E'를 기준으로 작업을 옮겨야 한다. 단순히 병합하면 같은 변경을 담은 커밋들이 중복으로 남거나 충돌이 발생할 수 있다.

따라서 다른 사람이 사용하는 브랜치는 Rebase 전에 조율해야 한다. 강제 push가 필요하면 --force-with-lease를 사용해 예상하지 못한 원격 변경을 덮어쓸 위험을 줄일 수 있지만, 동료의 히스토리가 어긋나는 문제까지 해결해 주지는 않는다.

3. 팀 프로젝트에서 merge와 rebase 중 어떤 방식을 선택해야 하며, GitHub의 Merge commit·Squash and merge·Rebase and merge는 각각 어떤 상황에 적합한가요?

팀 프로젝트에서는 공유 브랜치의 안정성과, 어떤 단위로 기록을 남길지를 기준으로 선택하면 된다. 개발 중 브랜치를 최신화 하는 방식과 GitHub에서 PR을 병합하는 방식은 별도로 정할 수 있다.

• 여러 사람이 함께 쓰는 브랜치: 기존 커밋을 보존하는 Merge가 무난하다.
• 혼자 작업하는 브랜치: 최신 main 위에 작업을 정리하려면 Rebase가 유용하다. 이미 push했다면 다른 사람이 그 커밋을 기반으로 작업 중인지 확인해야 한다.

예를 들어 개인 브랜치는 Rebase로 정리하고, PR은 Squash and merge로 통합하는 정책도 가능하다.

방식	기록 방식	추천 상황	고려할 점
Merge commit	기존 커밋 + 병합 기록	개별 커밋과 분기·통합 기록이 중요한 작업	작업 중 수정 커밋까지 남아 기록이 복잡해질 수 있음
Squash and merge	PR의 커밋을 하나로 합침	PR 하나가 기능·버그 수정 하나에 해당할 때	대상 브랜치에서는 PR 내부의 커밋 구분이 사라짐
Rebase and merge	개별 커밋을 일렬로 배치	각 커밋이 의미 있게 정리되어 있고 선형 기록을 원할 때	작업 중 임시 커밋도 그대로 반영되므로 사전 정리가 필요함

일반적인 작은 기능별 PR 중심의 팀이라면 다음을 기본안으로 추천한다.

• PR 병합은 Squash and merge: 기능 단위로 기록을 읽고 되돌리기 쉽다.
• 개별 커밋과 통합 이력 보존이 필요하면 Merge commit
• 각 커밋이 독립적이고 검증 가능한 팀이라면 Rebase and merge
• 공유 브랜치의 기존 기록을 바꾸는 Rebase·강제 push는 사전 조율

참고로 GitHub의 Rebase and merge는 대상 브랜치에 새 커밋을 추가하는 동작이다. 로컬에서 공유 브랜치를 Rebase한 뒤 강제 push하여 원격 기록을 덮어쓰는 경우와는 다르다. GitHub는 이 방식에서 커밋 SHA를 새로 생성한다.

핵심은 작업 과정 보존은 Merge commit, PR 단위 기록은 Squash, 개별 커밋을 유지한 선형 기록은 Rebase and merge이다.

[dnnals]

기본 질문

1. Merge와 Rebase는 각각 어떻게 동작하며, 커밋 히스토리에는 어떤 차이를 남기나요?

Merge와 Rebase는 모두 한 브랜치의 변경 사항을 다른 브랜치에 통합할 때 사용됩니다. 먼저 통합은 A에서 B로 통합한다면 A를 주로 source / feature / topic 브랜치라 하고 B를 target / base 브랜치라고 합니다. Merge는 통합 때, feature 브랜치의 변경사항이 base 브랜치에 통합되었다는 표시인 Merge Commit을 남겨 두 브랜치의 통합을 표시합니다. Rebase는 feature 브랜치가 시작된 위치를 base 브랜치의 끝 지점으로 옮겨 통합합니다. 이때 옮기는 행위를 기존 커밋들을 복사해 새로운 커밋으로 base 브랜치로 커밋합니다. Merge는 분기 가지를 유지한채 feature 브랜치에서의 변경사항을 통합한다는 표시 커밋만 base 브랜치에 남기기 때문에 히스토리에서 분기 가지가 보입니다. 반면에 Rebase는 feature 브랜치의 시작 지점을 base 브랜치로 옮겼기 때문에 분기 가지가 보이지 않습니다.

2. 이미 원격 저장소에 push된 브랜치를 rebase하면 어떤 문제가 발생할 수 있으며, 그 이유는 무엇인가요?

push된 브랜치를 Rebase하면 원격과 로컬의 브랜치 충돌이 일어날 수 있습니다. 이미 원격 저장소에 push된 브랜치를 Rebase하면 문제가 발생하는 이유는 Rebase가 기존의 커밋을 복사해 새로운 커밋을 만들어 기준 브랜치 끝에 새로 커밋한다는 특성 때문입니다. 이를 구체적인 예시를 들어 설명하겠습니다. 먼저 본인이 feature 브랜치를 push 하고 동료가 그 브랜치를 pull 했다면 나, 원격, 동료가 모두 feature 브랜치의 커밋 A, B를 모두 함께 가집니다. 그런데 여기서 feature 브랜치를 특정 브랜치로 Rebase 한다면 A, B 커밋이 A’, B’으로 완전히 다른 커밋으로 base 브랜치 줄기 끝에 만들어집니다. 이렇게 되면 원격에선 feature 브랜치는 A, B를 가지고 내 로컬의 feature는 A’, B’을 가집니다. 이때 또 원격으로 feature를 push를 한다면 원격에선 A, B가 없는 push를 거절합니다.

3. 팀 프로젝트에서 merge와 rebase 중 어떤 방식을 선택해야 하며, GitHub의 Merge commit·Squash and merge·Rebase and merge는 각각 어떤 상황에 적합한가요?

merge, rebase는 둘 중 하나가 정답이다로 정해져 있지 않고 취향의 영역으로 많이 갈립니다. 두 통합 방식의 차이는 분기를 남기느냐 남기지 않느냐이고 분기를 남겨서 우리의 작업 히스토리를 시각적으로 남기고 싶다면 merge, 분기를 남기지 않고 현재 최신 상태를 일직선으로 깔끔하게 관리하고 싶다면 rebase를 선택해서 사용합니다. Github의 Merge Commit, Squash and Merge, Rebase and Merge가 어떤 상황에 적합한지 말하기전 새로운 개념인 Squash에 대해 설명하면 이는 여러 커밋을 하나로 압축해 기록하는 것입니다. 그래서 Merge Commit과 Rebase and Merge는 앞서 말했듯이 취향의 영역이라면 Squash and Merge는 주로 자질구레한 커밋이 많이 섞여 커밋 기록이 지저분 하다면 압축해서 하나의 커밋으로 기록하는 상황에 유용합니다.

[eunji719]

1. Merge와 Rebase는 각각 어떻게 동작하며, 커밋 히스토리에는 어떤 차이를 남기나요?

Merge는 두 브랜치의 변경사항을 합치면서 새로운 병합 커밋을 만든다. 기존 커밋들은 그대로 유지된 채, 새로운 커밋이 하나 추가되는 방식이다. 히스토리를 보면 브랜치가 갈라졌다가 다시 합쳐지는 분기가 그대로 남아서, 실제 작업 흐름과 시점을 정확히 알 수 있다. 그치만 브랜치가 많아지면 히스토리가 복잡해질 수도 있다.

Rebase는 이름 처럼 base를 다시 설정한다라고 생각하면 편하다. 내가 작업하고 있던 브랜치를 떼어내서 대상 브랜치의 최신 커밋 뒤에 하나씩 다시 적용하는 방식이다. 브랜치가 애초에 최신 main에서 시작한 것처럼 커밋들을 재작성한다. 이렇게 하면 히스토리가 갈라짐 없이 일직선으로 깔끔하게 정리되지만, 커밋들이 새로 생성되는 것이므로 커밋 해시가 전부 바뀌게 된다.

2. 이미 원격 저장소에 push된 브랜치를 rebase하면 어떤 문제가 발생할 수 있으며, 그 이유는 무엇인가요?

Rebase는 커밋을 재작성하는 작업이라 커밋 해시가 모두 바뀐다. 문제는 원격 저장소에는 이미 이전 커밋 히스토리가 올라가 있다. 내가 로컬에서 rebase를 하면 내용은 같더라도 로컬 히스토리와 원격 히스토리가 서로 다른 커밋으로 갈라지게 된다. 이 상태에서 그냥 push를 하면 원격과 로컬 히스토리가 안 맞아서 거부되고, 강제로 올리려면 --force 를 써야 하는데, 이는 원격에 있던 기존 커밋들을 다 덮어써 버린다. 만약 다른 팀원이 그 사이에 원격 브랜치를 pull받아서 작업을 이어갔다면, 그 팀원의 히스토리는 사라진 옛날 커밋을 기준으로 작업 하는 상태가 된다. 이후 그 팀원이 push를 시도하면 이상한 충돌이 발생하거나 강제 push로 인해서 다른 팀원의 작업 내용이 유실될 수 있다. 그래서 이미 push된 히스토리는 rebase하지 않는게 정설이다.

3. 팀 프로젝트에서 merge와 rebase 중 어떤 방식을 선택해야 하며, GitHub의 Merge commit·Squash and merge·Rebase and merge는 각각 어떤 상황에 적합한가요?

main브랜치나 develop브랜치 같은 공유 브랜치에 다른 사람의 작업을 반영할 떄는 merge를 사용하는 것이 안전하다. 이미 여러 사람이 보고 있는 히스토리를 재작성하면 안되기 떄문이다. 내 개인의 아직 아무도 안 본, push도 안한 feature브랜치를 최신 main과 동기화하고 싶을 때는 rebase로 깔끔하게정리한 뒤 PR을 올리는 방식이 권장된다.

깃허브에서 PR병합 방식은 3가지가 있다.

1. Merge Commit: PR의 모든 커밋을 그대로 유지하면서 병합 커밋 하나를 추가한다. 브랜치 작업 흐름과 세부 커밋 이력을 그대로 보존하고 싶을 때, 특히 릴리즈 히스토리를 명확히 남기고 싶은 경우에 적합하다.
2. Squash and merge: PR안의 여러 커밋을 하나로 합쳐서 main에 커밋 한개로 추가한다. feature 브랜치 안에서 오타 수정, 테스트 추가 같은 자잘한 커밋이 많을 때, main히스토리를 기능 단위로 깔끔하게 유지하고 싶은 경우에 적합하다. 대부분 실무에서 쓰이는 가장 무난한 방식이다.
3. Rebase and merge: PR의 커밋들을 병합 커밋 없이 main뒤에 그대로 이어 붙인다. 각 커밋을 개별적으로 보존하면서도 일직선 히스토리를 원할 때 적합하지만, 이미 다른 사람이 참조 중인 커밋의 해시가 바뀌기 때문에 주의가 필요

[9ga0]

1. Merge와 Rebase는 각각 어떻게 동작하며, 커밋 히스토리에는 어떤 차이를 남기나요?

merge와 rebase는 모두 서로 다른 브랜치의 작업을 합치는 방법이지만, 커밋 기록을 처리하는 방식이 다릅니다.

merge는 두 브랜치의 기존 커밋을 그대로 유지하면서 하나로 합칩니다. 필요한 경우 두 작업을 합쳤다는 새로운 merge commit이 생성됩니다. 실제 브랜치 작업 흐름이 남는다는 특징이 있습니다.

A—B—C  main
    \
     D—E  feature

merge 후

A—B—C————M  main   (M은 merge commit)
    \     /
     D———E

rebase는 현재 브랜치의 시작점을 다른 브랜치의 최신 커밋 뒤로 옮깁니다.

A—B—C  main
    \
     D—E  feature

rebase 후

A—B—C—D'—E'  feature

기존 D, E를 그대로 이동하는 것이 아니라, 변경 내용을 다시 적용하여 D', E'라는 새로운 커밋을 만듭니다. 커밋 기록이 한 줄로 정리되며, 잘못 사용하면 다른 팀원의 작업에 영향을 줄 수 있다는 특징을 가집니다.

2. 이미 원격 저장소에 push된 브랜치를 rebase하면 어떤 문제가 발생할 수 있으며, 그 이유는 무엇인가요?

Git 커밋의 해시는 변경 내용만으로 결정되지 않습니다. 작성자, 시간, 커밋 메시지, 이전 커밋인 부모 커밋 등의 정보도 영향을 줍니다. 따라서 rebase로 부모 커밋이 달라지면 코드 내용이 같더라도 새로운 해시를 가진 커밋이 생성됩니다.

원격 저장소: A—B—D—E
로컬 rebase: A—B—C—D'—E'

따라서 원격저장소에 이를 올리려면 강제 push가 필요할 수 있습니다.

git push --force-with-lease //다른 사람의 새로운 커밋을 확인하는 --force-with-lease

그런데 만약 다른 팀원이 기존 커밋을 내려받아 작업하고 있었다면, 원격 히스토리가 변경되면서 커밋 중복이나 충돌이 발생하고 팀원의 작업을 덮어쓸 위험도 있습니다. 따라서 여러 사람이 공유하는 main이나 develop 브랜치는 rebase하지 않는 것이 안전합니다. Rebase는 아직 공유하지 않은 개인 브랜치에서 사용하는 것이 좋습니다.

3. 팀 프로젝트에서 merge와 rebase 중 어떤 방식을 선택해야 하며, GitHub의 Merge commit·Squash and merge·Rebase and merge는 각각 어떤 상황에 적합한가요?

팀의 협업 방식과 원하는 히스토리에 따라 선택해야 합니다.

일반적인 선택 기준

상황	적합한 방식
공유 브랜치의 기록을 안전하게 보존	Merge
개인 브랜치를 최신 main 위로 정리	Rebase
작업 과정과 브랜치 단위를 남기고 싶음	Merge commit
PR의 여러 커밋을 하나로 정리하고 싶음	Squash and merge
각각의 커밋을 보존하면서 선형 히스토리 유지	Rebase and merge

팀 프로젝트에서는 다음과 같은 규칙을 사용할 수 있습니다.

• main과 develop 같은 공유 브랜치는 rebase하지 않는다.
• 개인 feature 브랜치는 push하기 전이나 혼자 사용할 때 rebase할 수 있다.
• Pull Request를 합치는 방식은 팀 전체가 하나로 통일한다.

GitHub의 세 가지 병합 방법

1. Merge commit은 실제 작업 흐름과 모든 커밋을 보존해야 할 때 적합합니다. 다만 PR이 많아지면 히스토리가 복잡해질 수 있습니다.

A—B—C————M
    \     /
     D———E

4. Squash and merge는 PR의 여러 커밋을 하나로 합치는 방식입니다. 개발 중 생긴 불필요한 커밋을 제거하고, 하나의 기능을 하나의 커밋으로 관리하고 싶을 때 적합합니다.

feature: D—E—F

병합 후: A—B—C—S //S하나에 D,E,F 최종 변경 사항이 들어감.

5. Rebase and merge는 PR의 개별 커밋을 유지하면서 최신 main 뒤에 순서대로 다시 적용하는 방식입니다. merge commit 없이 선형 히스토리를 만들 수 있지만, PR의 커밋들이 의미 있는 단위로 잘 정리되어 있을 때 사용하는 것이 좋습니다.

병합 전

A—B—C  main
    \
     D—E  feature

병합 후

A—B—C—D'—E'  main

---

요약

Merge는 기존 커밋을 유지하면서 브랜치를 합치고, rebase는 커밋을 최신 브랜치 뒤에 다시 적용합니다. 따라서 merge는 실제 작업 흐름이 남고, rebase는 한 줄로 된 깔끔한 히스토리를 만들지만 커밋 해시가 변경됩니다.

이미 push한 브랜치를 rebase하면 기존 커밋의 해시가 변경되어 원격 저장소와 기록이 달라집니다. 강제 push 과정에서 다른 팀원의 커밋을 덮어쓰거나 충돌을 만들 수 있으므로 공유 브랜치는 rebase하지 않는 것이 안전합니다.

Merge commit은 작업 흐름 보존, Squash and merge는 여러 커밋을 하나의 기능 단위로 정리, Rebase and merge는 개별 커밋을 유지하면서 선형 히스토리를 만들 때 적합합니다. 팀 프로젝트에서는 팀원들과 병합 규칙을 미리 통일하는 것이 가장 중요합니다.

[paiwhy]

1. Merge와 Rebase는 각각 어떻게 동작하며, 커밋 히스토리에는 어떤 차이를 남기나요?

→ merge는 두 브랜치를 합치는 새 브랜치를 만듭니다. 원본의 커밋들이 그대로 보존되고 히스토리가 갈라졌다 합쳐지는 그래프 형태로 남아있습니다.
rebase는 브랜티의 커밋들을 다른 브랜치 끝에 하나씩 적용해 새로운 커밋으로 다시 작성합니다 그렇게 히스토리는 linear가 되고 머지 커밋이 되지 않습니다.

2. 이미 원격 저장소에 push된 브랜치를 rebase하면 어떤 문제가 발생할 수 있으며, 그 이유는 무엇인가요?

→ 이미 원격 저장소에 push 된 브랜치를 pull하고 rebase하게 되면 로컬 히스토리와 원격의 히스토리가 갈라지기에 문제가 발생합니다 그 이유는 rebase는커밋 해시를 바꾸기 때문입니다
다른 사람 로컬에서 예전 커밋이 남아있는 채로 원격이 새 커밋으로 바뀌기 때문에 pull했을때 중복이 생기거나 충돌이 생기게 됩니다
커밋을 맞추려면 강제로 push 해야 하고 다른 사람 작업이 덮어쓰여질 수 있기에 강제로 push하는게 옳다고 할수 없기에 이미 공유된 히스토리는 reabase하지 않아야 합니다

3. 팀 프로젝트에서 merge와 rebase 중 어떤 방식을 선택해야 하며, GitHub의 Merge commit·Squash and merge·Rebase and merge는 각각 어떤 상황에 적합한가요?

→ 보통 혼자만 보는 로컬 브랜치는 rebase로 정리하고 이미 팀원이 같이 쓰는 공유 브랜치는 merge를 씁니다.
rebase는 해시를 바꾸기 때문에 공유 브랜치에서 쓰면 팀원들의 작업이 꼬일 수 있습니다
Merge commit은 모든 커밋과 브랜치 흐름을 그대로 남깁니다. 히스토리 점검이 중요한 오픈소스나 릴리스 관리에 적합합니다.
Squash and merge는 PR의 모든 커밋을 하나로 합쳐서 main을 깔끔하게 유지합니다. 커밋 메시지가 많거나 정리되지 않은 사람들이 기본으로 많이 씁니다.
Rebase and merge는 커밋 단위는 보존하면서 merge commit 없이 linear history로 만들어씁니다. 커밋이 이미 잘 정리되어 있을때 사용하기에 적합합니다.
보통 Squash and merge를 기본으로 두고 필요할 때 나머지 두 개를 씁니다.

[JM-220]

1. Merge와 Rebase는 각각 어떻게 동작하며, 커밋 히스토리에는 어떤 차이를 남기나요?
   merge 는 분기된 브랜치에서 추가로 커밋을 만들어 병합 했다는 것을 알 수 있다. 두 히스토리의 분기 그래프는 유지되고, 서로 다른 브랜치가 분기되어서 다시 병합되는 과정을 보존한다. rebase 는 merge 와 다르게, 분기된 브랜치의 가지를 꺾어다가 원하는 가지에 붙인다. 분기 기록이 사라지고 가지를 이어 붙인 기록도 없다. 하지만 꺾었던 가지 히스토리는 확실히 다른 커밋이므로(자연스럽게 이어지는 것처럼 보이게 할 수는 있는데 커밋 로그도 같을 수는 없음) 커밋로그가 변경되어 새로운 커밋이 올라가는 방식이다. 그래프는 분기와 병합 과정이 보이지 않게된다.
2. 이미 원격 저장소에 push된 브랜치를 rebase하면 어떤 문제가 발생할 수 있으며, 그 이유는 무엇인가요?
   1번에서 말했던 것처럼 커밋 내용이 같더라도 rebase를 하면 커밋로그가 바뀐다. 원격에 있는 브랜치와 다른 커밋로그를 가진 브랜치를 원격에 push하면(일단 막히긴 하는데 강제 push 를 하면) 내 로컬과 원격이 같아져도 몇명일지 모르는 팀원들의 로컬과 원격은 달라진다. 여기에 팀원들이 작업내용을 push 하면 어떻게 될까? 막힌다. 당연히 그렇다.
3. 팀 프로젝트에서 merge와 rebase 중 어떤 방식을 선택해야 하며, GitHub의 Merge commit·Squash and merge·Rebase and merge는 각각 어떤 상황에 적합한가요?
   2번에서 언급한 문제 때문에 merge를 선택하는 것이 맞다. 문제에서 rebase and merge 가 있는데 그럼 이건 뭐냐? 라고 묻는다면 살짝 다르다. 공유 브랜치를 rebase 하는 게 아니라 rebase 방식으로 작업 브랜치를 공유 브랜치에 옮기는 작업이기 때문이다. 따라서 선형 그래프로 히스토리가 찍히고 fast foward 방식이 가능하다. merge commit 은 분기된 브랜치 하위의 모든 작업 커밋을 그대로 병합하는 방식이다. 모든 커밋 히스토리가 남아서, merge 작업이 많으면 히스토리가 복잡해질 수 있다. squash and merge는 작업 내용을 하나의 merge commit 으로 만들어서 간단하게 만들어 병합하는 것이다. 히스토리가 간단해진다. 버그를 수정했는데 또 버그가 생기고 수정하고 버그가 생기고 이렇게 계속한 적이 있을텐데, 이 방식을 사용하면 여러 커밋을 하나로 만들어 (~ bug fix 뭐 이런 식으로) 하나의 커밋으로 만들어 버릴 수 있다.