[SB 3기] 코드잇 스프린트 위클리페이퍼 1주차

[SB 3기] 코드잇 스프린트 위클리페이퍼 1주차

Q. git rebase와 git merge의 차이점을 설명하고, 각각 어떤 상황에서 사용하는 것이 적절한지 설명해주세요

1. merge/rebase 개념

• git merge
  • 두 개 이상의 브랜치를 통합할 때 사용
  • 대상 브랜치(예: feature)를 현재 브랜치(예: main)에 병합하며, 병합 커밋(merge commit) 생성
  • 기존 커밋 히스토리는 그대로 유지
• git rebase
  • 한 브랜치의 Base Commit을 다른 브랜치의 최신 커밋 뒤로 재설정(reapply)
  • 커밋 히스토리를 직렬화하여, 마치 한 줄기에서 작업한 것처럼 깔끔하게 정리
  • 실행 후에는 변경된 커밋 히스토리를 원격에 반영하기 위해 강제 push(push --force)가 필요
  • 참고사이트 : https://tlatmsrud.tistory.com/156

2. 차이점

기능	git merge	git rebase
커밋 히스토리	기존 커밋을 유지하며 새로운 병합 커밋(merge commit)을 생성	기존 커밋을 재배치하여 히스토리를 깔끔하게 정리
커밋 ID	원본 커밋 ID 유지	재배치 과정에서 새로운 해시 ID 부여
히스토리 가독성	여러 브랜치가 합쳐지면서 복잡해질 수 있음	마치 한 줄기에서 작업한 것처럼 정리됨
충돌 발생 시점	병합 시점	재배치 시점
대표적인 사용 상황	협업 프로젝트에서 명확한 변경 이력을 남길 때	로컬 브랜치에서 깔끔한 커밋 정리가 필요할 때

3. 사용 적절한 상황

• ✅ git merge
  • 프로젝트의 모든 변경 이력을 보존해야 하는 경우
    → 협업 프로젝트에서는 브랜치가 어떻게 병합되었는지 정확한 기록을 남기는 것이 중요하기 때문에 merge를 사용하면 좋음.
  • 업스트림(upstream)이 없는 원격(origin) 저장소에서 작업하는 경우
    → 단일 원격 저장소 환경에서는 merge를 통해 변경 사항을 통합하는 것이 일반적임.
  • 형상 관리가 중요한 프로젝트
    → 여러 사람이 작업한 브랜치를 병합할 때 merge commit이 남으면, 나중에 git log를 보며 변경 사항을 추적하기 쉬움. 여러 개발자가 작업한 기록을 그대로 남기므로, 누가 어떤 변경을 했는지 명확하게 확인할 수 있다.
• ✅ git rebase
  • 개인(feature) 브랜치에서 불필요한 커밋을 정리하거나 순서를 재배치할 때
  • 로컬에서 혼자 작업한 커밋 히스토리를 정리할 때
  • fork해 온 프로젝트를 upstream 최신 상태로 깔끔히 동기화할 때
    → fetch upstream으로 최신 정보를 가져온 뒤 rebase를 실행하면, 마치 원래부터 최신 상태에서 작업한 것처럼 정리됨. 원본 저장소의 최신 변경 사항을 내 로컬 작업에 깔끔하게 반영
  • fast-forward merge를 가능하게 하고 싶을 때
    → feature 브랜치를 master 브랜치의 최신 상태로 업데이트하고 싶다면, rebase를 사용하여 마치 한 줄기에서 개발한 것처럼 만들 수 있음.

4. 주의사항

• 공유된 브랜치에서 rebase 사용 주의
  → 이미 다른 사람과 공유한 브랜치에서 rebase를 사용하면 커밋 히스토리가 변경되어 충돌이나 혼란 발생 가능성이 있음.
• main/master 브랜치에서 직접 rebase 피하기
  • master(또는 main) 브랜치는 안정적인 이력을 유지해야 함.
    → feature 브랜치에서만 rebase를 수행하고, master에서는 merge를 사용하는 것이 일반적임.

