250709 [ Day 3 ] - Git (3)

TaeHyun·2025년 7월 9일

git study

TIL

목록 보기

3/182

Git

오늘은 Git에 대한 마지막 시간이었다. 아직 많은 기능을 다루지는 못했지만, 가장 많이 사용하고 당장 필요한 기능을 숙달하기 위해 오늘도 여러 번 반복해서 연습했다.

브랜치(Branch)란?

저장소의 기존 코드에서 갈라져 나온 하나의 독립적인 작업 공간으로, 여러 브랜치에서 작업 후 다시 합치는 작업을 항상 해야 한다는 특징이 있다.

브랜치의 역할
- 독립적 작업 : 다른 작업에 영향을 주지 않고 코드를 수정
- 기능 분리 : 개발, 테스트, 수정 등 기준으로 기존 코드와 분리하여 작업
- 안전한 개발 : 메인 코드에 오류가 생기지 않도록 보호
- 동시 작업 : 동시에 여러명의 개발자가 서로 다른 브랜치에서 작업 가능

Branch 관련 명령어

git switch 브랜치 이름 or git checkout 브랜치 이름 : 다른 브랜치로 이동

git branch : 로컬 브랜치 목록 확인
git branch -a : 로컬 + 원격 브랜치 목록 확인
git branch -r : 원격 브랜치 목록 확인

git branch -d 브랜치 이름 : 로컬 브랜치 삭제
git branch -D 브랜치 이름 : 브랜치 강제 삭제
git push origin -d 브랜치 이름 : 원격 브랜치 삭제

git merge 브랜치 이름 : 해당 브랜치를 현제 브랜치에 병합

merge에 대해

fast-forward = 현재 브랜치에서 변경 사항이 없을 때, 다른 브랜치의 커밋을 그대로 병합
3-way merge = 두 브랜치가 각각 다르게 작업하여 하나로 병합
두 브랜치가 각각 같은 파일을 작업 후 병합하려고 하면 충돌이 발생

브랜치 이름을 정할 때 자주 사용하는 규칙이 있다.

브랜치 이름 규칙

feature/ or feat/	새로운 기능 개발
fix/	버그 수정
hotfix/	긴급 버그 수정
release/	릴리즈 준비용
refactor/	리팩토링(기능 변경 없이 코드 구조 개선)
test/	테스트 코드 작성
chore/	사소한 작업

Commit 되돌리기

git reset 옵션 이동할 커밋

옵션
	--soft : HEAD만 이동, 스테이징에는 올라가 있으며 커밋만 다시 하고 싶을 때 사용
    --mixed : HEAD와 스테이징 영역까지 이동
    --hard : HEAD, 스테이징 영역, 작업 디렉토리 모두 롤백, 복구 불가능
이동할 커밋
    HEAD~n : n번째 조상 커밋으로 이동
    HEAD^n : 병합 커밋에서 사용하며 n번째 부모로 이동

git revert 이동할 커밋 주소

협업에는 reset보다 revert를 권장

브랜치를 만들어 GitHub에서 merge 하는 과정이 조금 익숙해진 후 GitHub를 이용한 협업 방법을 공부했다.

GitHub를 이용한 협업

협업 방법

WATERFALL
- 가장 익숙하고 고전적인 개발 기법
- 병행하지 않고 순차적으로 수행
- 단순한 모델이라 명확하게 파악 가능
- 변경을 수용하기 힘들다
- 시스템의 동작을 후반에 가야지만 확인 가능
- 순차적 진행으로 인해 일정이 지연될 가능성이 크다
AGILE
- 짧은 주기의 개발 단위를 반복해 하나의 큰 프로젝트를 완성해 나가는 것
- 요구 사항을 작은 단위로 쪼개 솔루션 제작, 빠른 진행
- Scrum(스크럼) 방법
  - 스프린트(Sprint)라고 불리는 반복 주기를 통해 프로젝트를 진행
  - 핵심 구성 요소
    
    스프린트(Sprint) : 정해진 기간(보통 2~4주) 동안 제품의 일부를 개발하는 반복 주기
    제품 백로그(Product Backlog) : 제품에 필요한 기능, 개선사항, 버그 수정 목록
    스프린트 백로그(Sprint Backlog) : 해당 스프린트에서 구현할 작업 목록
    데일리 스크럼(Daily Scrum) : 매일 15분 내외로 진행되는 짧은 회의, 진행 상황 공유 및 문제점 논의
  - 주요 이벤트(의식, Ceremonies)
    
    스프린트 계획 회의(Sprint Planning) : 스프린트에서 어떤 일을 할지 결정
    데일리 스크럼(Daily Scrum) : 팀원들이 각자의 진행상황을 공유
    스프린트 리뷰(Sprint Review) : 스프린트 결과물 시연 및 피드백 수집
    스프린트 회고(Sprint Retrospective) : 스프린트 과정에 대한 개선점 논의
- Kanban(칸반) 방법
  - 단계별 작업 현황을 열 형식의 보드 형태로 시각화 하는 프로젝트 관리 방법
    - 업무 흐름의 시각화
    - 진행 중 업무의 제한
    - 명시적 프로세스 정책 수립
    - 업무 흐름의 측정과 관리

GitHub 협업 방식

Collaborator
- 소규모 개발 팀에 적합
- 여러 명이 origin에 push를 하기 때문에 merge conflict를 항상 주의
- 같은 파일을 여러명이 동시에 편집하지 않는 것은 필수
Fork
- 대규모 협업 시 원격 저장소를 복제하여 협업하는 것이 유리
- 다른 사람의 Remote Repo.를 복사하여 가져옴
- 복사해온 Remote Repo.는 원본(Upstream)과 연결되어 있음
- 원본 Remote Repo.의 소유자는 Pull Request를 수학하여 Forked Repo.를 origin에 merge