코드잇 스프링백엔드 11기 1주차 위클리 페이퍼 #1
내용 정리 및 개인 학습 기록입니다.
Q1. git rebase와 git merge의 차이점을 설명, 각각 어떤 상황에서 사용하는 것이 적절한지 설명.
Q2. git fetch와 git pull의 차이점을 설명, 각각을 사용하는 것이 적절한 상황을 설명.
2026년 2월 5일, 코드잇 스프링 백엔드 코스의 첫걸음은 git과 함께 시작되었다. Java를 이제 막 접하기 시작한 나에게 git은 처음엔 차가운 텍스트뿐인 화면이었지만, 공부를 거듭할수록 그 속에서 '텍스트로 이루어진 정교한 그림'을 발견하고 있다.
//내가 느낀 git: 개발자들의 인스타그램"
처음 본 git은 아무 그림도 없는 검은화면 속의 CLI 였지만, Weekly Log를 작성하며 생각이 바뀌었다.
//연결의 미학: 각자의 코드가 자신만의 방식으로 연결되고 생명력을 얻는 과정이 놀라웠다.
//오픈 소스의 힘: 타임의 코드를 참조하고, PR(Pull Reques)을 통해 기존 코드에 새로운 생명을 불어넣는 모습은 마치 개발자들만의 SNS인 인스타그램처럼 느껴졌다.
// 주요 학습내용: CLI와 원격 저장소
검은 화면에 직접 명령어를 입력하는 git bash를 통해 gitHub와 연결되는 과정을 보며 CLI의 위대함을 새삼 체감했다. 협업을 위한 원격 저장소 활용의 핵심 질문 Q1,Q2을 다음과 같이 정리해본다.
About Q1. 'git rebase' and 'git merge'. How diffurent each other.
git에서 브랜치를 합칠때, 우리는 '기록을 보존할 것인가' 아니면 '기록을 한줄로 예쁘게 펼칠 것인가'에 따라 두가지 선택지를 가진다.
1) git merge: "두 갈래의 역사를 그대로 보존하기"
가장 일반적인 방법으로, 두 브랜치의 마지막 커밋드롸 공통 조상을 찾아 3-way merge 를 수행한다.
동작: 두 뿌리를 하나로 묶는 새로운 'merge commit'을 생성한다.
예시:
// feature 브랜치에서 작업이 끝나고 main에 합칠 때 사용한다.
bash
git checkout main
git merge feaure
결과: 히스토리에 브랜치가 갈라졌다가 다시 합쳐지는 '나뭇가지'모양이 남는다. 언제 어떤 기능을 합쳤는지 기록이 명확히 남는다는 장점이 있다.
2) git rebase: "역사를 다시 써서 한줄로 만들기"
브랜치에서 변경딘 사항을 patch형대로 만든 뒤, 이를 대상 브랜치의 최신 커밋 위에 차례대로 적용한다.
동작: 내 커밋들의 기준점(Base)을 다른 브랜치의 끝으로 옮긴다.(Re-Base)
예시 :
// 내 작업 중에 main에 새로운 업데이트가 생겼을 때, 내 작업이 마치 방금 시작된 것처럼 위치를 바꾼다.
bash
git checkout feature
git rebase main
결과: 히스토리가 갈라진 적 없는 것처럼 일직선으로 바뀐다. 마치 처음부터 main의 최신 상태에서 작업을 시작한 것처럼 보여 가독성이 매우 좋아진다.
요약: 언제 무엇을 쓸까?
git merge: 여러명이 공유하는 공용 브랜치(main)에 작업 결과를 합칠 때 사용한다. "누가, 언제 병합했는지" 라는 정보가 중요할때 유리하다.
git rebase: 내 로컬 작업물을 깔끔하게 유지하고 싶을 때 사용한다. 커밋 히스토리에 불필요한 'merge commit'노이즈를 줄여 프로젝트 전체를 한눈에 파악하기 쉽게 만든다.
- "rebase는 히스토리에 깔끔하게 관리할 수 있지만, 이미 서버에 공유된 커밋에 사용하면 동료들에게 혼란을 야기할수 있다." *
About Q2. git fetch and git pull. How diffurent those things?
" git fetch vs git pull : 원격의 소식을 듣는 두가지 태도 "
1) git fech(확인 후 선택)
"일단 소식만 들어볼게."
동작: 원격 저장소의 최신 이력을 로컬의 '원격 추적 브랜치(origin/main 등)'로 가져오지만, 내 작업물에 직접 합치지는 않는다.
예시:
//신중함이 필요할 때-
팀원들이 어떤 코드를 올렸는지 내 코드에 반영하기 전, git log나 git diff로 미리 검토하고 싶을때 사용한다.
//충돌이 예상될 때-
내가 수정한 파일과 원격의 파일이 겹칠 것 같아, 미리 변경 사항을 파악하고 대비하고 싶을 때 좋다.
//오프라인 작업 준비 -
일단 최신 상태만 받아두고, 나중에 인터넷이 안되는 곳에서 천천히 병합하고 싶을 때 유용하다.
2) git pull(신뢰와 속도)
"믿고 바로 합칠게!"
동작: fetch로 가져온 뒷 즉시 내 현재 브랜치에 merge한다. (작업 중인 파일이 바로 바뀐다.)
예시:
//단순 업데이트-
내가 건드리지 않은 부분의 코드나, 단순한 기능 추가 등 충돌 가능성이 낮은 변경 사항을 빠르게 반영할 때 사용한다.
// 협업의 시작-
아침에 출근해서(혹은 공부를 시작하며) 다른 사람들의 작업물을 내 로컬에 깔끔하게 맞추고 시작하고 싶을 때 가장 먼저 실행한다.
//작업 흐름이 명확할 때-
현재 내가 수정 중인 파일이 원격의 내용과 겹치지 않는다는 확신이 있을 때 시간을 절약해 준다.
강의 노트에서 언급된 'fecth-> 확인 -> merge' 전략은 마치 "낯선 사람이 문을 두드릴 때, 누구인지 확인하고 문을 열어주는 것"과 같다.
반면 pull은 "그냥 문을 활짝 열어두는 것"으로 비교할수 있다.
"============= 추천하는 루틴으로는============="
git fetch로 소식을 받고, git log --online main.origin/main 같은 명령어로 어떤 커밋들이 왔는지 훑어본뒤, 문제가 없어 보이면 git merge origin/main으로 합친다.
이렇게 하면 예상치 못한 충돌(Conflict)때문에 당황하는 일을 크게 줄일 수 있다. CLI의 매력은 이처럼 내가 모든 과정을 통제할수 있다는 점이 큰것 같다.
// 마무리 하며.. 도구의 이해가 만드는 협업의 예술
저번 주, git이라는 낯선 텍스트의 세계에 발을 들여놓으며 깨달은 것은 단순한 명령어를 외우는 것보다 '흐름을 통제하는 즐거움'이 크다는 점이다.
-기록의 보존과 정돈, 상황에 따라 merge로 역사를 증명하거나, rebase로 가독성을 챙기는 유연함
-신중함과 효율, fetch로 변화를 관찰하고, pull로 빠르게 동기화하며 팀원과 보폭을 맞추는 법
처음에는 아무 그림도 없는 검은 화면이었던 git bash가,
이제는 전 세계 개발자들과 소통하고 내 코드를 더 가치 있게 만들어줄 강력한 캔버스로 보이기 시작한다.
Java와 Spring이라는 거대한 산을 오르기 전, 든든한 장비를 갖춘 기분이다.
아직은 서툴고 충돌(Confilict)이 두렵기도 하지만, 이 텍스트 그림들을 하나씩 완성해 나가며 '함께 성장하는 개발자"로 거듭나고 싶다.
