좋은 질문이에요 
feature 브랜치에서 원격의 develop 브랜치를 가져올 때 pull과 rebase는 둘 다 최신 코드를 반영하는 방법이지만, 커밋 히스토리 관리 방식에서 차이가 있습니다.
feature 브랜치에서 원격의 develop 브랜치를 가져올 때 pull과 rebase는 둘 다 최신 코드를 반영하는 방법이지만, 커밋 히스토리 관리 방식에서 차이가 있습니다.1.
git pull develop (merge 방식)
기본적으로 pull은 fetch + merge 입니다.
git checkout feature
git pull origin develop
작동 방식
1.
원격 develop의 최신 커밋들을 가져옴 (fetch)
2.
feature 브랜치와 merge commit을 생성하여 병합
결과
feature 브랜치에 Merge branch 'develop' into feature 같은 머지 커밋이 추가됨
히스토리가 분기 → 다시 합쳐지는 그래프 형태
충돌이 있으면 merge conflict 해결 후 머지
장점
히스토리 보존 (어떤 시점에 develop을 합쳤는지 명확)
협업 시 흔히 쓰임
단점
불필요한 merge commit이 많이 쌓여 히스토리가 지저분해질 수 있음
1.
git pull --rebase develop (rebase 방식)
rebase는 feature 브랜치의 작업을 develop 최신 커밋 위로 다시 쌓는 것입니다.
git checkout feature
git pull --rebase origin develop
작동 방식
1.
feature 브랜치에서 한 커밋들을 잠시 저장
2.
feature 브랜치를 develop 최신으로 이동
3.
저장해둔 feature 커밋들을 develop 위에 순서대로 재적용
결과
merge commit 없음
feature 브랜치가 develop 최신에서 직선으로 이어진 깔끔한 히스토리
충돌이 있으면 각 커밋을 적용할 때마다 해결해야 함
장점
히스토리가 깔끔 (linear history)
git log, git bisect 분석하기 편리
단점
커밋 해시가 전부 새로 만들어짐 (이미 원격에 push한 브랜치를 rebase하면 협업자들에게 혼란 유발 가능)
충돌이 많을 경우, merge보다 번거로움
1.
언제 어떤 걸 쓰면 좋은가?
merge (pull) 추천
여러 사람이 같은 feature 브랜치를 공유할 때
히스토리 변경을 최소화하고 싶을 때
rebase (pull --rebase) 추천
개인 feature 브랜치에서 작업 후 PR 올리기 전에 최신 develop 반영할 때
히스토리를 직선으로 깔끔하게 유지하고 싶을 때
정리하면,pull (merge) → 충돌 해결 한 번에 끝, 머지 커밋 생김
pull --rebase → 히스토리 깔끔, 대신 커밋 해시가 바뀌므로 협업 시 주의
