오늘은 Git과 GitHub 기초에 대한 강의를 들었다.
이론뿐만 아니라 직접 브랜치를 만들고, PR을 생성하고, 머지까지 실습해보면서
GitHub 협업 흐름을 한 번 끝까지 경험해볼 수 있었다.
reset / restore / revert 개념 정리
reset — 과거를 지우는 방식
- 특정 커밋 이후의 모든 기록을 삭제
- 커밋 로그에서 아예 사라짐
- 협업 환경에서는 위험할 수 있음
- 혼자 작업 중, 커밋 히스토리 정리 시 사용
restore — 파일 단위로 되돌리기
- 커밋 전체가 아니라 파일 단위로 상태 복구
- 작업 중인 파일이나 스테이징된 파일을 되돌릴 때 사용
- 커밋 기록에는 영향 없음
revert — 기록을 유지하며 되돌리기
- 특정 커밋의 변경 사항을 취소하는 새 커밋 생성
- 기존 커밋 히스토리는 그대로 유지
- 협업 환경에서 가장 안전한 방법
협업 중이라면 revert,
혼자 작업 중이라면 상황에 따라 reset / restore를 선택하는 게 중요하다고 느꼈다
Git Branch란?
Git을 처음 사용할 때도 우리는 이미 main 브랜치에서 작업하고 있다.
브랜치는 말 그대로 나무 가지처럼,
기존 코드 흐름에서 독립된 작업 공간을 만들어주는 기능이다.
브랜치를 사용하는 이유
- 기능 개발, 테스트, 배포 환경을 분리하기 위해
- 새로운 기능 개발 중 발생할 수 있는 버그를 기존 코드와 격리하기 위해
- 협업 시 각자 작업 영역을 명확히 나누기 위해
프로젝트 규모가 커질수록 브랜치 기반 개발은 선택이 아니라 필수다.
브랜치 생성 & 이동
현재 브랜치 확인
git branch
새 브랜치 생성
git branch cherry-pick
브랜치 이동
git checkout cherry-pick
- 브랜치를 생성해도 이동하지 않으면 작업 브랜치는 바뀌지 않는다
- 브랜치는 현재 브랜치의 최신 커밋 기준으로 생성된다
Cherry-pick이란?
cherry-pick은
다른 브랜치의 특정 커밋 하나만 골라서 가져오는 기능이다.
Cherry-pick 특징
- 브랜치 전체를 합치지 않음
- 특정 커밋만 선택적으로 반영
- 원래 브랜치와의 관계는 유지되지 않음
사용 예시
- 긴급 버그 수정 커밋만 빠르게 배포해야 할 때
- 전체 기능 병합은 부담스러울 때
⚠️ Cherry-pick 주의점
커밋 간 충돌(conflict)이 발생할 수 있음
과거 커밋을 끼워 넣는 구조에서는 충돌 가능성 ↑
남용하면 히스토리 추적이 어려워짐
- 그래서 cherry-pick은 특수한 상황에서만 사용하는 것이 좋다.
GitHub 협업 흐름: PR & Merge
실무에서는 보통 cherry-pick보다
Pull Request(PR) + Merge 방식으로 협업한다.
Pull Request (PR)
이 브랜치의 변경 사항을 합치고 싶어요 라는 요청
변경 내용, 리뷰, 의견 공유의 공간
줄여서 PR이라고 부른다
Merge
PR에 대한 리뷰가 끝나면 코드 병합
GitHub UI에서 병합하는 경우가 일반적
아래는 내가 직접 실습해본 과정과 결과들이다.
1) 브랜치 생성하기
git branch login git branch # 생성한 브랜치 & 현재 브랜치 확인 git checkout login git branch
2) Readme.md 텍스트 추가 후, 커밋까지 진행
# github 기초 강의
## 로그인 기능 구현
- 로그인 명세서를 조회하려면 여기를 확인하세요.위 내용 작성 후
git add Readme.md git commit -m "Finished: log" git push origin login
3) PR 생성하기
4) 코드 단위 리뷰 확인하기
5) 리뷰 끝내기
6) PR 브랜치 합치기(Merge)
7) 로컬에서 코드 pull 해오기
git checkout master git pull origin master
- git 도구로 브랜치 생성 및 병합 결과도 볼 수 있음
- 브랜치가 병합 되었을 때는 master 또는 main 브랜치의 그래프에 다른 브랜치들이 합쳐져 있는 것들 볼 수 있음
이슈 등록과 라벨 추가 실습
이슈 해결 완료 실습
Github에 나의 자기소개서 배포하기
실습 이력서 템플릿은 스파르타에서 제공받음
1) 배포할 저장소 준비하기
jiiimni.github.io
2) 이력서 템플릿 가져오기
git clone https:// ~ cd resume-template
3) 클론 저장소에 있는 .git 폴더 제거
ls -altr rm -rf .git/
4) 저장소 초기화, 그리고 푸시
git init git add . git commit -m "init: resume template" git remote add origin https://jiiimni.github.io.git git push origin main
브랜치 전략
대표적인 브랜치 구조와 역할
Dev / Stage / Prod 구조
배포 단계를 명확히 나눠 안정성과 협업 효율을 높인다.
-
Dev
기능 개발과 수정이 가장 활발한 브랜치
→ 개발 완료 후 Stage로 병합 -
Stage
배포 전 최종 테스트(QA, 통합 테스트) 환경
→ 문제 없으면 Prod로 병합 -
Prod
실제 사용자에게 배포되는 운영 브랜치
긴급 버그는 hotfix로 빠르게 대응
태그(tag)로 배포 이력 관리
staging 없이 바로 prod로 배포하면
- 검증 부족으로 장애 위험 증가
- 한 번에 많은 변경이 포함된 Fat Release 발생
-> 작은 단위로 자주 배포하는 Small Release가 더 안전
목적 기반 브랜치 (Git Flow 스타일)
-
feature/
새로운 기능 개발
(develop에서 분기 → develop로 병합) -
release/
배포 직전 안정화 브랜치
QA 및 버그 수정 후 main(master)로 병합 -
hotfix/
운영 중 발생한 긴급 버그 수정
main에서 분기 -> 수정 후 main + develop에 반영
Git Flow vs GitHub Flow vs Trunk-Based Development
Git Flow
- 브랜치: main / develop / feature / release / hotfix
- 장점: 체계적, 안정성 높음
- 단점: 브랜치 관리 비용 큼
- 적합: 대규모 프로젝트, 운영 중심 서비스
GitHub Flow
- 브랜치: main + feature
- PR 리뷰 후 바로 main 병합
- 장점: 단순, 빠른 배포
- 단점: 검증 부족 시 위험
- 적합: 소규모 팀, 스타트업
Trunk-Based Development (TBD)
- 단일 main(trunk) 중심
- 아주 작은 단위로 자주 병합
- 장점: 매우 빠른 배포, 충돌 최소화
- 주의: 큰 기능 개발·의존성 있는 작업엔 부적합
버전 관리: SemVer (x.x.x)
- Major: 호환 깨지는 변경 (
1.0.0 -> 2.0.0) - Minor: 기능 추가 (
1.1.0 -> 1.2.0) - Patch: 버그 수정 (
1.0.1 -> 1.0.2)
한 줄 정리
- 안정성과 체계 -> Git Flow
- 단순함과 속도 -> GitHub Flow
- 초고속 배포 -> Trunk-Based Development
결국 프로젝트 규모와 팀의 개발 방식에 맞는 전략을 선택하는 것이 가장 중요하다.
