Git 사용법: 명령어, 용어 정리
· 약 92분
본 포스트는 Git 명령어를 중심으로 다룹니다. Git을 처음 접하시는 분들도 쉽게 따라올 수 있도록 기본 개념을 간단히 소개하는 것부터 시작해보려고 합니다.
Git: 더 이상 개발자만의 도구가 아니다!
과거에는 주로 개발자들이 사용하는 전문 도구로 여겨졌던 Git은 이제 블로거, 작가, 그리고 노트 정리를 좋아하는 사람들에게도 필수 도구로 자리 잡고 있습니다.
Git이란?
Git은 간단히 말해 버전 관리 시스템입니다. 컴퓨터 파일의 변경 사항을 기록하고, 필요할 때 특정 시점으로 되돌아갈 수 있게 도와주는 도구입니다. 먼저, Git은 코드나 파일의 변경 내역을 기록하고, 여러 사람이 함께 작업할 때 충돌을 방지하는 버전 관리 시스템입니다. 쉽게 말해, 모든 작업을 안전하게 "저장"하고 "공유"하는 디지털 작업 공간입니다.
예를 들어, 여러분이 소설을 쓰다가 내용이 마음에 들지 않아 "일주일 전 버전으로 되돌리고 싶다" 고 생각할 때, Git은 그런 마법을 가능하게 해줍니다.
요즘은 Obsidian, Logseq 같은 노트 관리 도구와의 조합으로 개인 지식 관리(PKM) 에도 많이 활용되고 있습니다.
초보자 분들은 GUI tool로부터 시작하는걸 권장 드립니다. (Sourcetree, GitKraken, GitHub Desktop, VS Code 등)
Git 개념잡기
Git Workflow
---- Git Workflow ---
[작업 디렉토리 (Working Directory)] 🖥️
|
| 파일 작업 (수정, 추가, 삭제)
| |
| | git add <파일> (변경 사항 스테이징)
| ↓
v
[스테이징 영역 (Staging Area)] 📦
|
| git commit -m "메시지" (변경 사항을 로컬 저장소에 저장)
↓
[로컬 저장소 (Local Repository)] 🏠
|
| git push origin <브랜치> (변경 사항을 원격 저장소로 푸시)
↓
[원격 저장소 (Remote Repository)] 🌍
|
| git pull origin <브랜치> (git fetch + git merge)
↓
[협력자의 로컬 저장소] 🏠
|
| git merge 발생
| |
| | 충돌 해결 (Conflict Resolution, 필요한 경우)
| ↓
v
[협력자의 작업 디렉토리 (Working Directory)] 🖥️
Git 용어정리
| 용어 | 설명 | 사용 예시 |
|---|---|---|
Working Directory | 현재 작업 중인 프로젝트의 디렉터리. Git이 추적하는 파일들이 위치하며 파일을 수정할 수 있는 작업 공간입니다. | git status로 Working Directory의 상태 확인 |
Staging Area | 커밋을 준비하기 위해 변경 사항을 임시로 저장하는 영역. git add 명령어로 파일을 추가합니다. | git add <file> (파일을 Staging Area에 추가) |
Index | Staging Area와 동일 개념으로, Git 내부에서 파일 상태를 추적하기 위한 데이터 구조를 의미합니다. | git ls-files --stage ( Index에 있는 파일 목록 확인) |
Worktree | 하나의 저장소에서 여러 작업 디렉터리를 관리할 수 있는 기능. 여러 브랜치에서 동시에 작업할 때 유용합니다. | git worktree add <path> <branch> (새 작업 디렉터리 추가) |
HEAD | 현재 작업 중인 브랜치의 최신 커밋을 가리키는 포인터. | git checkout main ( HEAD가 main 브랜치를 가리킴) |
Detached HEAD | HEAD가 특정 브랜치가 아닌 특정 커밋을 직접 가리키는 상태. 이 상태에서는 브랜치 없이 커밋이 생성되므로 주의가 필요합니다. | git checkout <commit-hash> ( Detached HEAD 상태로 전환) |
Repository | Git으로 관리되는 프로젝트의 저장소. 로컬 저장소와 원격 저장소로 구분됩니다. | git init (로컬 저장소 생성),git clone <URL> (원격 저장소 복제) |
Commit | 파일의 변경 사항을 저장하는 행위. 각 커밋은 고유한 해시 값으로 식별됩니다. | git commit -m "메시지" |
Branch | 코드의 독립적인 버전을 만드는 것. 기본적으로 main 또는 master 브랜치가 존재합니다. | git branch feature-branch (새 브랜치 생성) |
Checkout | 특정 브랜치나 커밋으로 작업 환경을 전환하는 명령어. | git checkout feature-branch (브랜치 전환) |
Merge | 두 브랜치의 변경 사항을 하나로 합치는 작업. | git merge feature-branch (현재 브랜치에 feature-branch 병합) |
Pull | 원격 저장소의 변경 사항을 로컬 저장소로 가져오고 병합하는 작업. | git pull origin main (원격 main 브랜치의 변경 사항 가져오기) |
Push | 로컬 저장소의 변경 사항을 원격 저장소로 업로드하는 작업. | git push origin feature-branch (원격 저장소에 feature-branch 업로드) |
Fetch | 원격 저장소의 변경 사항을 로컬 저장소로 가져오지만 병합하지는 않습니다. | git fetch origin (원격 저장소의 변경 사항 가져오기) |
Clone | 원격 저장소를 로컬로 복제하는 작업. | git clone https://github.com/user/repo.git |
Fork | 원격 저장소를 자신의 계정으로 복제하는 작업. 주로 오픈소스 프로젝트에 기여할 때 사용됩니다. | GitHub "Fork" 버튼 |
Pull Request (PR) | 자신의 브랜치에서 변경한 내용을 원본 저장소에 병합 요청을 보내는 작업. | GitHub "New Pull Request" 버튼 |
Stash | 작업 중인 변경 사항을 임시로 저장하고 작업 디렉터리를 깨끗하게 만드는 작업. | git stash (변경 사항 임시 저장),git stash pop (임시 저장 내용 복원) |
Rebase | 브랜치의 기반을 다른 커밋으로 재설정하여 커밋 히스토리를 깔끔하게 만드는 작업. | git rebase main (현재 브랜치를 main 브랜치에 리베이스) |
Tag | 특정 커밋에 이름을 붙이는 작업. 주로 버전 릴리즈 시 사용됩니다. | git tag v1.0.0 ( v1.0.0 태그 생성) |
Remote | 원격 저장소 를 가리키는 참조. 일반적으로 origin이라는 이름으로 설정됩니다. | git remote add origin <URL> (원격 저장소 추가) |
Conflict | 두 브랜치를 병합할 때 동일한 파일의 동일한 부분이 수정되어 발생하는 충돌. | 병합 시 충돌이 발생하면 수동으로 해결해야 함 |
Cherry-pick | 특정 커밋을 현재 브랜치에 적용하는 작업. | git cherry-pick <commit-hash> (특정 커밋 적용) |
Reset | 현재 브랜치의 HEAD를 특정 커밋으로 되돌리는 작업. --soft, --mixed, --hard 옵션으로 동작이 달라집니다. | git reset --hard HEAD~1 (이전 커밋으로 완전히 되돌림) |
Revert | 특정 커밋을 취소하는 새로운 커밋을 생성하는 작업. | git revert <commit-hash> (특정 커밋 취소) |
Blame | 파일의 각 줄을 누가 언제 수정했는지 확인하는 작업. | git blame <file> (파일의 수정 이력 확인) |
Log | 커밋 히스토리를 확인하는 작업. | git log (커밋 히스토리 출력) |
Diff | 파일의 변경 사항을 비교하는 작업. | git diff (작업 디렉터리와 스테이징 영역 비교) |
Stage | 변경 사항을 커밋하기 전에 스테이징 영역에 추가하는 작업. | git add <file> (파일을 스테이징 영역에 추가) |
Unstage | 스테이징 영역에서 변경 사항을 제거하는 작업. | git reset <file> (파일을 스테이 징 영역에서 제거) |
Ignore | Git이 추적하지 않을 파일이나 디렉터리를 지정하는 설정. .gitignore 파일에 정의합니다. | .gitignore 파일에 node_modules/ 추가 |
Submodule | 다른 Git 저장소를 현재 프로젝트에 포함시키는 방법. | git submodule add <URL> (서브모듈 추가) |
Bisect | 버그가 발생한 커밋을 이진 탐색으로 찾는 작업. | git bisect start, git bisect bad, git bisect good |
Hooks | Git 작업 중 특정 이벤트가 발생할 때 실행되는 스크립트. .git/hooks 디렉터리에 저장됩니다. | pre-commit, post-commit 등의 훅 스크립트 |
Reflog | Git에서 수행한 모든 작업의 기록을 확인하는 작업. | git reflog (작업 기록 확인) |
Upstream | 원격 저장소의 기본 브랜치를 가리키는 용어. 일반적으로 origin/main 또는 origin/master를 의미합니다. | git push --set-upstream origin feature-branch (업스트림 설정) |
포인터의 중요성
Git은 다양한 개념과 명령어를 기반으로 동작하지만, 그 핵심은 포인터(pointer)를 중심으로 이루어져 있습니다.
Git에서 포인터는 저장소 내의 특정 커밋이나 참조를 가리키는 핵심 메커니즘입니다. 포인터는 커밋의 해시값, 브랜치명, 태 그명 등을 통해 특정 시점의 코드 상태를 참조할 수 있으며, 이를 기반으로 효율적인 버전 관리와 브랜치 관리가 이루어집니다.
1. HEAD 포인터
- 현재 작업 중인 브랜치의 최신 커밋을 가리키는 포인터
.git/HEAD파일에 저장되어 있으며, 해당 파일은 HEAD가 가리키는 브랜치 이름 또는 특정 커밋 해시를 기록함.- 만약 특정 커밋을 직접 체크아웃하면,
HEAD는 "분리된 상태(Detached HEAD)"가 됨. 이 경우HEAD는 브랜치 대신 커밋 해시를 직접 가리킴.(ref: refs/heads/main->88f4bc..)
HEAD 표현법
HEAD와 관련된 커밋을 참조할 때는 ^와 ~ 기호를 사용합니다.
HEAD^: HEAD가 가리키는 커밋의 직전 부모 커밋을 참조합니다.HEAD^: 첫 번째 부모 커밋HEAD^^: 두 세대 전의 커밋HEAD^2: 두 번째 부모 커밋 (병합 커밋에서 유용)
HEAD~: HEAD가 가리키는 커밋에서 첫 번째 부모를 기준으로 몇 세대 이전의 커밋을 참조합니다.HEAD~: 첫 번째 부모 커밋HEAD~2: 두 세대 전의 커밋HEAD~10: 10 세대 전의 커밋
HEAD^와 HEAD~의 차이점
- 단일 부모를 가진 커밋의 경우,
HEAD^와HEAD~는 동일한 커밋을 참조합니다. - 병합 커밋의 경우:
HEAD^: 첫 번째 부모 커밋을 참조하며,HEAD^2는 두 번째 부모를 참조합니다.HEAD~: 항상 첫 번째 부모를 기준으로 세대를 거슬러 올라갑니다.
차이를 보기 위하여 아래와 같은 예시를 보겠습니다.
브랜치 feature가 브랜치 main에 병합되면서 병합 커밋 M이 생성된 상황입니다.
A---B---C---M (main)
\ /
D---E (feature)
-
git show HEAD^2HEAD는 현재 커밋M을 가리키며,HEAD^2는 병합 커밋M의 두 번째 부모 커밋인E를 참조합니다.
-
git show HEAD~2HEAD~2는HEAD에서 첫 번째 부모를 두 번 거슬러 올라간 커밋, 즉B를 참조합니다.
2. 브랜치 포인터
- 각 브랜치의 최신 커밋을 가리키는 포인터
.git/refs/heads/디렉터리에 브랜치별로 저장- 새로운 커밋이 생성되면 브랜치 포인터가 자동으로 이동
3. 태그 포인터
- 특정 커밋을 영구적으로 가리키는 포인터
.git/refs/tags/디렉터리에 저장- 태그가 특정 커밋을 안정적으로 가리키기 위한 목적으로 사용됨, 하여 일반적으로 한번 생성되면 변경되지 않음.
4. 원격 브랜치 포인터
- 원격 저장소의 브랜치를 가리키는 포인터
.git/refs/remotes/디렉터리에 저장fetch명령으로 업데이트됨
이러한 포인터들은 Git의 핵심 메커니즘으로, 버전 관리와 브랜치 관리의 기반이 됩니다. 특히 HEAD 포인터는 현재 작업 중인 위치를 나타내는 중요한 역할을 하며, 브랜치 포인터와 함께 Git의 분산 버전 관리 시스템을 가능하게 합니다.
Git 명령어
1. 저장소 설정
git config
git config는 Git의 설정을 관리하는 명령어입니다. 이 명령어를 사용하여 사용자 이름, 이메일, 에디터, 별칭 등을 설정하거나 확인할 수 있습니다. 설정은 전역(global), 로컬(local), 시스템(system) 레벨에서 관리됩니다.
Git config 파일의 종류:
system설정 파일: 모든 사용자에게 적용 (많이 사용되지 않음)- macOS/Linux:
/etc/gitconfig,macOS 같은 경우 Homebrew로 설치시/usr/local/etc/gitconfig에 위치하기도 함. - Windows:
C:\Program Files\Git\etc\gitconfig
- macOS/Linux:
global설정 파일: 사용자 전체에 적용,~/.gitconfig에 위치.local설정파일: 특정 저장소에만 적용,<repo>/.git/config에 위치하.
-e 옵션으로 config 파일 위치 확인가능(예:git config --global -e)
global 설정 vs. local 설정: 일반적으로 사용자 정보는 전역 설정으로, 프로젝트별 설정은 로컬 설정으로 관리합니다.
config 우선순위: local 설정 > global 설정 > system 설정 순으로 우선순위가 적용됩니다.
| 명령어 및 옵션 | 설명 |
|---|---|
git config --list | 현재 적용된 모든 설정을 확인. |
git config --global | 전역 설정을 관리. (사용자 전체에 적용) |
git config --local | 로컬 설정을 관리. (현재 저장소에만 적용) |
git config --get <key> | 특정 설정 값을 확인. |
git config --add <key> <value> | 새로운 설정을 추가. |
git config --unset <key> | 특정 설정을 삭제. |
git config --edit 또는 -e | 설정 파일을 편집기로 열어 수정. |
git config --show-origin | 설정 값의 출처를 확인. |
사용예시:
# 현재 적용된 모든 설정 확인
git config --list
# 전역 설정 확인
git config --global --list
# 전역 설정에 사용자 이름 추가
git config --global user.name "John Doe"
# 전역 설정에 사용자 이메일 추가
git config --global user.email "john@example.com"
# 특정 설정 값 확인 (예: 사용자 이름)
git config --get user.name
# 특정 설정 삭제 (예: 사용자 이름)
git config --global --unset user.name
# 설정 파일 편집기로 열기
git config --global --edit
# 설정 값의 출처 확인
git config --show-origin user.name
git alias
git alias는 자주 사용하는 긴 명령어를 짧은 별칭으로 설정하여 편리하게 사용할 수 있도록 도와주는 기능입니다.git config 명령어를 통해 설정하거나, .gitconfig 파일을 직접 편집하여 설정할 수 있습니다.
1. git config를 사용하여 alias 설정하기
# alias 설정 (자주 사용하는 alias)
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.unstage 'reset HEAD --' # 스테이징 영역에서 파일 제거
git config --global alias.last 'log -1 HEAD' # 마지막 커밋 확인
git config --global alias.amend 'commit --amend' # 마지막 커밋 수정
# alias 확인
git config --get-regexp alias
# alias 삭제
git config --global --unset alias.<별칭>
# 사용 예시
git co main # `git checkout main`과 동일
git br # `git branch`와 동일
git ci -m "메시지" # `git commit -m "메시지"`와 동일
git st # `git status`와 동일
git unstage file.txt # `git reset HEAD file.txt`와 동일
git last # `git log -1 HEAD`와 동일
git amend # `git commit --amend`와 동일
2. .gitconfig 파일을 직접 편집하여 alias 설정하기
.gitconfig 파일을 직접 편집하여 alias를 설정할 수도 있습니다. .gitconfig 파일은 일반적으로 사용자의 홈 디렉토리(~/.gitconfig)에 위치합니다.
[alias]
co = checkout
br = branch
ci = commit
st = status
last = log -1 HEAD
lg = log --oneline --graph --decorate --all
2. 저장소 초기화 및 클론
git저장소를 만드는 방식에는 아래와 같이 git init, git clone 2가지 방식이 있습니다.
git init
git init은 새로운 Git 저장소를 초기화하는 명령어입니다. 이 명령어는 현재 디렉토리 또는 지정한 디렉토리에 .git이라는 숨겨진 하위 디렉토리를 생성하여 Git 저장소로 만듭니다.
| 명령어 및 옵션 | 설명 |
|---|---|
git init | 현재 디렉토리에 새로운 Git 저장소를 초기화. |
git init <directory> | 지정한 디렉토리에 새로운 Git 저장소를 초기화. |
git init --bare | 작업 디렉토리 없이 베어 저장소를 초기화. |
git init --quiet | 초기화 과정에서 출력을 최소화. |
git init --initial-branch <name> | 초기 브랜치 이름을 지정. (기본값: main) |
사용예시:
# 현재 디렉토리에 새로운 Git 저장소 초기화
git init
# 지정한 디렉토리에 새로운 Git 저장소 초기화
git init my-repo
# 작업 디렉토리 없이 베어 저장소 초기화
git init --bare
# 초기화 과정에서 출력 최소화
git init --quiet
# 초기 브랜치 이름을 지정하여 초기화
git init --initial-branch develop
git clone
git clone은 Git 버전 관리 시스템에서 원격 저장소(remote repository)에서 로컬 저장소(local repository)로 프로젝트를 복제하는 명령어입니다. 이 명령어는 원격 저장소의 전체 히스토리와 파일을 로컬 저장소로 가져오는 데 사용됩니다.
| 명령어 및 옵션 | 설명 |
|---|---|
git clone <repository> | 원격 저장소를 로컬로 복제. |
git clone <repository> <directory> | 원격 저장소를 지정한 디렉토리에 복제. |
git clone --branch <branch> | 특정 브랜치를 복제. |
git clone --depth <depth> | 특정 깊이만큼의 커밋 히스토리만 복제. (얕은 복제) |
git clone --single-branch | 특정 브랜치만 복제. |
git clone --recurse-submodules | 서브모듈을 포함하여 복제. |
git clone --bare | 작업 디렉토리 없이 복제. (베어 저장소) |
git clone --mirror | 원격 저장소를 미러링하여 복제. |
사용예시:
# 기본적인 복제
git clone https://github.com/user/repo.git
# 지정한 디렉토리에 복제
git clone https://github.com/user/repo.git my-directory
# 특정 브랜치만 복제
git clone --single-branch --branch main https://github.com/user/repo.git
# 얕은 복제
git clone --depth 1 https://github.com/user/repo.git
# 서브모듈 포함하여 복제
git clone --recurse-submodules https://github.com/user/repo.git
# 작업 디렉토리 없이 베어 저장소로 복제
git clone --bare https://github.com/user/repo.git
# 원격 저장소를 미러링하여 복제
git clone --mirror https://github.com/user/repo.git
3. 변경 사항 추적 및 관리
git status
git status는 현재 작업 디렉토리와 스테이징 영역의 상태를 보여주는 Git 명령어입니다. 즉, 어떤 파일들이 변경되었는지, 변경된 파일들이 커밋될 준비가 되었는지 등을 한눈에 확인할 수 있습니다.
git status 상태값 설명:
git status 상태 | 설명 | 추적 상태 | 파일 상태 |
|---|---|---|---|
| Untracked | Git이 추적하지 않는 새로운 파일. (git add로 스테이징 가능) | Untracked | - |
| Modified | Git이 추적 중인 파일이 수정되었으나 스테이징되지 않음. | Tracked | Modified |
| Staged | 변경 사항이 스테이징 영역에 추가된 파일. (git commit으로 커밋 가능) | Tracked | Staged |
| Unstaged | 변경 사항이 작업 디렉토리에 있으나 스테이징되지 않음. | Tracked | Unstaged |
| Deleted | Git이 추적 중인 파일이 삭제됨. (git rm으로 삭제를 스테이징 가능) | Tracked | Deleted |
| Renamed | 이름이 변경된 파일. (git mv 또는 수동 변경 후 스테이징 필요) | Tracked | Renamed |
| Copied | 기존 파일을 복사한 새 파일. (git add로 스테이징 가능) | Tracked | Copied |
| Unmerged | 충돌이 발생한 파일. (충돌 해결 후 git add 필요) | Tracked | Unmerged |
| Ignored | .gitignore에 의해 무시된 파일. (git status --ignored로 확인 가능) | Ignored | - |
git status 옵션:
| 명령어 및 옵션 | 설명 |
|---|---|
git status | 작업 디렉토리와 스테이징 영역의 상태를 확인. |
git status -s 또는 --short | 상태 정보를 짧은 형식으로 확인. |
git status --branch | 브랜치 정보를 함께 확인. |
git status --untracked-files 또는 -u | 추적되지 않은 파일의 상태를 확인. (예: no, normal, all) |
git status --verbose | 상태 정보를 상세히 확인. |
사용예시:
# 기본 상태 확인
git status
# 짧은 형식으로 상태 확인
git status -s
# 브랜치 정보 확인
git status --branch
# 추적되지 않은 파일의 상태 확인
git status --untracked-files=all
# 상세한 상태 정보 확인
git status --verbose
git add
git add는 작업 디렉토리의 변경 사항을 스테이징 영역(staging area)에 추가하는 명령어입니다. 이 명령어는 커밋할 파일을 준비하는 데 사용되며, 변경 사항을 Git이 추적할 수 있도록 합니다.
| 명령어 및 옵션 | 설명 |
|---|---|
git add <file> | 특정 파일을 스테이징 영역에 추가. |
git add . | 현재 디렉토리의 모든 변경 사항을 스테이징 영역에 추가. |
git add -A | 작업 디렉토리의 모든 변경 사항을 스테이징 영역에 추가. |
git add -u | 추적 중인 파일의 변경 사항만 스테이징 영역에 추가. |
git add --patch 또는 -p | 변경 사항을 인터랙티브하게 선택하여 스테이징 영역에 추가. |
git add --force 또는 -f | 무시된 파일도 강제로 스테이징 영역에 추가. |
사용예시:
# 특정 파일을 스테이징 영역에 추가
git add file.txt
# 현재 디렉토리의 모든 변경 사항을 스테이징 영역에 추가
git add .
# 작업 디렉토리의 모든 변경 사항을 스테이징 영역에 추가
git add -A
# 추적 중인 파일의 변경 사항만 스테이징 영역에 추가
git add -u
# 변경 사항을 인터랙티브하게 선택하여 스테이징 영역에 추가
git add --patch
# 무시된 파일도 강제로 스테이징 영역에 추가
git add --force
git diff
git diff는 Git에서 변경 사항을 비교하는 명령어입니다. 이 명령어는 작업 디렉토리, 스테이징 영역, 커밋 간의 차이를 확인할 때 사용됩니다. 파일의 추가, 삭제, 수정 사항을 라인 단위로 보여줍니다.
| 명령어 및 옵션 | 설명 |
|---|---|
git diff | 작업 디렉토리와 스테이징 영역의 차이를 확인. |
git diff --cached | 스테이징 영역과 최신 커밋의 차이를 확인. |
git diff HEAD | 작업 디렉토리와 최신 커밋의 차이를 확인. |
git diff <commit> | 작업 디렉토리와 특정 커밋의 차이를 확인. |
git diff <commit1> <commit2> | 두 커밋 간의 차이를 확인. |
git diff --stat | 변경된 파일의 통계를 확인. |
git diff --name-only | 변경된 파일의 이름만 확인. |
git diff --name-status | 변경된 파일의 이름과 상태(추가, 수정, 삭제 등)를 확인. |
git diff --color | 출력에 색상을 적용. |
git diff --word-diff | 단어 단위로 차이를 확인. |
git diff --ignore-space-change | 공백 변경을 무시하고 차이를 확인. |
git diff --diff-filter=<filter> | 특정 상태의 파일만 확인. (예: A 추가, M 수정, D 삭제) |
git diff --check | 공백 오류를 검사. |
git diff --quiet | 차이가 있는지 여부만 확인. (출력 없음) |
사용예시:
# 작업 디렉토리와 스테이징 영역의 차이 확인
git diff
# 스테이징 영역과 최신 커밋의 차이 확인
git diff --cached
# 작업 디렉토리와 최신 커밋의 차이 확인
git diff HEAD
# 작업 디렉토리와 특정 커밋의 차이 확인
git diff abc1234
# 두 커밋 간의 차이 확인
git diff abc1234 def5678
# 변경된 파일의 통계 확인
git diff --stat
# 변경된 파일의 이름만 확인
git diff --name-only
# 변경된 파일의 이름과 상태 확인
git diff --name-status
# 출력에 색상 적용
git diff --color
# 단어 단위로 차이 확인
git diff --word-diff
# 공백 변경을 무시하고 차이 확인
git diff --ignore-space-change
# 특정 상태의 파일만 확인 (예: 추가된 파일)
git diff --diff-filter=A
# 공백 오류 검사
git diff --check
# 차이가 있는지 여부만 확인 (출력 없음)
git diff --quiet
git stash
git stash는 작업 중인 변경 사항을 임시로 저장하는 명령어입니다. 현재 작업 디렉토리의 변경 사항을 스택에 저장하고, 깨끗한 상태로 만들어 다른 작업을 수행할 수 있습니다. 나중에 저장한 변경 사항을 다시 적용할 수 있습니다.
- git stash는 작업 디렉토리의 변경 사항을 스택에 저장합니다.
- 스태시는 여러 개 저장할 수 있으며, 각 스태시는 고유한 식별자(
stash@{n})를 가집니다.
| 명령어 및 옵션 | 설명 |
|---|---|
git stash | 작업 중인 변경 사항을 임시로 저장. |
git stash save "<message>" | 메시지와 함께 변경 사항을 임시로 저장. |
git stash list | 저장된 스태시 목록을 확인. |
git stash apply | 가장 최근의 스태시를 적용. |
git stash apply <stash> | 특정 스태시를 적용. |
git stash pop | 가장 최근의 스태시를 적용하고 스택에서 제거. |
git stash drop | 가장 최근의 스태시를 스택에서 제거. |
git stash clear | 모든 스태시를 스택에서 제거. |
git stash show | 가장 최근의 스태시의 변경 사항을 확인. |
git stash show -p | 가장 최근의 스태시의 변경 사항을 패치 형식으로 확인. |
git stash --include-untracked | 추적되지 않은 파일도 함께 스태시에 저장. |
사용 예시:
# 작업 중인 변경 사항을 임시로 저장
git stash
# 메시지와 함께 변경 사항을 임시로 저장
git stash save "WIP: Working on feature X"
# 저장된 스태시 목록 확인
git stash list
# 가장 최근의 스태시 적용
git stash apply
# 특정 스태시 적용
git stash apply stash@{1}
# 가장 최근의 스태시 적용 및 스택에서 제거
git stash pop
# 가장 최근의 스태시 스택에서 제거
git stash drop
# 모든 스태시 스택에서 제거
git stash clear
# 가장 최근의 스태시의 변경 사항 확인
git stash show
# 가장 최근의 스태시의 변경 사항을 패치 형식으로 확인
git stash show -p
# 추적되지 않은 파일도 함께 스태시에 저장
git stash --include-untracked
git commit
git commit은 스테이징 영역(staging area)에 있는 파일 변경 사항을 로컬 저장소에 저장하는 명령어입니다. 한 번의 커밋은 변경 사항의 논리적 단위를 의미하며, 작업의 스냅샷으로 볼수 있습니다.
commit의 구성 요소:
- 커밋 해시 (Commit Hash): 커밋을 고유하게 식별하는 40자리의 SHA-1 해시 값.
- 해시 값은 커밋의 내용(변경 사항, 작성자, 날짜 등)을 기반으로 생성됨.
- 트리 객체 (Tree Object): 커밋 시점의 작업 디렉토리 구조를 나타내는 객체입니다.
- 트리 객체는 파일과 디렉토리의 구조를 저장하며, 각 파일의 해시 값을 포함.
- 이를 통해 커밋 시점의 파일 상태를 재구성할 수 있음.
- 부모 커밋 (Parent Commit): 현재 커밋의 이전 커밋(부모 커밋)을 가리키는 해시 값.
- 일반적으로 하나의 부모 커밋을 가지지만, 머지 커밋의 경우 두 개 이상의 부모 커밋을 가질 수 있음.
- 부모 커밋을 통해 커밋 히스토리를 추적 가능.
- 작성자 (Author): 커밋을 만든 사람의 이름과 이메일.
- 커미터 (Committer): 커밋을 실제로 저장소에 기록한 사람의 이름과 이메일. (작성자와 커미터가 다른 경 우가 있음)
- 커밋 날짜 (Commit Date): 커밋이 생성된 날짜와 시간.
- 커밋 메시지 (Commit Message): 커밋의 변경 사항에 대한 기술.
- GPG 서명 (GPG Signature) (선택 사항): 커밋에 GPG 서명을 추가하여(
--gpg-sign옵션 사용) 커밋의 무결성(변조 여부)을 보장 가능.
| 명령어 및 옵션 | 설명 |
|---|---|
git commit | 스테이징 영역의 변경 사항을 커밋. (커밋 메시지 편집기 열림) |
git commit -m "<message>" | 커밋 메시지를 직접 입력하여 커밋. |
git commit -a | 추적 중인 파일의 변경 사항을 자동으로 스테이징하고 커밋. |
git commit --amend | 최신 커밋을 수정. (커밋 메시지 변경 또는 파일 추가) |
git commit --no-verify | 커밋 전 후크(hook) 스크립트를 실행하지 않음. |
git commit --allow-empty | 빈 커밋을 생성. (변경 사항 없이 커밋) |
git commit --signoff | 커밋 메시지에 Signed-off-by 줄을 추가. |
git commit --no-edit | 커밋 메시지를 수정하지 않고 --amend를 수행. |
git commit --fixup=<commit> | 특정 커밋을 수정하기 위한 커밋을 생성. (rebase --autosquash와 함께 사용) |
git commit --squash=<commit> | 특정 커밋과 병합하기 위한 커밋을 생성. (rebase --autosquash와 함께 사용) |
사용예시:
# 스테이징 영역의 변경 사항을 커밋 (커밋 메시지 편집기 열림)
git commit
# 커밋 메시지를 직접 입력하여 커밋
git commit -m "Add new feature"
# 추적 중인 파일의 변경 사항을 자동으로 스테이징하고 커밋
git commit -a -m "Update tracked files"
# 최신 커밋을 수정 (커밋 메시지 변경 또는 파일 추가)
git commit --amend
# 커밋 전 후크(hook) 스크립트를 실행하지 않음
git commit --no-verify -m "Bypass hooks"
# 빈 커밋 생 성 (변경 사항 없이 커밋)
git commit --allow-empty -m "Empty commit"
# 커밋 메시지에 Signed-off-by 줄 추가
git commit --signoff -m "Add signoff"
# 커밋 메시지를 수정하지 않고 --amend 수행
git commit --amend --no-edit
# 특정 커밋을 수정하기 위한 커밋 생성
git commit --fixup=abc1234
# 특정 커밋과 병합하기 위한 커밋 생성
git commit --squash=abc1234
git log
git log는 Git 저장소의 커밋 히스토리를 확인하는 명령어입니다. 이 명령어는 커밋의 해시, 작성자, 날짜, 커밋 메시지 등을 확인할 때 사용됩니다.
| 명령어 및 옵션 | 설명 |
|---|---|
git log | 커밋 히스토리를 확인. |
git log -n <number> | 최근 N개의 커밋만 확인. |
git log --oneline | 커밋 정보를 한 줄로 간단히 확인. |
git log --stat | 커밋에서 변경된 파일의 통계를 확인. |
git log --patch 또는 -p | 커밋에서 변경된 내용을 패치 형식으로 확인. |
git log --graph | 커밋 히스토리를 그래프 형식으로 확인. |
git log --pretty=<format> | 커밋 정보를 예쁘게(pretty) 출력. (예: oneline, short, full, fuller) |
git log --since=<date> | 특정 날짜 이후의 커밋만 확인. (예: 2023-10-01, 2.weeks.ago) |
git log --until=<date> | 특정 날짜 이전의 커밋만 확인. (예: 2023-10-31, 1.day.ago) |
git log --author=<pattern> | 특정 작성자의 커밋만 확인. |
git log --grep=<pattern> | 커밋 메시지에서 특정 패턴과 일치하는 커밋만 확인. |
git log -- <path> | 특정 파일 또는 디렉토리의 커밋 히스토리만 확인. |
git log --no-merges | 머지 커밋을 제외하고 확인. |
git log --decorate | 브랜치와 태그 정보를 함께 확인. |
git log --abbrev-commit | 커밋 해시를 짧게 표시. |
git log --name-only | 변경된 파일의 이름만 확인. |
git log --name-status | 변경된 파일의 이름과 상태(추가, 수정, 삭제 등)를 확인. |
git log --all | 모든 참조(브랜치, 태그 등)의 커밋 히스토리를 확인. |
사용예시:
# 커밋 히스토리 확인
git log
# 최근 5개의 커밋만 확인
git log -n 5
# 커밋 정보를 한 줄로 간단히 확인
git log --oneline
# 커밋에서 변경된 파일의 통계 확인
git log --stat
# 커밋에서 변경된 내용을 패치 형식으로 확인
git log --patch
# 커밋 히스토리를 그래프 형식으로 확인
git log --graph
# 커밋 정보를 예쁘게(pretty) 출력
git log --pretty=oneline
# 특정 날짜 이후의 커밋만 확인 (예: 2023-10-01 이후)
git log --since="2023-10-01"
# 특정 날짜 이전의 커밋만 확인 (예: 2023-10-31 이전)
git log --until="2023-10-31"
# 특정 작성자의 커밋만 확인 (예: 작성자 이름이 "John")
git log --author="John"
# 커밋 메시지에서 특정 패턴과 일치하는 커밋만 확인 (예: "bugfix")
git log --grep="bugfix"
# 특정 파일 또는 디렉토리의 커밋 히스토리만 확인 (예: src/main.c)
git log -- src/main.c
# 머지 커밋을 제외하고 확인
git log --no-merges
# 브랜치와 태그 정보를 함께 확인
git log --decorate
# 커밋 해시를 짧게 표시
git log --abbrev-commit
# 변경된 파일의 이름만 확인
git log --name-only
# 변경된 파일의 이름과 상태 확인
git log --name-status
# 모든 참조(브랜치, 태그 등)의 커밋 히스토리 확인
git log --all
git show
git show는 특정 커밋, 태그, 또는 트리의 상세 정보를 보여주는 명령어입니다. 이 명령어는 커밋의 변경 사항, 작성자, 날짜, 커밋 메시지 등을 확인할 때 유용합니다.
| 명령어 및 옵션 | 설명 |
|---|---|
git show <commit> | 특정 커밋의 상세 정보를 보여줌. |
git show <tag> | 특정 태그가 가리키는 커밋의 상세 정보를 보여줌. |
git show <tree> | 특정 트리의 상세 정보를 보여줌. |
git show --oneline | 커밋 정보를 한 줄로 간단히 보여줌. |
git show --stat | 커밋에서 변경된 파일의 통계를 보여줌. |
git show --patch 또는 -p | 커밋에서 변경된 내용을 패치 형식으로 보여줌. |
git show --name-only | 변경된 파일의 이름만 보여줌. |
git show --name-status | 변경된 파일의 이름과 상태(추가, 수정, 삭제 등)를 보여줌. |
git show --format=<format> | 커밋 정보를 사용자 정의 형식으로 출력. |
git show --no-patch | 패치 정보를 표시하지 않음. |
git show --color | 출력에 색상을 적용. |
git show --quiet | 커밋 메시지만 출력하고 다른 정보는 생략. |
사용예시:
# 특정 커밋의 상세 정보 보기
git show abc1234
# 특정 태그가 가리키는 커밋의 상세 정보 보기
git show v1.0.0
# 특정 트리의 상세 정보 보기
git show HEAD:path/to/file
# 커밋 정보를 한 줄로 간단히 보기
git show --oneline abc1234
# 커밋에서 변경된 파일의 통계 보기
git show --stat abc1234
# 커밋에서 변경된 내용을 패치 형식으로 보기
git show --patch abc1234
# 변경된 파일의 이름만 보기
git show --name-only abc1234
# 변경된 파 일의 이름과 상태 보기
git show --name-status abc1234
# 커밋 정보를 사용자 정의 형식으로 출력
git show --format="%h - %an, %ar : %s" abc1234
# 패치 정보 없이 커밋 메시지만 보기
git show --no-patch abc1234
# 출력에 색상 적용
git show --color abc1234
# 커밋 메시지만 출력
git show --quiet abc1234
5. 브랜치 관리
git branch
git branch는 Git에서 브랜치를 생성, 조회, 삭제하는 명령어입니다. 브랜치는 작업을 분리하고 병합하는 데 필수적인 기능으로, git branch를 통해 브랜치를 효과적으로 관리할 수 있습니다.
| 명령어 및 옵션 | 설명 |
|---|---|
git branch | 로컬 브랜치 목록을 확인. |
git branch <branch> | 새로운 브랜치를 생성. |
git branch -d <branch> | 브랜치를 삭제. (병합된 브랜치만 삭제 가능) |
git branch -D <branch> | 브랜치를 강제 삭제. (병합되지 않은 브랜치도 삭제 가능) |
git branch -m <new-branch> | 현재 브랜치의 이름을 변경. |
git branch -a | 모든 브랜치(로컬 + 원격)를 확인. |
git branch -r | 원격 브랜치 목록을 확인. |
git branch --merged | 현재 브랜치에 병합된 브랜치 목록을 확인. |
git branch --no-merged | 현재 브랜치에 병합되지 않은 브랜치 목록을 확인. |
git branch --set-upstream-to=<remote>/<branch> | 현재 브랜치의 업스트림(추적 브랜치)을 설정. |
git branch --unset-upstream | 현재 브랜치의 업스트림(추적 브랜치) 설정을 해제. |
git branch --verbose 또는 -v | 각 브랜치의 최신 커밋 메시지와 함께 브랜치 목록을 확인. |
사용 예시:
# 로컬 브랜치 목록 확인
git branch
# 새로운 브랜치 생성
git branch feature-branch
# 브랜치 삭제 (병합된 브랜치만 삭제 가능)
git branch -d feature-branch
# 브랜치 강제 삭제 (병합되지 않은 브랜치도 삭제 가능)
git branch -D feature-branch
# 현재 브랜치의 이름 변경
git branch -m new-branch-name
# 모든 브랜치(로컬 + 원격) 확인
git branch -a
# 원격 브랜치 목록 확인
git branch -r
# 현재 브랜치에 병합된 브랜치 목록 확인
git branch --merged
# 현재 브랜치에 병합되지 않은 브랜치 목록 확인
git branch --no-merged
# 현재 브랜치의 업스트림 설정
git branch --set-upstream-to=origin/main
# 현재 브랜치의 업스트림 설정 해제
git branch --unset-upstream
# 각 브랜치의 최신 커밋 메시지와 함께 브랜치 목록 확인
git branch --verbose
git checkout
git checkout은 Git에서 브랜치를 전환하거나, 특정 커밋이나 파일로 작업 디렉토리를 되돌리는 데 사용되는 명령어입니다. 브랜치 전환, 파일 상태 복원, 커밋 체크아웃 등 다양한 작업에 활용됩니다.
현재는 git --help에도 조회가 안되지만 많이들 사용하는 명령입니다.
The git-checkout(1) command is seen by many as hard to understand because it connects two somewhat unrelated features: switching between branches and restoring worktree files from arbitrary revisions. In 2019, we thus implemented two new commands git-switch(1) and git-restore(1) to split out these separate concerns into standalone functions. (참고: Commit 028bb23)
명령어 하나로 브랜치 전환, 파일 복구 두 무관한 기능이 연결된다는게 사용자한테 혼란을 주고있다는 얘기입니다.
그래서 Git 2.23 이후로 git checkout 명령어는, 아래서 나오는 git-switch, git-restore 두 명령어로 분리가 되었습니다.
그래도 아직까지 광범위하게 사용되고 있는 관계로 deprecate계획은 없다고 하죠.
| 명령어 및 옵션 | 설명 |
|---|---|
git checkout <branch> | 특정 브랜치로 전환. |
git checkout -b <new-branch> | 새로운 브랜치를 생성하고 전환. |
git checkout <commit> | 특정 커밋으로 작업 디렉토리를 이동. (Detached HEAD 상태) |
git checkout -- <file> | 작업 디렉토리의 특정 파일을 최신 커밋 상태로 되돌림. |
git checkout . | 작업 디렉토리의 모든 변경 사항을 최신 커밋 상태로 되돌림. |
git checkout -f | 강제로 작업 디렉토리를 최신 커밋 상태로 되돌림. (변경 사항 무시) |
git checkout --patch 또는 -p | 변경 사항을 인터랙티브하게 선택하여 되돌림. |
git checkout --track <remote>/<branch> | 원격 브랜치를 추적하는 로컬 브랜치를 생성하고 전환. |
git checkout --detach | 현재 브랜치를 Detached HEAD 상태로 전환. |
git checkout --merge | 브랜치 전환 시 충돌이 발생하면 자동으로 병합을 시도. |
사용 예시:
# 특정 브랜치로 전환
git checkout main
# 새로운 브랜치 생성 및 전환
git checkout -b feature-branch
# 특정 커밋으로 이동 (Detached HEAD 상태)
git checkout abc1234
# 작업 디렉토리의 특정 파일을 최신 커밋 상태로 되돌리기
git checkout -- file.txt
# 작업 디렉토리의 모든 변경 사항을 최신 커밋 상태로 되돌리기
git checkout .
# 강제로 작업 디렉토리를 최신 커밋 상태로 되돌리기
git checkout -f
# 변경 사항을 인터랙티브하게 선택하여 되돌리기
git checkout --patch
# 원격 브랜치를 추적하는 로컬 브랜치 생성 및 전환
git checkout --track origin/feature-branch
# 현재 브랜치를 Detached HEAD 상태로 전환
git checkout --detach
# 브랜치 전환 시 충돌이 발생하면 자동으로 병합 시도
git checkout --merge feature-branch
git switch
git switch는 Git 2.23 버전부터 도입된 명령어로, git checkout의 브랜치 전환 기능을 더 명확하게 분리한 명령어입니다. git switch는 브랜치 전환에 특화되어 있으며, git checkout보다 더 직관적이고 안전하게 사용할 수 있습니다.
| 명령어 및 옵션 | 설명 |
|---|---|
git switch <branch> | 특정 브랜치로 전환. |
git switch -c <new-branch> | 새로운 브랜치를 생성하고 전환. |
git switch --detach <commit> | 특정 커밋으로 작업 디렉토리를 이동. (Detached HEAD 상태) |
git switch --track <remote>/<branch> | 원격 브랜치를 추적하는 로컬 브랜치를 생성하고 전환. |
git switch --force | 충돌이 발생해도 강제로 브랜치를 전환. |
git switch --merge | 브랜치 전환 시 충돌이 발생하면 자동으로 병합을 시도. |
사용예시:
# 특정 브랜치로 전환
git switch main
# 새로운 브랜치 생성 및 전환
git switch -c feature-branch
# 특정 커밋으로 이동 (Detached HEAD 상태)
git switch --detach abc1234
# 원격 브랜치를 추적하는 로컬 브랜치 생성 및 전환
git switch --track origin/feature-branch
# 충돌이 발생해도 강제로 브랜치 전환
git switch --force feature-branch
# 브랜치 전환 시 충돌이 발생하면 자동으로 병합 시도
git switch --merge feature-branch
git merge
git merge는 두 브랜치의 변경 사항을 하나로 합치는 명령어입니다. 주로 기능 개발이 완료된 브랜치를 메인 브랜치에 병합할 때 사용됩니다. 병합은 Fast-forward, 3-way merge, Conflict Resolution(충돌해결) 등 다양한 방식으로 이루어질 수 있습니다.
병합 방식:
| 병합 방식 | 조건 | 설명 |
|---|---|---|
-ff (default) | 분기 없음 또는 동일한 분기 내용 | 브랜치 포인터를 병합 대상 브랜치 끝으로 이동. 히스토리 선형 유지. 병합 커밋 생성되지 않음. |
--no-ff | 조건 없음 | Fast-Forward 가능 여부와 상관없이 항상 병합 커밋 생성. 히스토리에 병합 작업을 명확히 표시. |
--ff-only | 분기 없음 | Fast-Forward 병합만 허용. 불가능하면 병합 중단. 히스토리를 선형으로 유지해야 할 때 사용. |
3-way | 분기 있음 | 공통 조상을 기준으로 병합 커밋 생성. 히스토리에 분기 흔적 남음. 충돌 발생 시 수동 해결 필요. |
--squash | 조건 없음 | 병합 대상 브랜치의 모든 커밋을 하나로 압축하여 적용. 히스토리 선형 유지, 개별 커밋 히스토리는 남지 않음. |
Fast-forward merge: --ff vs --no-ff :
* main 브랜치에서 feature 브랜치를 병합할 때
- main: A --- B --- C
\
- feature: D --- E --- F
1. `git merge --no-ff feature` 실행
- main: A --- B --- C ------------------- M
\ /
- feature: D --- E --- F ---
- 병합 커밋(M)이 생성됨
- feature 브랜치의 히스토리가 main 브랜치에 그대로 유지됨
2. `git merge --ff feature` 실행 (Fast-Forward 가능한 경우)
- main: A --- B --- C --- D --- E --- F
\
- feature: D --- E --- F
- 병합 커밋이 생성되지 않음
- main 브랜치가 feature 브랜치의 최신 커밋으로 이동함
| 명령어 및 옵션 | 설명 |
|---|---|
git merge <branch> | 현재 브랜치에 특정 브랜치를 병합. |
git merge --no-ff <branch> | Fast-forward 병합을 비활성화하고 항상 새로운 병합 커밋을 생성. |
git merge --ff-only <branch> | Fast-forward 병합만 허용. Fast-forward가 불가능하면 병합을 중단. |
git merge --squash <branch> | 특정 브랜치의 변경 사항을 현재 브랜치로 가져오되, 새로운 커밋으로 묶어서 병합. |
git merge --abort | 병 합 중 충돌이 발생한 경우, 병합 프로세스를 중단하고 병합 전 상태로 되돌림. |
git merge --continue | 충돌을 해결한 후 병합 프로세스를 계속 진행. |
git merge --no-commit <branch> | 병합을 수행하지만 자동으로 커밋하지 않음. |
git merge --stat | 병합 후 변경 사항의 통계를 보여줌. |
git merge --strategy=<전략> | 병합 전략을 지정. 예: recursive, ours, subtree 등. |
git merge --strategy-option=<옵션> | 병합 전략에 대한 옵션을 지정. 예: ours, theirs, patience 등. |
사용 예시:
# 현재 브랜치에 특정 브랜치 병합
git merge feature-branch
# Fast-forward 병합 비활성화 (항상 새로운 병합 커밋 생성)
git merge --no-ff feature-branch
# Fast-forward 병합만 허용 (불가능하면 중단)
git merge --ff-only feature-branch
# 특정 브랜치의 변경 사항을 Squash하여 병합
git merge --squash feature-branch
# 병합 중 충돌 발생 시 병합 중단 및 되돌리기
git merge --abort
# 충돌 해결 후 병합 계속 진행
git merge --continue
# 병합을 수행하지만 커밋하지 않음
git merge --no-commit feature-branch
# 병합 후 변경 사항 통계 보기
git merge --stat feature-branch
# 병합 전략 지정 (예: recursive)
git merge --strategy=recursive feature-branch
# 병합 전략 옵션 지정 (예: ours)
git merge --strategy-option=ours feature-branch
6. 원격 저장소
git remote
git remote는 원격 저장소를 관리하는 명령어입니다. 원격 저장소를 추가, 조회, 삭제하거나, 원격 저장소의 URL을 변경하는 등의 작업을 수행할 수 있습니다.
| 명령어 및 옵션 | 설명 |
|---|---|
git remote | 등록된 원격 저장소 목록을 확인. |
git remote -v | 등록된 원격 저장소 목록과 URL을 함께 확인. |
git remote add <name> <url> | 새로운 원격 저장소를 추가. |
git remote remove <name> | 등록된 원격 저장소를 삭제. |
git remote rename <old> <new> | 원격 저장소의 이름을 변경. |
git remote set-url <name> <url> | 원격 저장소의 URL을 변경. |
git remote show <name> | 특정 원격 저장소의 상세 정보를 확인. |
git remote prune <name> | 원격 저장소에서 삭제된 브랜치를 로컬에서 정리. |
git remote update | 원격 저장소의 모든 브랜치와 태그를 업데이트. |
git remote get-url <name> | 특정 원격 저장소의 URL을 확인. |
git remote set-branches <name> <branch> | 원격 저장소에서 추적할 브랜치를 지정. |
git remote add --track <branch> <name> <url> | 원격 저장소를 추가하면서 특정 브랜치를 추적하도록 설정. |
사용 예시:
# 등록된 원격 저장소 목록 확인
git remote
# 등록된 원격 저장소 목록과 URL 확인
git remote -v
# 새로운 원격 저장소 추가
git remote add origin https://github.com/user/repo.git
# 등록된 원격 저장소 삭제
git remote remove origin
# 원격 저장소 이름 변경
git remote rename origin upstream
# 원격 저장소 URL 변경
git remote set-url origin https://github.com/user/new-repo.git
# 특정 원격 저장소의 상세 정보 확인
git remote show origin
# 원격 저장소에서 삭제된 브랜치를 로컬에서 정리
git remote prune origin
# 원격 저장소의 모든 브랜치와 태그 업데이트
git remote update
# 특정 원격 저장소의 URL 확인
git remote get-url origin
# 원격 저장소에서 추적할 브랜치 지정
git remote set-branches origin main
# 원격 저장소를 추가하면서 특정 브랜치 추적 설정
git remote add --track main origin https://github.com/user/repo.git
git pull
git pull은 원격 저장소의 변경 사항을 로컬 저장소로 가져와 병합하는 명령어입니다. git fetch와 git merge를 합친 기능으로, 원격 브랜치의 최신 상태를 로컬에 반영할 때 사용됩니다.
| 명령어 및 옵션 | 설명 |
|---|---|
git pull | 현재 브랜치의 원격 저장소 변경 사항을 가져와 병합. |
git pull <remote> <branch> | 특정 원격 저장소와 브랜치의 변경 사항을 가져와 병합. |
git pull --rebase | 변경 사항을 가져온 후 병합 대신 리베이스를 수행. |
git pull --ff-only | Fast-forward 병합만 허용. Fast-forward가 불가능하면 중단. |
git pull --no-ff | Fast-forward 병합을 비활성화하고 항상 새로운 병합 커밋을 생성. |
git pull --autostash | 작업 중인 변경 사항을 임시로 저장(stash)하고, 병합 후 다시 적용. |
git pull --no-commit | 병합을 수행하지만 자동으로 커밋하지 않음. |
git pull --tags | 원격 저장소의 모든 태그를 가져옴. |
git pull --no-tags | 태그를 가져오지 않음. |
사용 예시:
# 현재 브랜치의 원격 저장소 변경 사항을 가져와 병합
git pull
# 특정 원격 저장소와 브랜치의 변경 사항을 가져와 병합
git pull origin main
# 변경 사항을 가져온 후 리베이스 수행
git pull --rebase
# Fast-forward 병합만 허용 (불가능하면 중단)
git pull --ff-only
# Fast-forward 병합 비활성화 (항상 새로운 병합 커밋 생성)
git pull --no-ff
# 작업 중인 변경 사항을 임시로 저장하고 병합 후 다시 적용
git pull --autostash
# 병합을 수행하지만 커밋하지 않음
git pull --no-commit
# 원격 저장소의 모든 태그를 가져옴
git pull --tags
# 태그를 가져오지 않음
git pull --no-tags
git push
git push는 로컬 저장소의 변경 사항을 원격 저장소에 업로드하는 명령어입니다. 주로 로컬에서 작업한 커밋을 원격 저장소와 동기화할 때 사용됩니다. 브랜치, 태그, 또는 특정 커밋을 원격 저장소로 푸시할 수 있습니다.
| 명령어 및 옵션 | 설명 |
|---|---|
git push | 현재 브랜치의 변경 사항을 원격 저장소에 푸시. |
git push <remote> <branch> | 특정 원격 저장소와 브랜치에 변경 사항을 푸시. |
git push <remote> <tag-name> | 특정 태그를 원격 저장소에 푸시. |
git push --all | 모든 브랜치의 변경 사항을 원격 저장소에 푸시. |
git push --tags | 모든 태그를 원격 저장소에 푸시. |
git push --force 또는 -f | 강제로 변경 사항을 푸시. (주의: 원격 저장소의 기존 커밋을 덮어씀) |
git push --force-with-lease | 강제로 푸시하되, 원격 브랜치가 로컬과 동일한 상태일 때만 수행. |
git push --delete <remote> <branch> | 원격 저장소의 특정 브랜치를 삭제. |
git push --set-upstream <remote> <branch> | 현재 브랜치를 원격 저장소에 푸시하고, 업스트림(추적) 브랜치로 설정. |
git push --dry-run | 푸시를 시뮬레이션. 실제로 푸시하지 않고 어떤 변경 사항이 푸시될지 확인. |
git push --prune | 원격 저장소에서 로컬에 존재하지 않는 브랜치를 삭제. |
git push --no-verify | 푸시 전 후크(hook) 스크립트를 실행하지 않음. |
git push --follow-tags | 푸시할 때 자동으로 태그를 함께 푸시. |
사용 예시:
# 현재 브랜치의 변경 사항을 원격 저장소에 푸시
git push
# 특정 원격 저장소와 브랜치에 변경 사항 푸시
git push origin main
# 특정 태그를 원격 저장소에 푸시
git push origin v1.0.0
# 모든 브랜치의 변경 사항을 원격 저장소에 푸시
git push --all
# 모든 태그를 원격 저장소에 푸시
git push --tags
# 강제로 변경 사항 푸시 (주의: 원격 저장소의 기존 커밋을 덮어씀)
git push --force
# 강제로 푸시하되, 원격 브랜치가 로컬과 동일한 상태일 때만 수행
git push --force-with-lease
# 원격 저장소의 특정 브랜치 삭제
git push --delete origin old-branch
# 현재 브랜치를 원격 저장소에 푸시하고 업스트림 브랜치로 설정
git push --set-upstream origin feature-branch
# 푸시를 시뮬레이션 (실제로 푸시하지 않음)
git push --dry-run
# 원격 저장소에서 로컬에 존재하지 않는 브랜치 삭제
git push --prune origin
# 푸시 전 후크(hook) 스크립트를 실행하지 않음
git push --no-verify
# 푸시할 때 자동으로 태그를 함께 푸시
git push --follow-tags
git fetch
git fetch는 원격 저장소의 변경 사항을 로컬 저장소로 가져오는 명령어입니다. git pull과 달리, fetch는 가져온 변경 사항을 자동으로 병합하지 않습니다. 따라서 원격 저장소의 상태를 확인하고, 필요할 때 수동으로 병합할 수 있어 보다 안전한 명령입니다.
| 명령어 및 옵션 | 설명 |
|---|---|
git fetch | 원격 저장소의 모 든 변경 사항을 가져옴. |
git fetch <remote> | 지정한 원격 저장소의 모든 변경 사항을 가져옴. |
git fetch <remote> <branch> | 지정한 원격 저장소의 특정 브랜치만 가져옴. |
git fetch --all | 모든 원격 저장소의 데이터를 가져옴. |
git fetch --prune | 로컬에 없는 원격 브랜치를 제거. |
git fetch --tags | 원격 저장소의 모든 태그를 가져옴. |
git fetch --force | 로컬 브랜치의 변경 사항을 강제로 덮어쓰며 원격 데이터를 가져옴. |
사용 예시:
# 원격 저장소의 모든 변경 사항 가져오기
git fetch
# 특정 원격 저장소의 변경 사항 가져오기
git fetch origin
# 특정 원격 저장소의 특정 브랜치 변경 사항 가져오기
git fetch origin main
# 모든 원격 저장소의 변경 사항 가져오기
git fetch --all
# 원격 저장소에서 삭제된 브랜치를 로컬에서 정리
git fetch --prune
# 원격 저장소의 모든 태그 가져오기
git fetch --tags
# 강제로 변경 사항 가져오기 (원격 브랜치가 강제로 없데이트 되어, 원격 참조(브랜치, 태그, HEAD등)가 변한경우)
git fetch --force
7. 태그
git tag
git tag는 특정 커밋에 태그를 추가하거나 관리하는 명령어입니다. 태그는 일반적으로 릴리스 버전(예: v1.0.0)을 표시하는 데 사용되며, 커밋을 쉽게 참조할 수 있도록 합니다. 태그는 Lightweight 태그와 Annotated 태그로 구분됩니다.
Lightweight태그: 단순히 커밋을 가리키는 이름입니다. 추가 정보(메시지, 서명 등)가 없습니다.(git tag <tagname>로 생성.)Annotated태그: 태그 이름 외에 메시지, 서명, 작성자 정보 등을 포함합니다. 일반적으로 릴리스 버전을 표시할 때 사용됩니다. (git tag -a <tagname>로 생성.)- 태그 푸시: 태그는 기본적으로
git push로 원격 저장소에 푸시되지 않습니다. 태그를 푸시하려면 명시적으로 지정해야 합니다.(git push참고 ) - 태그 삭제(
-d) 후 원격 저장소에서 태그를 삭제하려면git push <remote> --delete <tagname>을 사용해야 합니다.
| 명령어 및 옵션 | 설명 |
|---|---|
git tag | 모든 태그 목록을 확인. |
git tag <tagname> | 현재 커밋에 Lightweight 태그를 추가. |
git tag -a <tagname> | 현재 커밋에 Annotated 태그를 추가. (메시지 입력 필요) |
git tag -a <tagname> -m "<message>" | Annotated 태그를 추가하고 메시지를 함께 지정. |
git tag <tagname> <commit> | 특정 커밋에 태그를 추가. |
git tag -d <tagname> | 특정 태그를 삭제. |
git tag -l "<pattern>" | 특정 패턴과 일치하는 태그 목록을 확인. (예: v1.*) |
git tag --contains <commit> | 특정 커밋을 포함하는 태그 목록을 확인. |
git tag --points-at <commit> | 특정 커밋을 가리키는 태그 목록을 확인. |
git tag --sort=<key> | 태그 목록을 특정 키로 정렬. (예: version:refname, -version:refname) |
git tag -f <tagname> | 기존 태그를 강제로 덮어씀. (주의: 이미 공개된 태그는 덮어쓰지 않는 것이 좋음) |
git tag --sign | 태그에 GPG 서명을 추가. (Annotated 태그에서만 가능) |
사용 예시:
# 모든 태그 목록 확인
git tag
# 현재 커밋에 Lightweight 태그 추가
git tag v1.0.0
# 현재 커밋에 Annotated 태그 추가 (메시지 입력 필요)
git tag -a v1.0.0
# Annotated 태그 추가 및 메시지 지정
git tag -a v1.0.0 -m "Release version 1.0.0"
# 특정 커밋에 태그 추가
git tag v1.0.0 abc1234
# 특정 태그 삭제
git tag -d v1.0.0
# 특정 패턴과 일치하는 태그 목록 확인 (예: v1.*)
git tag -l "v1.*"
# 특정 커밋을 포함하는 태그 목록 확인
git tag --contains abc1234
# 특정 커밋을 가리키는 태그 목록 확인
git tag --points-at abc1234
# 태그 목록을 버전 순으로 정렬
git tag --sort=version:refname
# 태그 목록을 역순으로 정렬
git tag --sort=-version:refname
# 기존 태그 강제로 덮어쓰기 (주의: 공개된 태그는 덮어쓰지 않는 것이 좋음)
git tag -f v1.0.0
# 태그에 GPG 서명 추가
git tag --sign v1.0.0
8. 로그 및 변경이력
🔗git log
🔗git show
git blame
git blame은 특정 파일의 각 줄을 마지막으로 수정한 커밋과 작성자를 확인하는 명령어입니다. 이 명령어는 코드의 특정 부분이 누구에 의해, 언제 수정되었는지 추적할 때 유용합니다.
| 명령어 및 옵션 | 설명 |
|---|---|
git blame <file> | 특정 파일의 각 줄을 마지막으로 수정한 커밋과 작성자를 확인. |
git blame -L <start>,<end> <file> | 특정 파일의 특정 줄 범위를 확인. |
git blame -C <file> | 파일 내에서 복사된 코드의 원본 커밋을 추적. |
git blame -M <file> | 파일 내에서 이동된 코드의 원본 커밋을 추적. |
git blame -w | 공백 변경을 무시하고 코드 변경만 확인. |
git blame -e | 작성자의 이메일 주소를 표시. |
git blame -l | 커밋 해시의 전체 길이를 표시. |
git blame -t | 커밋의 타임스탬프를 표시. |
git blame -s | 커밋 해시의 짧은 버전을 표시. |
git blame --ignore-rev <commit> | 특정 커밋을 무시하고 결과를 표시. |
git blame --ignore-revs-file <file> | 특정 파일에 나열된 커밋을 무시하고 결과를 표시. |
사용 예시:
# 특정 파일의 각 줄을 마지막으로 수정한 커밋과 작성자 확인
git blame README.md
# 특정 파일의 10번째 줄부터 20번째 줄까지 확인
git blame -L 10,20 README.md
# 파일 내에서 복사된 코드의 원본 커밋 추적
git blame -C README.md
# 파일 내에서 이동된 코드의 원본 커밋 추적
git blame -M README.md
# 공백 변경을 무시하고 코드 변경만 확인
git blame -w README.md
# 작성자의 이메일 주소 표시
git blame -e README.md
# 커밋 해시의 전체 길이 표시
git blame -l README.md
# 커밋의 타임스탬프 표시
git blame -t README.md
# 커밋 해시의 짧은 버전 표시
git blame -s README.md
# 특정 커밋을 무시하고 결과 표시
git blame --ignore-rev abc1234 README.md
# 특정 파일에 나열된 커밋을 무시하고 결과 표시
git blame --ignore-revs-file .git-blame-ignore-revs README.md
git reflog
git reflog는 Reference Logs의 약자로, Git에서 HEAD와 브랜치의 이동 기록을 보여주는 명령어입니다. 이 명령어는 실수로 삭제한 브랜치나 커밋을 복구할 때 매우 유용합니다. reflog는 로컬 저장소에서만 유지되며, 원격 저장소와는 동기화되지 않습니다.
| 명령어 및 옵션 | 설명 |
|---|---|
git reflog | HEAD의 이동 기록을 확인. |
git reflog <branch> | 특정 브랜치의 이동 기록을 확인. |
git reflog --all | 모든 참조(브랜치, 태그 등)의 이동 기록을 확인. |
git reflog --date=<format> | 날짜 형식을 지정하여 기록을 확인. (예: iso, relative, local) |
git reflog --since=<time> | 특정 시간 이후의 기록만 확인. (예: 2.weeks.ago, 2023-10-01) |
git reflog --until=<time> | 특정 시간 이전의 기록만 확인. (예: 1.day.ago, 2023-10-31) |
git reflog --grep=<pattern> | 특정 패턴과 일치하는 기록만 확인. |
사용 예시:
# HEAD의 이동 기록 확인
git reflog
# 특정 브랜치의 이동 기록 확인
git reflog main
# 모든 참조(브랜치, 태그 등)의 이동 기록 확인
git reflog --all
# 날짜 형식을 지정하여 기록 확인 (예: ISO 형식)
git reflog --date=iso
# 특정 시간 이후의 기록만 확인 (예: 2주 전부터)
git reflog --since=2.weeks.ago
# 특정 시간 이전의 기록만 확인 (예: 1일 전까지)
git reflog --until=1.day.ago
# 특정 패턴과 일치하는 기록만 확인 (예: "merge"가 포함된 기록)
git reflog --grep=merge
9. 파일 복구 및 취소
🔗git checkout
git reset
git reset은 Git에서 커밋 히스토리를 되돌리거나, 스테이징 영역 및 작업 디렉토리의 상태를 변경하는 데 사용됩니다. 이 명령어는 커밋을 취소하거나, 파일을 스테이징 영역에서 제거하는 등 다양한 작업에 활용됩니다.
리셋의 세 가지 모드:
--soft: HEAD만 이동합니다. 스테이징 영역과 작업 디렉토리는 변경되지 않습니다.--mixed(기본): HEAD와 스테이징 영역을 리셋합니다. 작업 디렉토리는 변경되지 않습니다.--hard: HEAD, 스테이징 영역, 작업 디렉토리를 모두 리셋합니다. (주의필요: 변경사항 영구 삭제됨)
| 명령어 및 옵션 | 설명 |
|---|---|
git reset <commit> | 현재 브랜치의 HEAD를 특정 커밋으로 이동. ( 기본: --mixed) |
git reset --soft <commit> | HEAD를 특정 커밋으로 이동하지만, 스테이징 영역과 작업 디렉토리는 변경하지 않음. |
git reset --mixed <commit> | HEAD를 특정 커밋으로 이동하고, 스테이징 영역을 리셋하지만 작업 디렉토리는 변경하지 않음. (기본 동작) |
git reset --hard <commit> | HEAD를 특정 커밋으로 이동하고, 스테이징 영역과 작업 디렉토리를 모두 리셋. (주의: 변경 사항이 영구 삭제됨) |
git reset <file> | 특정 파일을 스테이징 영역에서 제거. (커밋되지 않은 변경 사항은 유지) |
git reset --patch 또는 -p | 변경 사항을 인터랙티브하게 선택하여 스테이징 영역에서 제거. |
git reset --keep <commit> | HEAD를 특정 커밋으로 이동하지만, 작업 디렉토리의 변경 사항을 유지. |
사용 예시:
# 현재 브랜치의 HEAD를 특정 커밋으로 이동 (기본: --mixed)
git reset abc1234
# HEAD를 특정 커밋으로 이동하지만, 스테이징 영역과 작업 디렉토리는 변경하지 않음 (--soft)
git reset --soft abc1234
# HEAD를 특정 커밋으로 이동하고, 스테이징 영역을 리셋하지만 작업 디렉토리는 변경하지 않음 (--mixed)
git reset --mixed abc1234
# HEAD를 특정 커밋으로 이동하고, 스테이징 영역과 작업 디렉토리를 모두 리셋 (--hard)
git reset --hard abc1234
# 특정 파일을 스테이징 영역에서 제거
git reset file.txt
# 변경 사항을 인터랙티브하게 선택하여 스테이징 영역에서 제거
git reset --patch
# HEAD를 특정 커밋으로 이동하지만, 작업 디렉토리의 변경 사항을 유지 (--keep)
git reset --keep abc1234
git restore
git restore는 Git 2.23 버전부터 도입된 명령어로, 작업 디렉토리나 스테이징 영역의 파일을 복원하는 데 사용됩니다.
| 명령어 및 옵션 | 설명 |
|---|---|
git restore <file> | 작업 디렉토리의 파일을 최신 커밋 상태로 복원. |
git restore --staged <file> | 스테이징 영역의 파일을 최신 커밋 상태로 복원. (작업 디렉토리는 변경되지 않음) |
git restore --source=<commit> <file> | 특정 커밋의 파일 상태로 작업 디렉토리 또는 스테이징 영역을 복원. |
git restore --worktree <file> | 작업 디렉토리의 파일만 복원. (스테이징 영역은 변경되지 않음) |
git restore --patch 또는 -p | 변경 사항을 인터랙티브하게 선택하여 복원. |
git restore --quiet | 복원 과정에서 출력을 최소화. |
git restore --ignore-unmerged | 병합 충돌이 발생한 파일은 복원하지 않음. |
git restore --recurse-submodules | 서브모듈의 변경 사항도 함께 복원. |
사용 예시:
# 작업 디렉토리의 파일을 최신 커밋 상태로 복원
git restore file.txt
# 스테이징 영역의 파일을 최신 커밋 상태로 복원
git restore --staged file.txt
# 특 정 커밋의 파일 상태로 작업 디렉토리 복원
git restore --source=HEAD~2 file.txt
# 작업 디렉토리의 파일만 복원 (스테이징 영역은 변경되지 않음)
git restore --worktree file.txt
# 변경 사항을 인터랙티브하게 선택하여 복원
git restore --patch file.txt
# 복원 과정에서 출력 최소화
git restore --quiet file.txt
# 병합 충돌이 발생한 파일은 복원하지 않음
git restore --ignore-unmerged file.txt
# 서브모듈의 변경 사항도 함께 복원
git restore --recurse-submodules
10. 리베이스
git rebase
git rebase는 브랜치의 커밋 히스토리를 재구성하는 명령어입니다. 다른 브랜치의 최신 커밋을 기준으로 현재 브랜치의 커밋을 재배치하여 깔끔한 히스토리를 만들 수 있습니다. 주로 git merge 대신 사용되며, 커밋 히스토리를 선형적으로 유지하는 데 유용합니다.
- 리베이스 중 충돌이 발생하면 충돌을 해결한 후
git rebase --continue를 실행해야 함. - 인터랙티브(
-i) 모드에서는 커밋을 수정, 삭제, 병합, 순서 변경 등 다양한 작업을 할 수 있음. (예를 들어, pick을 squash로 변경하여 여러 커밋을 하나로 합치는게 가능)
| 명령어 및 옵션 | 설명 |
|---|---|
git rebase <branch> | 현재 브랜치를 특정 브랜치 위로 재배치. |
git rebase -i <commit> | 인터랙티브 모드로 커밋을 재배치. (커밋 수정, 삭제, 병합 등 가능) |
git rebase --continue | 충돌 해결 후 리베이스를 계속 진행. |
git rebase --abort | 리베이스를 중단하고 원래 상태 로 되돌림. |
git rebase --skip | 충돌이 발생한 커밋을 건너뜀. |
git rebase --onto <newbase> | 현재 브랜치를 특정 커밋(newbase) 위로 재배치. |
git rebase --autostash | 작업 중인 변경 사항을 임시로 저장(stash)하고, 리베이스 후 다시 적용. |
git rebase --root | 최초 커밋부터 리베이스를 수행. |
git rebase --no-verify | 리베이스 전 후크(hook) 스크립트를 실행하지 않음. |
사용 예시:
# 현재 브랜치를 main 브랜치 위로 재배치
git rebase main
# 인터랙티브 모드로 커밋 재배치 (커밋 수정, 삭제, 병합 등 가능)
git rebase -i HEAD~3
# 충돌 해결 후 리베이스 계속 진행
git rebase --continue
# 리베이스 중단 및 원래 상태로 되돌리기
git rebase --abort
# 충돌이 발생한 커밋 건너뛰기
git rebase --skip
# 현재 브랜치를 특정 커밋(newbase) 위로 재배치
git rebase --onto newbase oldbase
# 작업 중인 변경 사항을 임시로 저장하고 리베이스 후 다시 적용
git rebase --autostash
# 최초 커밋부터 리베이스 수행
git rebase --root
# 리베이스 전 후크(hook) 스크립트를 실행하지 않음
git rebase --no-verify
11. 서브모듈
git submodule
git submodule은 Git 저장소 안에 다른 Git 저장소를 포함하는 기능입니다. 이는 프로젝트에서 외부 라이브러리나 다른 프로젝트를 의존성으로 사용할 때 유용합니다. 서브모듈은 독립적인 저장소로 관리되며, 부모 저장소에서 특정 커밋을 참조합니다.
| 명령어 및 옵션 | 설명 |
|---|---|
git submodule add <repository> | 새로운 서브모듈을 추가. |
git submodule init | 서브모듈을 초기화. (.gitmodules 파일에 정의된 서브모듈을 로컬에 설정) |
git submodule update | 서브모듈을 업데이트. (부모 저장소에서 참조하는 커밋으로 서브모듈을 업데이트) |
git submodule update --init | 서브모듈을 초기화하고 업데이트. |
git submodule update --remote | 서브모듈을 원격 저장소의 최신 커밋으로 업데이트. |
git submodule sync | 서브모듈의 URL을 .gitmodules 파일과 동기화. |
git submodule status | 서브모듈의 상태를 확인. |
git submodule deinit <path> | 특정 서브모듈을 비활성화. |
git submodule foreach <command> | 모든 서브모듈에 대해 특정 명령어를 실행. |
사용 예시:
# 새로운 서브모듈 추가
git submodule add https://github.com/user/repo.git path/to/submodule
# 서브모듈 초기화
git submodule init
# 서브모듈 업데이트
git submodule update
# 서브모듈 초기화 및 업데이트
git submodule update --init
# 서브모듈을 원격 저장소의 최신 커밋으로 업데이트
git submodule update --remote
# 서브모듈의 URL 동기화
git submodule sync
# 서브모듈 상태 확인
git submodule status
# 특정 서브모듈 비활성화
git submodule deinit path/to/submodule
# 모든 서브모듈에 대해 특정 명령어 실행
git submodule foreach 'git checkout main'
12. 기타 유용한 명령어
git cherry-pick
git cherry-pick은 특정 커밋을 현재 브랜치에 적용하는 명령어입니다. 다른 브랜치의 특정 커밋만 선택적으로 현재 브랜치에 반영할 때 사용됩니다. 이는 특정 기능이나 버그 수정을 다른 브랜치로 포팅할 때 유용합니다.
- cherry-pick 중 충돌이 발생하면 충돌을 해결한 후
git cherry-pick --continue를 실행해야 합니다. - 충돌 해결을 중단하려면
git cherry-pick --abort를 사용합니다.
| 명령어 및 옵션 | 설명 |
|---|---|
git cherry-pick <commit> | 특정 커밋을 현재 브랜치에 적용. |
git cherry-pick <commit1> <commit2> | 여러 커밋을 현재 브랜치에 적용. |
git cherry-pick <start>^..<end> | 특정 범위의 커밋을 현재 브랜치에 적용. |
git cherry-pick --continue | 충돌 해결 후 cherry-pick을 계속 진행. |
git cherry-pick --abort | cherry-pick을 중단하고 원래 상태로 되돌림. |
git cherry-pick --skip | 충돌이 발생한 커밋을 건너뜀. |
git cherry-pick --no-commit | 커밋을 생성하지 않고 변경 사항만 적용. |
git cherry-pick --edit | 커밋 메시지를 수정하며 cherry-pick을 수행. |
git cherry-pick --signoff | 커밋 메시지에 Signed-off-by 줄을 추가. |
git cherry-pick --ff | 가능한 경우 Fast-forward로 cherry-pick을 수행. |
사용 예시:
# 특정 커밋을 현재 브랜치에 적용
git cherry-pick abc1234
# 여러 커밋을 현재 브랜치에 적용
git cherry-pick abc1234 def5678
# 특정 범위의 커밋을 현재 브랜치에 적용
git cherry-pick start-commit^..end-commit
# 충돌 해결 후 cherry-pick 계속 진행
git cherry-pick --continue
# cherry-pick 중단 및 원래 상태로 되돌리기
git cherry-pick --abort
# 충돌이 발생한 커밋 건너뛰기
git cherry-pick --skip
# 커밋을 생성하지 않고 변경 사항만 적용
git cherry-pick --no-commit abc1234
# 커밋 메시지를 수정하며 cherry-pick 수행
git cherry-pick --edit abc1234
# 커밋 메시지에 Signed-off-by 줄 추가
git cherry-pick --signoff abc1234
# 가능한 경우 Fast-forward로 cherry-pick 수행
git cherry-pick --ff abc1234
git bisect
git bisect는 이진 탐색(binary search)을 사용하여 버그가 발생한 커밋을 찾는 명령어입니다. 이 명령어는 특정 버그가 언제 도입되었는지 정확히 찾아낼 때 매우 유용합니다. git bisect는 좋은 상태(good)와 나쁜 상태(bad)를 지정한 후, 중간 커밋을 확인하며 버그가 발생한 커밋을 찾습니다.
| 명령어 및 옵션 | 설명 |
|---|---|
git bisect start | 이진 탐색을 시작. |
git bisect good <commit> | 특정 커밋이 좋은 상태(good)임을 표시. |
git bisect bad <commit> | 특정 커밋이 나쁜 상태(bad)임을 표시. |
git bisect reset | 이진 탐색을 종료하고 원래 브랜치로 돌아감. |
git bisect run <command> | 자동으로 이진 탐색을 수행. 지정한 명령어를 실행하여 좋은지 나쁜지 판단. |
git bisect log | 이진 탐색의 로그를 확인. |
git bisect skip | 현재 커밋을 건너뜀. |
사용 예시:
# 이진 탐색 시작
git bisect start
# 현재 커밋이 나쁜 상태임을 표시
git bisect bad
# 특정 커밋이 좋은 상태임을 표시
git bisect good abc1234
# 이진 탐색 종료 및 원래 브랜치로 돌아가기
git bisect reset
# 자동으로 이진 탐색 수행 (테스트 스크립트 사용)
git bisect run ./test-script.sh
# 이진 탐색 로그 확인
git bisect log
# 현재 커밋 건너뛰기
git bisect skip