5. 결론

• 협업 프로젝트 -> git merge가 기본! (git log에서 히스토리를 추적하기 좋음)
  • 전체 변경 이력을 추적하고 기록을 남기는데 유리하다.
• 개인 로컬 브랜치 정리 -> git rebase를 활용하여 깔끔한 커밋 히스토리 유지!
  • 개인 작업 시 커밋 정리와 최신 코드 반영에 효과적이다.
• 업스트림(upstream) 동기화할 때는 rebase가 유용!
  • fork한 저장소에서 원본의 최신 내용을 깔끔하게 반영할 수 있다.
• master에서 rebase하는 것은 피해야 함. (충돌 가능성 높음)
  • 충돌 및 이력 변경 문제로 인해 협업에 불리할 수 있다.
• 참고
  • Upstream이란?
    • upstream은 내가 작업하는 저장소보다 상위에 있는 원격 저장소를 의미하며, 보통 프로젝트의 원본 저장소이다.
    • 내가 fork해온 원본 저장소 = upstream
    • 내가 clone해서 작업하는 개인 원격 저장소 = origin
    • 즉, upstream은 원본, origin은 내 작업 공간이라고 보면 된다.

---

Q. git fetch와 git pull의 차이점을 설명하고, 각각을 사용하는 것이 적절한 상황을 설명해주세요

1. fetch/pull 개념

• git fetch
  • 원격 저장소에서 최신 커밋(및 메타데이터)을 로컬 저장소의 임시 브랜치(FETCH_HEAD 등)로 가져옴.
  • 자동 병합을 하지 않으므로, 로컬 브랜치에는 바로 영향이 가지 않는다.
  • 가져온 변경 사항을 확인한 후, 필요에 따라 수동으로 병합(예: git merge)하거나 검토할 수 있다.
  • 참고 사이트 : https://krrong.tistory.com/289
• git pull
  • 원격 저장소의 최신 커밋들을 로컬로 가져오고, 자동으로 현재 작업 중인 브랜치와 병합(merge)까지 진행
  • 즉, git fetch + git merge를 한 번에 실행하는 명령어
  • 병합 과정에서 충돌이 발생할 수 있으며, 병합 커밋이 생성될 수 있다.

2. 사용 적절한 상황

• ✅ git fetch
  • 변경 사항을 먼저 확인하고 싶을 때
    → 원격 저장소의 최신 커밋이나 태그가 무엇인지, 어떤 변경이 있었는지를 검토하고 싶은 경우
  • 로컬 브랜치에 직접적인 변경을 주고 싶지 않을 때
    → 수동으로 병합 여부를 결정하거나, 충돌 가능성을 미리 파악하고 싶을 때
  • 원격과 로컬 저장소의 상태를 비교할 때
    → git diff origin/main과 같은 명령어를 사용하여 어떤 변경 사항이 있는지 확인한 후, 안전하게 병합할 수 있음.
• ✅ git pull
  • 원격 저장소의 최신 상태를 로컬 브랜치에 바로 반영하고 싶을 때
    → 현재 작업 중인 브랜치에 원격의 변경 사항을 즉시 통합해야 할 때
  • 자동 병합을 통해 빠르게 업데이트하고자 할 때
    → 별도의 검토 없이 로컬 브랜치를 최신 상태로 유지할 필요가 있는 경우
  • 간단한 협업 환경에서
    → 충돌 가능성이 낮고, 신속하게 업데이트가 필요한 상황이라면 편리하게 사용할 수 있음.

3. 결론

• 핵심 차이점:
  • git fetch는 원격 저장소의 최신 정보를 가져오되, 병합하지 않고 단순히 업데이트 내용을 확인하는 용도로 사용한다.
  • git pull은 원격 저장소의 변경 사항을 가져온 후, 자동으로 로컬 브랜치에 병합하여 업데이트한다.
• 사용 추천:
  • 검토와 비교가 필요한 경우 → git fetch
  • 즉각적인 업데이트가 필요하고, 병합 커밋 생성에 문제가 없을 경우 → git pull