Category
Preparing references and filters for this topic. 이 주제의 레퍼런스와 필터를 준비하고 있습니다.
Category Reference
기본 흐름, 브랜치 협업, rebase, remote tracking, conflict 해결, reflog와 bisect까지 Git의 핵심 흐름을 카드형 레퍼런스로 정리합니다.
Search titles, summaries, tags, and subcategories.
Showing 27 cards.
Subcategory
2 cards
단순한 파일 복사 대신 Git을 쓰는 이유를 변경 이력, 복구, 실험 분리, 협업 관점에서 정리하는 입문 카드입니다.
# 파일 복사 방식의 문제
- report-final.docx
- report-final-real.docx
- report-final-real-2.docx
# → 어느 것이 최신인지, 무엇이 달라졌는지 알 수 없다
# Git 방식
- commit으로 변경 시점과 의도를 기록
- branch로 실험을 본선과 분리
- diff로 두 시점의 차이를 정확히 확인
- revert로 특정 변경만 안전하게 되돌리기Git의 핵심 구조인 작업 트리, 스테이징 영역, 커밋의 관계를 이해해 다음 행동을 판단하는 카드입니다.
# 1. 파일 수정 (작업 트리에서만 변경된 상태)
# 2. 다음 커밋에 포함할 변경을 선택
git add app.js
# 3. 스테이징된 내용을 커밋으로 확정
git commit -m "Refine search input behavior"
# 현재 세 영역의 상태를 확인
git status5 cards
작업 트리와 스테이징 영역의 상태를 읽어 다음에 무엇을 해야 할지 판단하는 Git 기본 카드입니다.
git status
# 보고 판단하기
- Changes not staged for commit
- Changes to be committed
- Untracked files수정한 파일을 스테이징하고 커밋한 뒤 원격으로 올리는 Git의 가장 기본적인 작업 흐름입니다.
git add <file>
git commit -m "의도를 설명하는 메시지"
git push원격 저장소를 처음 가져올 때와 최신 상태를 받아올 때 쓰는 clone, fetch, pull의 차이를 정리합니다.
# 처음 가져올 때
git clone <url>
# 원격 변경만 먼저 확인할 때
git fetch
git log HEAD..origin/main --oneline
# 원격 변경을 받아와 현재 브랜치에 반영할 때
git pull빌드 산출물, 로그, 비밀 정보처럼 추적하지 않을 파일을 .gitignore 패턴으로 관리하는 기본 카드를 정리합니다.
node_modules/
dist/
*.log
.env
!.env.example지금 작업을 잠깐 치워두고 브랜치를 바꾸거나 긴급 수정으로 이동해야 할 때 stash를 어떻게 안전하게 쓰는지 정리합니다.
# 현재 변경을 이름과 함께 임시 저장
git stash push -m "wip: login form validation"
# 다른 브랜치로 이동해 긴급 작업 처리
git switch main
# 원래 브랜치로 돌아와 복원
git switch feature/login
git stash pop7 cards
기능 작업을 별도 브랜치에서 진행하고, 끝나면 기준 브랜치로 합치는 Git 협업의 기본 흐름입니다.
git switch -c feature/login
# 작업 후
git switch main
git merge feature/loginmerge와 rebase가 무엇이 다르고, 내 작업 브랜치를 최신 기준 위에 다시 얹는 rebase를 언제 선택하는지 정리합니다.
git switch feature/login
git fetch origin
git rebase origin/main
# 충돌이 없으면 완료, 충돌 시
# 해결 후 git add <file>
# git rebase --continue충돌이 났을 때 당황하지 않고 상태를 읽고, 파일별로 해결하고, 완료까지 마무리하는 기본 흐름을 정리합니다.
# 1. 충돌 파일 확인
git status
# 2. 파일 안의 충돌 마커를 직접 편집해 최종 내용 결정
# <<<<<<< HEAD
# 현재 브랜치 내용
# =======
# 병합 대상 브랜치 내용
# >>>>>>> feature/login
# 3. 해결 완료 표시
git add <file>
# 4. 진행 계속
git merge --continue # merge 중이었다면
git rebase --continue # rebase 중이었다면내 로컬 브랜치가 어떤 원격 브랜치를 따라가고 있는지와, `origin/main` 같은 remote tracking branch를 어떻게 읽어야 하는지 정리합니다.
git switch -c feature/login --track origin/feature/login
git branch -vv
git push -u origin feature/login브랜치마다 작업 디렉터리를 따로 열어 두고 동시에 여러 작업선을 다루는 `git worktree`의 핵심 개념과 사용 흐름을 정리합니다.
# 새 worktree 추가 (브랜치가 없으면 -b로 생성)
git worktree add ../project-hotfix hotfix/login-bug
# worktree 목록 확인
git worktree list
# 작업 완료 후 worktree 제거
git worktree remove ../project-hotfixpre-commit/commit-msg/pre-push 훅으로 커밋 전 자동 검사를 설정하는 방법, husky와 lefthook으로 팀 전체에 훅을 공유하는 전략을 정리합니다.
# 1. husky 설치 및 초기화
npm install --save-dev husky
npx husky init
# 2. pre-commit 훅 추가 (lint-staged 실행)
echo "npx lint-staged" > .husky/pre-commit
# 3. lint-staged 설정 (package.json)
# "lint-staged": {
# "*.{ts,tsx}": ["eslint --fix", "prettier --write"]
# }
# 4. commit-msg 훅으로 메시지 형식 강제
echo 'npx commitlint --edit "$1"' > .husky/commit-msggit submodule로 외부 저장소를 프로젝트에 포함하는 방법, detached HEAD 함정, 서브모듈 업데이트 흐름과 git subtree 대안을 정리합니다.
# 서브모듈 추가
git submodule add https://github.com/org/shared-lib libs/shared-lib
# 저장소 클론 후 서브모듈 초기화 및 체크아웃
git clone https://github.com/org/my-project
git submodule update --init --recursive
# 서브모듈을 최신 커밋으로 업데이트
git submodule update --remote --merge
# 상위 저장소에 서브모듈 포인터 변경 반영
git add libs/shared-lib
git commit -m "chore: shared-lib 최신 버전으로 업데이트"7 cards
커밋 히스토리와 실제 변경 줄을 읽어 무엇이 언제 어떻게 바뀌었는지 추적하는 Git 기본 카드입니다.
git log --oneline --graph --decorate
git diff
git diff --staged과거 상태로 되돌리고 싶을 때 히스토리를 다시 쓰는 reset과 이력을 남기며 되돌리는 revert의 차이를 정리합니다.
# 로컬에서 아직 정리 중이면
git reset --soft HEAD~1
# 이미 공유된 커밋을 취소하려면
git revert <commit>다른 브랜치의 커밋 전체가 아니라 필요한 커밋 몇 개만 현재 브랜치로 가져오고 싶을 때 cherry-pick을 어떻게 쓰는지 정리합니다.
git switch release/1.0
git cherry-pick a1b2c3d
# 여러 커밋을 순서대로 적용
git cherry-pick a1b2c3d e4f5g6h
# 범위 지정 (이전 커밋 제외, 이후 커밋 포함)
git cherry-pick a1b2c3d..e4f5g6h특정 커밋을 버전 기준점으로 남기는 tag가 브랜치와 무엇이 다르고, release 흐름에서 어떻게 쓰이는지 정리합니다.
# annotated tag 생성
git tag -a v1.0.0 -m "Release 1.0.0"
# 원격에 tag 전송 (커밋 push와 별개다)
git push origin v1.0.0
# 모든 tag를 원격에 전송
git push origin --tags실수로 브랜치 포인터를 옮기거나 reset으로 커밋이 사라진 것처럼 보일 때, reflog로 최근 이동 기록을 어떻게 되찾는지 정리합니다.
# HEAD 이동 기록 보기
git reflog
# 출력 예시
# abc1234 HEAD@{0}: reset: moving to HEAD~2
# def5678 HEAD@{1}: commit: Add login validation
# ghi9012 HEAD@{2}: commit: Init auth module
# 원하는 시점으로 복구
git reset --hard HEAD@{2}
# 또는 dangling commit에서 새 브랜치 생성
git branch recover-login def5678어느 커밋에서 버그가 들어왔는지 모를 때, 이분 탐색 방식으로 문제 커밋 범위를 빠르게 좁히는 `git bisect` 흐름을 정리합니다.
git bisect start
git bisect bad # 현재 상태가 문제 있음
git bisect good v1.2.0 # 확실히 정상이었던 태그 또는 커밋
# Git이 중간 커밋을 checkout해 줌
# 테스트 후 판정
git bisect good # 또는 git bisect bad
# 원인 커밋이 특정되면 출력됨
git bisect reset # 원래 브랜치로 복귀대형 모노레포에서 필요한 디렉터리만 체크아웃하는 sparse checkout, cone 모드로 성능을 극대화하는 방법, --filter=blob:none과의 조합을 정리합니다.
# 새 저장소를 sparse checkout으로 클론
git clone --filter=blob:none --no-checkout https://github.com/org/monorepo
cd monorepo
# cone 모드 활성화 및 필요한 디렉터리만 지정
git sparse-checkout init --cone
git sparse-checkout set apps/web packages/ui
# 파일 체크아웃
git checkout main6 cards
GitHub 협업 흐름에 잘 맞는 공식 Git GUI 클라이언트인 GitHub Desktop의 성격과 용도를 간단히 소개합니다.
# GitHub Desktop의 기본 작업 흐름
1. File > Clone Repository로 저장소 복제
2. Current Branch에서 New Branch 생성
3. 파일 수정 후 Changes 탭에서 변경 확인
4. 커밋 메시지 작성 후 Commit to <branch>
5. Push origin → Create Pull Request로 PR 열기브랜치 그래프와 세밀한 변경 선택이 강한 Git GUI 클라이언트인 Sourcetree의 성격과 용도를 간단히 소개합니다.
# Sourcetree가 특히 유용한 상황
- 변경된 파일 중 일부 줄(hunk)만 선택해서 커밋
- 브랜치 그래프로 merge·rebase 후 히스토리 검증
- 긴 히스토리에서 특정 파일 변경 이력 추적에디터를 벗어나지 않고 Git 작업을 이어갈 수 있는 VS Code Source Control 기능의 성격과 용도를 간단히 소개합니다.
# VS Code Source Control에서 자주 쓰는 흐름
- 파일 변경 후 Source Control 뷰(Ctrl+Shift+G)에서 diff 확인
- + 버튼으로 파일 stage, 메시지 입력 후 커밋
- 상태 표시줄의 sync 버튼으로 push/pull 처리
- 충돌 발생 시 내장 Merge Editor로 3-way 비교 후 해결시각적인 브랜치 그래프와 다양한 Git 호스트 연동이 강한 GitKraken의 성격과 용도를 간단히 소개합니다.
# GitKraken이 적합한 시나리오
- 여러 원격 호스트(GitHub, GitLab, Bitbucket)를 한 화면에서 관리
- 브랜치 그래프로 merge, rebase 흐름을 시각적으로 추적
- 크로스플랫폼 팀(Windows + macOS + Linux)에서 공통 클라이언트 필요빠르고 가벼운 화면 구성과 강한 diff, rebase 지원으로 인기가 많은 Fork Git 클라이언트의 성격을 간단히 소개합니다.
# Fork의 대표 작업 흐름
1. 저장소 열기 → 브랜치 그래프에서 현재 상태 파악
2. 파일 변경 후 Changes 탭에서 줄 단위 stage 선택
3. 커밋 메시지 작성 후 Commit
4. 좌측 사이드바에서 브랜치 전환 또는 Remote > Push
5. Interactive Rebase로 히스토리 정리GitHub Desktop에서 자주 쓰는 commit, branch, sync 관련 keyboard shortcut을 macOS와 Windows 기준으로 정리합니다.
자주 쓰는 GitHub Desktop shortcut (macOS / Windows)
Push Cmd+P / Ctrl+P
Pull Shift+Cmd+P / Ctrl+Shift+P
New Branch Shift+Cmd+N / Ctrl+Shift+N
Commit Cmd+Enter / Ctrl+Enter
Changes view Cmd+1 / Ctrl+1
History view Cmd+2 / Ctrl+2
Branches list Cmd+B / Ctrl+B