Sparta(JAVA심화3기) - TIL/Chap.01

Chap.01 : 특강 - Git 그리고 PR(Pull Request) - TIL

Dev.99_tale 2025. 2. 13. 13:01

학습 목표

  • Git에 대한 개념을 익히고 프로젝트에 적용
  • Github을 통해 Pull Request 사용

1. Git 개념

VCS(Version Control System)와 SCM(Source Code Management)

  • VCS(버전 관리 시스템)는 파일의 변경 이력을 관리하고 협업을 가능하게 하는 시스템이다.
  • SCM(소스 코드 관리)는 VCS를 포함하여 빌드 자동화, 배포 등의 소프트웨어 개발 전반의 구성 관리를 의미한다.

Git과 SVN 차이점

비교 항목 Git (DVCS) SVN (CNCS)
저장소 구조 분산형 (각 사용자가 전체 저장소 보유) 중앙 집중형 (중앙 서버에 저장)
네트워크 의존성 오프라인 작업 가능 온라인 필수
속도 빠름 상대적으로 느림
브랜치 관리 가볍고 빠름 상대적으로 무거움

 

Git이 다루는 영역


참고 : https://velog.io/@jisu80/Git-Git-Flow

스테이징 영역(Staging Area)

  • 커밋 단위를 효율적으로 관리하기 위해 일부 파일만 선택하여 준비하는 공간
  • $ git diff --staged 명령어로 검토 가능
  • 인텔리제이에서도 커밋 창에서 "Staged Changes" 목록을 확인 가능

Git Flow와 브랜치 전략

  • Git Flow는 협업과 버전 관리를 체계적으로 하기 위한 브랜치 구조
  • 최근에는 develop 브랜치에서 오래된 브랜치가 남아있는 문제를 방지하기 위해 Trunk-Based Development (TBD) 방식이 적용되기도 한다

참고 : https://velog.io/@jisu80/Git-Git-Flow

 

Git (Git-Flow)

Git 이란?Git이란 코드 형상 관리 시스템으로 VCS(Version Control System)이라고 칭한다.Git이 다루는 영역은?출처: https://choonsik-lab.tistory.com/entry/Git-기초-1편?pidx=0이렇게 크게는 Lo

velog.io

 

 

브랜치 종류 및 역할

  • main(master) : 현재 서비스 중인 최종 릴리즈 버전
  • develop : 새로운 기능 개발 및 테스트 진행
  • feature : 새로운 기능 개발을 위한 브랜치
  • release : 배포를 위한 브랜치, 배포 준비 및 버그 수정 진행
  • hotfix : 긴급 수정이 필요한 경우 사용
  • sandbox : 개발 서버에서 테스트를 위한 브랜치
  • tag : 특정 릴리즈 버전을 기록하기 위한 마커 역할

브랜치 네이밍 규칙

브랜치명 예시

  • feature : feature/티켓번호_add-validation
  • release : release/1.0.0
  • hotfix : hotfix-버전번호-validation

커밋 메시지 예시

  • [티켓번호] 기능명
  • 상세 내용 기입 (필요 시)

3. Git 기본 명령어 정리

Git 설정

git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

저장소 초기화 및 원격 연결

git init
echo "initial commit" > README.md
git add README.md
git commit -m "Initial commit"
git remote add origin <원격저장소_URL>

브랜치 생성 및 전환

git branch # 모든 로컬 브랜치 확인
git checkout -b develop # develop 브랜치 생성 및 체크아웃
git push origin develop # 원격 저장소에 반영

커밋 및 푸시

git add .
git commit -m "feat: 추가 기능 구현"
git push origin feature/1_test

브랜치 삭제

git branch -d <브랜치명> # 로컬 브랜치 삭제
git push origin --delete <브랜치명> # 원격 브랜치 삭제

변경 사항 확인 및 병합

git fetch # 원격 저장소 변경 사항 확인
git merge feature/branch_name # 브랜치 병합

checkout vs switch

  • checkout : 브랜치 이동 및 워킹 트리 파일 복원 가능
  • switch : 브랜치 이동 전용
  • restore : 워킹 트리 파일 복원 전용

참고 : 제이크서 위키 블로그

4. Merge와 Rebase 차이

비교 항목 Merge Rebase
개념 두 개의 브랜치를 하나로 합침 변경 사항을 재정렬하여 깔끔한 히스토리 유지
커밋 기록 기존 커밋 유지 (Merge Commit 발생) 커밋이 새로 작성됨
충돌 해결 Merge 중 해결 Rebase 중 해결

5. Pull Request(PR) 활용

PR이란

  • 코드 변경 사항을 다른 브랜치에 병합(Merge) 요청하는 과정
  • PR은 단순히 코드 병합을 위한 과정이 아니라, 코드 리뷰와 협업을 위한 중요한 절차이다.

PR의 주요 역할

  • 코드 리뷰 : 다른 개발자가 코드의 문제를 발견하고 개선할 수 있다.
  • 협업 강화 : 팀원들과의 의견 조율 및 토론 가능
  • 코드 품질 : 필수 승인자 지정, 자동화된 테스트 등을 통해 코드 품질 관리유지 가능

좋은 PR 작성 방법

  1. 작은 단위로 나누기 : 너무 큰 기능 혹은 많은 변경사항을 한 번에 올리지 않기
  2. 명확한 제목과 설명
    • PR 제목 : 어떤 기능이 추가/변경되었는지 간결하게 작성
    • PR 설명
      • 변경 이유
      • 주요 변경 사항
      • 테스트 방법
      • 리뷰 요청 사항
  3. 코드 리뷰를 염두에 두기:  다른 개발자가 쉽게 이해할 수 있도록 클린 코드 유지

PR 작성 예시

### PR 제목
feat: 사용자 로그인 기능 추가

### 변경 사항
- OAuth2를 이용한 로그인 기능 구현
- JWT 토큰 발급 로직 추가
- 유효한 토큰이 없으면 API 접근 제한  

### 테스트 방법
1. `/login` 엔드포인트 호출
2. 정상적인 로그인 후 토큰 발급 확인
3. 토큰을 포함한 요청이 정상적으로 인증되는지 확인 

### 리뷰 요청 사항
- 인증 로직이 적절한지 확인 부탁드립니다.

충돌 해결 방법

  1. git pull --rebase origin develop을 사용하여 최신 변경 사항 반영
  2. 충돌 발생 시 git status로 충돌 파일 확인
  3. 충돌 파일 수정 후 git add .git rebase --continue 실행
  4. git push --force-with-lease로 원격 저장소에 반영
    • git merge --abort: 병합 중단
    • git rebase --abort: 리베이스 중단
  • 충돌 해결 후 git add  git commit

 

참고

https://markruler.github.io/posts/shell/cs-visualized-useful-git-commands/

 

CS Visualized: 유용한 깃(Git) 명령어

Lydia Hallie

markruler.github.io

https://gist.github.com/ljlm0402/5f69a1e831d8a50bb1b9f4f1fba71f7f

 

배포전략

배포전략. GitHub Gist: instantly share code, notes, and snippets.

gist.github.com