20260107 [WIL] 왜 Git을 배우는데 머리가 아플까

 

git 강의를 다 들어도 전혀 와닿지 않는 이유......
명령어는 대충 뭔지 알겠는데 흐름이 전혀 보이지 않는다. 내가 이해력이 딸리는 것도 맞는데, 구조가 전혀 없는 상태에서 용어들만 다 쑤셔 넣으려고 하니 헷갈리고 모르겠다. 그래서 대충 흐름만 정리하는 용도로 글을 써 보려고 한다.

---

🎯 가정: 우리는 커뮤니티 사이트를 만든다

• 회원가입 / 로그인
• 글쓰기
• 댓글쓰기
• 추천 / 비추천
• 마이페이지
• 검색

등의 기능을 만들고 싶다고 치자

 

---

🚩기본 git 규칙

github에 저장소가 하나 있다 예를 들어 "community-server"

브랜치 구조

• main - 진짜 서비스에 나가는 코드 (절대 함부로 수정을 할 수가 없다)
• feature/* - 기능 하나 만들 때 쓰는 개인 작업 브랜치라고 생각하면 편하다

main에서 직접 개발을 하면 안 되고 모든 작업은 feature 브랜치에서 한다.

 

---

🚩 저장소를 내 컴퓨터로 복사해서 코드 받아오기

git clone https://github.com/company/community-server.git

이건 예시다

• clone ㅡ github에 있는 저장소를 내 컴퓨터로 복사

 

git checkout main
git pull --rebase origin main

• pull ㅡ github에서 내 컴퓨터로 최신 코드를 가져온다
• rebase ㅡ 내 코드 없이, 그냥 최신 상태로 정렬한다

 

---

🚩 기능 시작 ㅡ 브랜치 생성

git checkout -b feature/login

• branch ㅡ 평행 세계라고 생각하면 편하다 말 그대로 가지라는 뜻이다. main을 복사해서 만든 개인 작업 공간이다.

main
 └─ feature/login

현재 상태는 이렇다

 

---

🚩 개발 시작, 중간중간 저장

개발을 한다면 controller를 작성하고 service 로직 작성, JWT 발급, DB 조회 같은 것들을 한다.

git add .
git commit -m "feat: 로그인 API 구현"

• add ㅡ "나 이 파일들 저장할 거야" 체크를 한다
• commit ㅡ 이 시점 상태를 사진 찍어서 기록을 한다고 생각하면 편하다
• commit -m 메시지 ㅡ 이 작업을 왜 했는지 설명한다

 

---

🚩 github에 올린다

git push -u origin feature/login

• push ㅡ 내 컴퓨터 -> github로 업로드
• -u ㅡ 지금 하고 있는 브랜치랑 원격 브랜치를 연결하기

 

---

🚩 Pull Request(PR) 생성

Github에서는 feature/login -> main으로 가는 걸로

• 이 기능 다 만들었는데, main 합쳐도 되나요? 이렇게 물어보는 거라고 생각하면 됨
• PR에는 보통 어떤 기능인지, 어떻게 테스트했는지, 이슈 번호라든가 각자 템플릿이 있다고 한다

 

---

🚩 팀원들이 코드를 보고 리뷰를 한다

여기서 리뷰를 들으면 반영을 해야지

 

---

🚩 리뷰 반영 ㅡ 다시 commit, push

git add .
git commit -m "refactor: ~"
git push

• PR은 브랜치에 push하면 자동으로 업데이트가 된다

 

---

🚩 그 사이에 다른 사람이 "글쓰기 기능"을 merge 한다면? ㅡ rebase

main이 내가 하는 것보다 앞으로 가 버린다 예를 들어 main에 글쓰기 기능이 추가됐는데, login은 예전 main 기준이라든가

여기서 rebase를 쓴다 - 과거를 다시 쓰자

git checkout feature/login
git fetch origin
git rebase origin/main

• checkout 할 때 rebase하는 대상은 main이 아니라 내 브랜치에서 하는 거다
• fetch는 아직 합치는 게 아니라 origin에 있는 최신 main 정보를 가져오기만 한다 내가 기준 삼을 최신 main이 뭔지 알아야 되기 때문에 ㅡ pull이 fetch + merge 개념으로 본다
• 내가 A B C D를 했는데 main이 A B D E F까지 갔을 때 C 이후에 만든 커밋 E, F를 잠시 떼고 최신 main의 끝에 다시 하나씩 재적용하라는 뜻
• PR 리뷰가 편해지고 충돌을 해결하고, 히스토리가 읽기 쉬워서 장애 났을 때 추적이 쉽기 때문에 rebase를 많이 쓴다
• main에서 rebase는 절대 하면 안 된다 
• 내 작업을 최신 기준으로 다시 정렬

 

---

🚩 rebase 후에는 강제 push

git push --force-with-lease

• 원격이 내가 아는 상태일 때만 강제로 밀어라

 

---

🚩 PR 승인 -> merge

• PR에서 리뷰가 승인 되면 merge가 된다. main에 합치는 과정
• 여기서 squash merge를 쓴다
• squash merge ㅡ PR 브랜치에서 만든 여러 커밋을 하나의 커밋으로 뭉쳐서 main에 넣는 merge 방식으로 feature 브랜치에 커밋이 10개 있어도 main에는 커밋 1개만 만드는 기능

 

---

~git을 보내 주며~
물론 보냈지만 보낸 게 아니고 계속 써야 되는 기술? 기능이기 때문에 보냈지만 널 보내지 못하였다지만, 흐름은 정리가 된 것 같다. 또 써야 될 때가 오면 "아, 이거 어떻게 하더라" 헤매고 있겠지만, 그때는 그때 가서 열심히 구글링 하면 된다. 어차피 자주 쓰이는 명령어라든가 그런 것 빼고는 다들 찾아서 쓰고 있지 않을까, 싶고... 
내일은 자바 발제가 시작되는 날 너무 걱정된다. 괜찮겠지! 열심히 하면 되지!