[KB IT's your life] 10일차 - Git 특강(1)

학습 목표

• Git을 왜 사용하는지 설명할 수 있다
• 로컬(Local)과 원격(Remote) 개념을 설명할 수 있다
• 커밋(Commit), 스테이지(Stage), 브랜치(Branch) 등 기본 개념을 이해한다
• 로컬 컴퓨터에서 Git 기본 기능을 가이드 없이 사용할 수 있다

Git의 필요성과 역사

Git이란?

• 정의: 소스 코드를 관리해주는 도구 
• 핵심 기능:
  • 파일의 상태 저장
  • 파일의 변경 기록 저장 (핵심!)
• 분류: 분산 버전 관리 시스템 (Distributed VCS)

버전 관리 시스템의 발전

본 이미지는 AI 이미지 생성 도구를 활용하여 제작되었습니다

1세대: 로컬 VCS

• 개발자 컴퓨터에서만 관리
• 협업 불가능

2세대: 중앙집중식 VCS (Centralized VCS)

• 서버 1대에 버전 관리 시스템 설치
• 팀원들이 공동으로 접속하여 사용

문제점:

• SPOF (Single Point of Failure): 서버가 다운되면 전체 작업 중단
• 서버가 병목 지점이 됨

본 이미지는 AI 이미지 생성 도구를 활용하여 제작되었습니다

3세대: 분산 VCS

예시: Git

• 코드 저장소를 복제(Clone) 가능
• 각 로컬 환경이 완전한 저장소 역할
• 중앙 서버가 다운되어도 작업 가능
• 로컬에서 복구 가능

변경 이력을 저장해야 하는 이유

실제 사례 :

• 커밋 수: 약 19,000개
• 각 파일별로 변경 이유, 시점, 작성자 추적 가능
• 특정 코드 라인 선택 → 언제, 왜 추가되었는지 확인 가능
• PR(Pull Request) 링크를 통한 코드 리뷰 내역 확인

장점:

1. 이력 파악: 4년 전, 2년 전 코드 변경 내역 확인
2. 작성자 확인: 누가 만들었는지 추적
3. 변경 목적 이해: 커밋 메시지를 통한 맥락 파악
4. 독립적 학습: 다른 사람 도움 없이도 코드 이해 가능

AI 시대와 Git 학습의 의미

LLM (Large Language Model)이란?

• 정의: 대형 언어 모델
• 동작 원리:
  • 사람들이 만든 데이터로 학습
  • 다음 단어를 예측하도록 훈련됨
  • 분포의 패턴을 학습하여 그럴싸한 답변 생성

 

Git 사용 방법

리눅스 기본 명령어 

명령어	설명	예시
pwd	Print Working Directory (현재 경로 출력)	pwd
cd	Change Directory (디렉토리 이동)	cd basic
cd..	상위 디렉토리로 이동	cd..
ls	List (파일/폴더 목록 출력)	ls
ls -al	숨김 파일 포함 상세 목록	ls -al
mkdir	Make Directory (폴더 생성)	mkdir basic
clear	콘솔 화면 지우기	clear
man	Manual (명령어 매뉴얼)	man is
touch	빈 파일 생성	touch file.txt

 
옵션 사용법:

• 단축 옵션: - (예: -a, -l)
• 풀 옵션: -- (예: --all, --list)

Git 초기 설정

사용자 정보 설정 (필수!)

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

• 커밋 작성자 정보로 사용됨
• 설정하지 않으면 커밋 시 오류 발생

줄바꿈 설정

git config --global core.autocrlf true

에디터 설정

# Vim 사용
git config --global core.editor vim

# VS Code 사용 (추천)
git config --global core.editor "code --wait"

 
설정 확인

# 로컬 저장소 설정 확인
git config -l

# 글로벌 설정 확인
git config --global -l

# 에디터로 확인/수정
git config -e
git config --global -e

 

Git 핵심 개념

레포지토리 (Repository)

정의: 저장소 = 코드 저장소
 
단위: 프로젝트 단위로 생성

• 1 프로젝트 = 1 레포지토리
• 예: Apache Kafka 프로젝트 = 1개의 레포지토리

로컬 레포지토리: 내 컴퓨터의 프로젝트 폴더
원격 레포지토리: GitHub 등의 서버에 있는 저장소
 
생성 방법:

1. 새로 생성: git init
2. 복제: git clone <url>

커밋 (Commit)

정의:

• Commitment = 약속, 도장 찍기
• 변경 이력을 저장하는 단위
• 코드의 스냅샷

특징:

• 각 커밋은 고유한 해시값(ID)을 가짐
• 과거 커밋을 가리키는 Pointer 구조
• Linked List처럼 연결됨
• 최신 커밋 → 과거 커밋 방향

Git의 파일 관리 방식

Snapshot 방식

본 이미지는 AI 이미지 생성 도구를 활용하여 제작되었습니다.

버전1: A₁, B₁, C₁
버전2: A₂, B₁, C₂  (B는 변경 없어서 포인터만)
버전3: A₂, B₁, C₃
버전4: A₃, B₂, C₃
버전5: A₃, B₃, C₃

• 전체 파일의 최종 상태를 버전별로 저장
• 변경되지 않은 파일은 이전 버전 포인터 사용
• 어떤 버전을 선택해도 즉시 해당 시점의 전체 상태 확인 가능

 
장점:

• 특정 시점으로 빠른 복구
• 브랜치 생성/전환이 빠름
• 병렬 작업에 유리

실습: 로컬 레포지토리 생성

새 레포지토리 생성

# 1. 작업 폴더 생성 및 이동
mkdir basic
cd basic

# 2. 현재 경로 확인
pwd

# 3. Git 저장소로 초기화
git init
# 결과: Initialized empty Git repository in /path/to/basic/.git/

# 4. 생성된 .git 폴더 확인
ls -al
# .git 디렉토리가 생성됨

# 5. .git 내부 확인
cd .git
ls -al

 

실습: 원격 레포지토리 복제

본 이미지는 AI 이미지 생성 도구를 활용하여 제작되었습니다.

Clone 실습

# 1. 상위 디렉토리로 이동
cd ..

# 2. 새 폴더 생성
mkdir remote-test
cd remote-test

# 3. Apache Kafka 레포지토리 복제
git clone https://github.com/apache/kafka.git

# 4. 복제된 폴더로 이동
cd kafka

# 5. .git 디렉토리 확인
ls -al
# .git이 존재함 = 로컬 레포지토리

# 6. Git 로그 확인
git log

# 7. 한 줄로 로그 보기
git log --oneline

 

마크다운(Markdown) 문법

 
기본 문법

# 제목 1 (가장 큰 제목)
## 제목 2
### 제목 3

**굵은 글씨**
*기울임*

- 리스트 항목 1
- 리스트 항목 2

1. 번호 리스트 1
2. 번호 리스트 2

[링크 텍스트](URL)
![이미지](이미지URL)

 

Git의 세 가지 작업 공간

Working Directory (작업 디렉토리)

정의: 실제로 파일 작업이 일어나는 로컬 공간
특징:

• IDE에서 보이는 현재 상태가 Working Directory의 상태
• 실제 파일의 변경(생성, 수정, 삭제)이 일어나는 곳
• pwd 명령어로 현재 경로 확인 가능

Staging Area (스테이징 영역) / Index

정의: 커밋되기 전 변경사항을 임시로 리스팅해 둔 공간
특징:

• 눈에 보이지 않는 논리적 공간
• Working Directory와 Local Repository 사이에 위치
• 커밋할 변경사항을 선택적으로 구성하기 위한 공간

목적: 논리적 단위로 변경사항을 묶어 커밋 구성
 

Local Repository (로컬 저장소)

정의: .git 폴더 내에 실제 커밋 데이터가 저장되는 공간
특징:

• 커밋된 변경 이력이 저장됨
• 파일 단위로 diff가 저장
• 객체(objects)로 변경사항 관리

기본 파일 조작 명령어 

파일 생성 및 확인

touch README.md              # 빈 파일 생성
ls -a                       # 파일 목록 확인 (숨김 파일 포함)
cat README.md               # 파일 내용 출력
vi README.md                # VIM 에디터로 파일 편집

 
파일 내용 입력

echo "내용"                  # 콘솔에 문자열 출력
echo "내용" > file.md       # 파일에 덮어쓰기 (꺾쇠 1개)
echo "내용" >> file.md      # 파일 끝에 추가 (꺾쇠 2개)

 

Git 기본 명령어

저장소 초기화 및 상태 확인

git init                    # 현재 디렉토리를 Git 저장소로 초기화
git status                  # 변경사항 상태 확인

git status 출력 내용:

• Working Directory의 상태
• Staging Area의 상태
• 추적되지 않는 파일(Untracked files)
• 괄호 안에 다음 수행할 명령어 힌트 제공

변경사항 추가 및 커밋

git add <filename>          # 특정 파일을 Staging Area에 추가
git add .                   # 모든 변경사항을 Staging Area에 추가
git commit                  # VIM 에디터로 커밋 (메시지 작성창 열림)
git commit -m "메시지"      # 한 줄 메시지로 바로 커밋

 
VIM 에디터 사용법:

• i: 입력 모드 진입
• ESC: 명령 모드로 전환
• :w: 저장
• :q: 종료
• :wq: 저장 후 종료

커밋 이력 조회

git log                     # 기본 로그 조회
git log --oneline          # 한 줄로 간단히 조회
git log --patch            # diff와 함께 조회
git log --stat             # 변경 통계와 함께 조회
git log --oneline --patch --stat  # 여러 옵션 조합 가능

로그 출력 정보:

• Commit ID (해시값)
• 작성자 정보
• 작성 시간
• 커밋 메시지 (제목 + 내용)
• Root commit: 최초 커밋 표시

변경사항 확인 (diff)

git diff                    # Working Directory의 변경사항 확인
git diff --staged          # Staging Area의 변경사항 확인
git diff --cached          # --staged와 동일

diff 활용:

• add 전: git diff로 변경사항 확인 가능
• add 후: git diff --staged로 확인해야 함
• 변경된 줄 앞에 + 표시

원격 저장소 연동

원격 저장소 추가

git remote add origin <URL>     # 원격 저장소를 origin이라는 이름으로 추가
git remote -v                   # 등록된 원격 저장소 확인

원격 저장소 별칭:

• origin: 관례상 주 원격 저장소 이름
• fetch: 가져오기용 URL
• push: 업로드용 URL

브랜치 설정 및 푸시

git branch -M main              # 기본 브랜치 이름을 main으로 변경
git push origin main            # 로컬 변경사항을 원격으로 푸시
git push -u origin main         # upstream 설정과 함께 푸시

 
원격 저장소 복제

git clone <URL>                 # 원격 저장소를 로컬로 복제

 

로컬 저장소 생성 두 가지 방법

방법 1: git init (로컬 우선)

프로세스:

1. 로컬 디렉토리 생성: mkdir project
2. 디렉토리 이동: cd project
3. Git 초기화: git init
4. 파일 작업 및 커밋
5. GitHub에 원격 저장소 생성 (빈 저장소, 체크박스 모두 해제)
6. 원격 저장소 연결: git remote add origin <URL>
7. 푸시: git push -u origin main

주의사항: GitHub에서 저장소 생성 시 README, .gitignore, license 추가 옵션 모두 체크 해제
 

방법 2: git clone (원격 우선) - 권장

프로세스:

1. GitHub에서 원격 저장소 생성
2. README, .gitignore 등 선택적 추가
3. 로컬로 복제: git clone <URL>
4. 자동으로 .git 폴더 및 원격 연결 설정됨

장점:

• 초기 설정이 자동으로 완료
• 원격 연결 수동 설정 불필요

 

GitHub 저장소 생성 옵션

기본 설정

• Repository name: 저장소 이름 (로컬 이름과 동일하지 않아도 됨)
• Public/Private: 공개 여부 선택

초기 파일 옵션

• README.md: 프로젝트 설명 파일
• .gitignore: Git 추적 제외 파일 리스트
  • 언어별 템플릿 제공 (Java, Python, Node 등)
  • 개발 환경에 맞는 언어 선택
• License: 오픈소스 라이선스 (학습용은 불필요)

빈 저장소 생성 시:

• 모든 체크박스 해제 → 안내 명령어 제공
• 체크박스 선택 → 초기 커밋 자동 생성

Commit 메시지 작성 가이드

중요성

• 커뮤니케이션 도구: 개발자의 가장 중요한 능력
• 미래의 나를 위한 설명서: 나중에 읽어도 이해 가능해야 함
• 협업의 핵심: 다른 사람이 읽어도 변경사항 파악 가능해야 함

본 이미지는 AI 이미지 생성 도구를 활용하여 제작되었습니다.

작성 원칙

• 명확하고 구체적으로 작성
• 변경 목적과 내용을 모두 포함
• 프로젝트별 작성 규칙(Convention) 준수
• 제목과 본문 구분 (상세 설명 필요 시)

구조

제목: 변경사항 요약 (50자 이내)

본문: 상세 설명 (선택사항)
- 왜 이 변경이 필요한가?
- 무엇을 변경했는가?
- 어떤 영향이 있는가?

Git 명령어 카테고리

시작하기

• git clone: 원격 저장소 복제
• git init: 로컬 저장소 초기화

변경사항 조작

• git add: Staging Area에 추가
• git mv: 파일 이동
• git restore: 변경사항 되돌리기
• git rm: 파일 삭제

이력 관리

• git log: 커밋 이력 조회
• git status: 현재 상태 확인
• git diff: 변경사항 비교

브랜치 & 병합

• git branch: 브랜치 관리
• git commit: 커밋 생성
• git merge: 브랜치 병합
• git rebase: 커밋 재정렬

협업

• git fetch: 원격 변경사항 가져오기
• git pull: 가져오기 + 병합
• git push: 로컬 변경사항 업로드

 

실습 워크플로우 예시

새 프로젝트 시작

# 1. 디렉토리 생성 및 이동
mkdir git-basic
cd git-basic

# 2. Git 초기화
git init

# 3. 파일 생성
echo "# My Project" > README.md

# 4. 상태 확인
git status

# 5. Staging Area에 추가
git add README.md

# 6. 다시 상태 확인
git status

# 7. 커밋
git commit -m "docs: README 파일 추가"

# 8. 로그 확인
git log --oneline

 
파일 수정 및 재커밋

# 1. 파일 수정
echo "프로젝트 설명 추가" >> README.md

# 2. 변경사항 확인
git diff

# 3. Staging
git add README.md

# 4. Staged 변경사항 확인
git diff --staged

# 5. 커밋
git commit -m "docs: README 내용 업데이트"

 
추가 팁: Linux 명령어 특수 기호

• >: 표준 출력을 파일로 덮어쓰기 (redirect)
• >>: 표준 출력을 파일 끝에 추가 (append)
• 예: echo "text" > file.txt

HEAD의 개념과 역할

현재 작업 중인 브랜치의 마지막 커밋을 가리키는 포인터
HEAD의 활용

git log  # HEAD 위치 확인
git diff  # 워킹 디렉토리와 HEAD 커밋 간 차이 확인

• HEAD 위치 이동 가능 (과거 커밋으로 체크아웃)
• 작업 공간이 이상할 때: 항상 HEAD 위치 확인 필요
• HEAD가 브랜치를 가리키지 않으면 작업 공간 문제 발생 가능성

브랜치(Branch) 개념

• 특정 커밋을 가리키는 포인터
• 작업 공간을 분기하는 기능
• 게임의 선택지처럼 여러 경로로 개발 가능

본 이미지는 AI 이미지 생성 도구를 활용하여 제작되었습니다.

브랜치의 필요성

문제 상황 예시:

메인 브랜치: A → B → C (웰컴 화면 완성)
개발자가 C에서 직접 D(로그인) 추가
→ 다른 팀원이 동시 작업 시 충돌 발생
→ 웰컴 화면조차 작동 안 할 수 있음

해결 방안:

메인 브랜치: A → B → C (항상 정상 동작)
           ↓
디벨롭 브랜치: D → E → F (로그인 기능)

 
브랜치 작업 흐름

1. 메인 브랜치: 항상 정상 동작하는 코드만 유지
2. 기능 브랜치: 새 기능 개발을 위한 별도 공간
3. 테스트 & 리뷰: 충분한 검증 후
4. 머지(Merge): 메인 브랜치에 반영

브랜치 생성 기준

• 개발 단위별: 기능 하나당 브랜치 하나
• 리뷰 단위별: 코드리뷰 받을 묶음 단위로 생성
• 예시:

브랜치 네이밍

• 기능 브랜치: feature/shopping-cart-list
• 버그 수정: bugfix/cart-delete-error
• 핫픽스: hotfix/critical-security-patch

브랜치 명령어

브랜치 생성 및 관리

# 브랜치 생성
git branch develop

# 브랜치 목록 조회
git branch

# 브랜치 전환 (체크아웃)
git checkout develop

# 브랜치 생성 + 전환 (단축)
git checkout -b feature-login

 
베이스(Base) 개념

• 새 브랜치는 현재 체크아웃된 브랜치를 베이스로 생성
• 메인 브랜치 체크아웃 상태에서 생성 → 메인의 히스토리 계승
• 작업 전 반드시 확인: 현재 HEAD 위치 확인 필수

브랜치 병합

# 메인 브랜치로 이동
git checkout main

# develop 브랜치 병합
git merge develop

주의: 항상 병합될 대상 브랜치로 먼저 이동
 
 

실무 개발 프로세스

이슈 기반 개발

1. 이슈 생성: Jira, Confluence 등 이슈 트래커
2. 개발 범위 결정: 이슈 내용 기반
3. 브랜치 생성: 기능별 독립 브랜치
4. 커밋 작업: 의미 있는 단위로 커밋
5. 풀 리퀘스트(PR): 코드 리뷰 요청
6. 코드 리뷰: 팀원들의 검토 및 피드백
7. 승인 & 머지: 리뷰 완료 후 메인 브랜치 반영

7. Git 작업 기본 순서

# 1. 상태 확인
git status

# 2. 변경사항 확인
git diff

# 3. 스테이징
git add .

# 4. 재확인
git status

# 5. 커밋
git commit -m "커밋 메시지"

# 6. 로그 확인
git log

 

추가 명령어 및 팁

이전 상태로 되돌리기

# 로그에서 커밋 해시 복사
git log

# 특정 커밋으로 강제 리셋
git reset --hard <커밋해시>

 

기본 명령어 - add와 restore

git add 명령어

• 역할: Working Directory의 변경사항을 Staging Area(Index)에 반영
• git add [파일명]: 특정 파일만 추가
• git add .: 현재 디렉토리의 모든 변경사항 추가

git restore --staged [파일명]

• 역할: Staged 상태의 파일을 Unstaged 상태로 되돌림
• 목적: 잘못 add한 파일을 커밋 대상에서 제외
• 변경사항 자체는 Working Directory에 유지됨

git restore [파일명]

• 역할: Working Directory의 변경사항을 완전히 삭제
• 주의: 변경사항이 완전히 사라지므로 신중하게 사용
• 옵션 없이 파일명만 입력

Commit 관련 명령어

git commit --amend (어맨드 옵션)

• 역할: 마지막 커밋을 새로운 내용으로 대체
• 동작 과정:
  1. 기존 마지막 커밋이 사라짐
  2. 새로운 변경사항이 포함된 커밋으로 교체
  3. 새로운 커밋 ID가 할당됨
• 사용 시나리오:
  • 마지막 커밋 직후 빠뜨린 내용 발견
  • 커밋 메시지 수정 필요
• 커밋 메시지 수정 창이 자동으로 열림

git commit --fixup HEAD (픽스업 옵션)

• 역할: 이전 커밋은 유지하면서 수정 커밋을 추가
• 동작 과정:
  1. 기존 HEAD 커밋은 그대로 유지
  2. 그 위에 새로운 fixup 커밋 생성
  3. HEAD가 새 커밋으로 이동
• 커밋 메시지: 자동으로 "fixup! [원본 메시지]" 형식으로 생성
• 차이점: amend는 대체, fixup은 추가

실습 예시

# 변경사항 확인
git status
git diff

# add 후 amend로 커밋
git add .
git commit --amend
# → 이전 커밋이 새 커밋으로 대체됨

# fixup으로 커밋
git add .
git commit --fixup HEAD
# → 새로운 fixup 커밋이 추가됨

 

파일 이동 및 이름 변경 - mv 명령어

리눅스 mv 명령어

• 파일명 변경과 경로 이동 모두 가능
• mv a.txt b.txt: 파일명 변경
• mv b.txt ./basic/: 파일 이동

Git mv 명령어

• 형식: git mv [원본파일] [대상파일]
• 장점: 이름 변경을 자동으로 staged 상태로 추가
• 예시: git mv "What I like.txt" "What I love.txt"
• 상태 확인: git status에서 "renamed:" 로 표시
• diff 확인: 이름 변경 내역을 명확하게 표시

파일 삭제 - rm 명령어

git rm [파일명]

• 역할: 파일 삭제 + 변경사항을 자동으로 staging
• 동작:
  1. Working Directory에서 파일 실제 삭제
  2. 삭제 변경사항을 자동으로 Index에 추가
• 확인: git status에서 "deleted:" 로 표시

브랜치 시각화

그래프 옵션

git log --oneline --graph

• 브랜치가 어디서 분기되었는지 확인
• 커밋 이력이 어떻게 쌓였는지 파악
• 복잡한 브랜치 구조에서 필수적

 

이전 상태로 복구

Reflog 활용한 Reset

실습 예시:

git reflog                    # HEAD 이동 이력 확인
git reset --hard [commit_id]  # 특정 커밋으로 복구

• reflog로 이전 커밋 ID 확인
• 복사한 커밋 ID로 reset
• 병합 이전 상태로 복구 가능

• 방법 1: reflog로 커밋 ID 찾기
• 방법 2: git log에서 끝에서 두 번째 커밋으로 reset

브랜치 병합: Merge vs Rebase

공통점

• 목적: 분기한 브랜치를 베이스 브랜치로 반영
• 최종 소스 코드: 동일한 결과
• 차이: diff를 기존 브랜치에 합치는 방식

본 이미지는 AI 이미지 생성 도구를 활용하여 제작되었습니다.

Merge 방식
특징:

• 명시적인 머지 커밋(Merge Commit) 생성
• 브랜치 히스토리가 가지치기 형태로 보존됨
• 그래프에서 분기가 시각적으로 확인 가능

커밋 히스토리:

• 메인 브랜치 변경사항과 작업 브랜치 변경사항이 별도 라인으로 표시
• 최종적으로 머지 커밋에서 합쳐짐
• 사용 사례: 큰 단위의 브랜칭을 시각적으로 확인하고 싶을 때

Merge 실습

절차:

git checkout main         # 메인 브랜치로 이동
git merge testing         # testing 브랜치 병합

결과:

• 메인 브랜치가 testing의 커밋을 포함
• HEAD가 메인을 가리킴
• 코드 상태는 testing과 동일

Rebase 방식
특징:

• 머지 커밋 없이 일직선 히스토리 생성
• 베이스를 다시 쌓는 방식
• 모든 커밋이 메인 브랜치에서 작업한 것처럼 보임

동작 원리:

• 작업 브랜치의 커밋을 임시 저장
• 메인 브랜치의 최신 커밋을 베이스로 설정
• 임시 저장한 커밋을 새 베이스 위에 순차적으로 적용
• 명령어: git rebase <브랜치명>
• 깔끔한 히스토리 유지, 선형적인 커밋 로그 선호 시

Rebase 실습

절차:

git checkout main
git rebase testing

결과:

• 커밋 히스토리는 merge와 유사
• 파일 내용 동일

최종 결과물

코드 상태는 동일: Merge든 Rebase든 최종 코드는 같음

차이점

차이점은 히스토리: 커밋 로그의 모양새만 다름

단순 작업: 큰 차이 없음
 
복잡한 작업:

• 변경 규모가 클 때
• 다른 사람의 작업이 메인 브랜치에 추가된 후 병합 시
• 커밋 이력 모양이 달라짐

Git 충돌(Conflict) 개념

본 이미지는 AI 이미지 생성 도구를 활용하여 제작되었습니다.

충돌 발생 시나리오

• 발생 조건: 메인 브랜치에서 새 브랜치를 만든 후, 메인 브랜치가 변경되고 동시에 새 브랜치에서도 같은 파일을 수정한 경우

예시 상황:

• C1 커밋에서 브랜치 분기 → 메인에 C2 커밋 추가 → 분기 브랜치에 C3 커밋 추가
• 같은 파일의 같은 부분을 서로 다르게 수정
• 함수 시그니처 변경: 한쪽에서는 인자 이름 변경, 다른 쪽에서는 인자 삭제

충돌 발견 시 상태 확인

• git status 명령어로 충돌 상태 확인
• 터미널 표시: "You have unmerged paths", "fix conflicts"
• 충돌 파일에 <<<<<<<, =======, >>>>>>> 마커 표시

충돌 해결 절차

1. git diff로 충돌 내용 확인
2. 충돌 마커 확인:
   • <<<<<<< HEAD: 현재 브랜치(메인) 변경사항
   • =======: 구분선
   • >>>>>>> branch-name: 머지하려는 브랜치 변경사항
3. 선택지:
   • 옵션 1: 메인 브랜치 변경사항 선택
   • 옵션 2: 머지 브랜치 변경사항 선택
   • 옵션 3: 두 변경사항 모두 유지
   • 옵션 4: 완전히 새로운 코드 작성
4. 충돌 해결 후 git add <파일명>으로 마킹
5. git commit으로 머지 커밋 완료

충돌 취소

• git merge --abort: 머지 시도 취소, 이전 상태로 복귀

Stash 명령어

• 상황: 커밋하지 않은 변경사항이 있는데 브랜치 전환이나 Merge/Rebase가 필요한 경우
• 문제: Unstaged 상태의 변경사항이 있으면 브랜치 변경 명령어 실행 불가

Stash 동작 원리

• 저장: git stash - 워킹 디렉토리의 변경사항을 임시 공간에 저장
• 조회: git stash list - 저장된 stash 목록 확인
• 복원: git stash pop - 가장 최근 stash를 워킹 디렉토리로 복원
• 특정 복원: git stash apply stash@{0} - 특정 stash 복원

Stash 활용 워크플로우

1. 작업 중 커밋 전 상태에서 git stash 실행
2. 브랜치 변경 또는 merge/rebase 수행
3. 작업 완료 후 git stash pop으로 작업 내용 복원
4. 계속 작업 진행

Fetch vs Pull

Fetch 명령어

• 기능: 원격 저장소의 변경사항을 로컬로 받기만 함
• 워킹 디렉토리는 변경되지 않음
• 원격 브랜치 정보만 업데이트
• 안전한 방식

• 명령어: git fetch origin main
• 이후 작업: 수동으로 git merge 또는 git rebase 필요

Pull 명령어

• 기능: Fetch + Merge (또는 Rebase)를 한 번에 수행
• 원격 변경사항을 받아서 즉시 현재 브랜치에 적용
• 충돌 가능성 있음
• 빠르지만 위험할 수 있음

명령어:

• git pull (기본: fetch + merge)
• git pull --rebase (fetch + rebase)

권장 워크플로우

1. git fetch origin - 원격 변경사항 확인
2. git log 또는 git diff로 변경내용 검토
3. 필요시 git stash로 작업 내용 임시 저장
4. git rebase origin/main - 베이스 업데이트
5. git stash pop - 작업 내용 복원
6. 작업 완료 후 커밋 및 푸시

- 코드리뷰 전 필수 작업

1. Fetch: 원격 메인 브랜치 최신화 확인
2. Rebase: 메인 브랜치 변경사항을 작업 브랜치 베이스로 업데이트
3. 충돌 해결: 충돌 발생 시 로컬에서 해결
4. Push: 충돌 없는 깔끔한 상태로 Push
5. Pull Request: 코드리뷰 요청

 Force Push 사용법

Force Push가 필요한 경우

• 민감정보 커밋 제거: 비밀번호, API 키 등이 실수로 커밋된 경우
• 커밋 히스토리 수정: 이미 푸시한 커밋을 로컬에서 수정한 경우

Force Push 절차

1. 로컬에서 커밋 수정: git reset, git commit --amend 등 사용
2. 강제 푸시: git push --force origin main
3. 주의: 원격의 커밋 히스토리가 덮어씌워짐

 
민감정보 제거 예시

# 문제 커밋 이전으로 리셋
git reset --soft HEAD~1

# 문제 파일 제외하고 다시 커밋
git add a.txt b.txt
git commit -m "Fix: remove sensitive data"

# 강제 푸시
git push --force origin main