Git CLI 명령어 사용 매뉴얼 (2025-09-26)
1. 서문
이 문서는 Git CLI(Command-Line Interface) 명령어의 사용법을 총망라하는 실용적인 레퍼런스를 제공하는 것을 목표로 한다. 설치, 환경 설정, Git의 내부 동작 원리에 대한 이론적 설명은 의도적으로 배제하고, 오직 명령어의 구문과 활용 예시에 집중한다. 명령어는 개발 워크플로우의 논리적 흐름에 따라 분류되었다. 각 명령어는 핵심 기능에 대한 명료한 설명과 함께, 다양한 옵션을 활용한 구체적인 사용법을 제시한다.
2. 저장소 생성 및 복제
모든 Git 프로젝트는 저장소(Repository)에서 시작된다. 이 섹션에서는 로컬에서 새로운 저장소를 만들거나 원격에 존재하는 저장소를 복제하는 명령어를 다룬다.
2.1 git init
새로운 로-컬 저장소를 초기화한다.
핵심 기능
현재 디렉토리를 Git 저장소로 변환한다. 이 명령을 실행하면 .git이라는 숨겨진 하위 디렉토리가 생성되며, 이 디렉토리에는 저장소에 필요한 모든 메타데이터와 객체 데이터베이스가 저장된다.1 기존 프로젝트를 버전 관리하에 두거나, 완전히 새로운 프로젝트를 시작할 때 가장 먼저 실행하는 명령어이다.4
기본 사용법
- 현재 디렉토리에서 초기화
현재 작업 중인 디렉토리를 Git 저장소로 만든다.
git init
이 명령은 현재 디렉토리에 .git 폴더를 생성한다. 기존에 파일이 있더라도 파일 자체에는 영향을 주지 않는다.2
- 특정 디렉토리에 초기화
지정한 이름으로 새 디렉토리를 만들고 그 안에서 Git 저장소를 초기화한다.
git init <directory>
예를 들어, git init my-project는 my-project라는 디렉토리를 생성하고 그 안에 .git 폴더를 만든다.3
주요 옵션
--bare
작업 디렉토리(Working Directory)가 없는 ‘bare’ 저장소를 생성한다. 이 저장소는 개발자가 직접 파일을 편집하고 커밋하는 용도가 아니다. 대신, 여러 개발자가 코드를 공유하고 동기화하기 위한 중앙 서버 역할을 한다. 관례적으로 bare 저장소의 디렉토리명은 .git으로 끝난다 (예: my-project.git).1 중앙 집중식 워크플로우를 구축할 때, 서버에는 git init --bare로 저장소를 만들고 각 개발자는 git clone으로 non-bare 로컬 복사본을 가져가 작업하는 것이 표준적인 패턴이다. init --bare가 공유를 위한 빈 중앙 저장소를 ’처음부터 생성’하는 역할이라면, clone --bare는 기존 중앙 저장소의 ’백업 또는 미러를 생성’하는 데 사용된다는 개념적 차이를 이해하는 것이 중요하다.
-b <branch-name>또는--initial-branch=<branch-name>
저장소 생성 시 초기 브랜치 이름을 지정한다. 이 옵션을 사용하지 않으면 master나 main과 같은 기본 이름이 사용된다. Git 2.28 버전부터 이 기본 브랜치 이름을 init.defaultBranch 설정을 통해 변경할 수 있다.1
git init -b main
--template=<template-directory>
저장소를 초기화할 때 기본 구조 대신 지정된 템플릿 디렉토리의 파일과 디렉토리를 .git 디렉토리에 복사한다. 이를 통해 모든 팀원이 동일한 Git hooks, .gitignore 패턴, 또는 저장소 설정을 공유하도록 강제할 수 있다.1
2.2 git clone
기존 저장소를 복제한다.
핵심 기능
원격 서버(예: GitHub)나 로컬 파일 시스템에 있는 기존 Git 저장소의 완전한 복사본을 만든다. 단순히 파일만 복사하는 것이 아니라, 프로젝트의 모든 파일, 모든 브랜치, 그리고 모든 커밋 이력을 포함하는 완전한 복제본을 생성한다.6
git clone 명령어는 내부적으로 git init을 호출하여 새 디렉토리를 초기화한 후, 원격 저장소의 데이터를 복사하고 작업 디렉토리를 구성하는 방식으로 동작한다.5
기본 사용법
- 원격 저장소 복제
지정된 URL의 저장소를 현재 위치 아래에 저장소 이름과 동일한 새 디렉토리를 만들어 그 안에 복제한다.
git clone <repo-url>
예를 들어, git clone https://github.com/user/repo.git는 repo라는 디렉토리를 생성하고 그 안에 저장소를 복제한다.9
- 특정 디렉토리 이름으로 복제
저장소를 복제하면서 로컬에 생성될 디렉토리의 이름을 직접 지정한다.
git clone <repo-url> <directory>
예를 들어, git clone https://github.com/user/repo.git my-project는 저장소를 my-project라는 디렉토리 안에 복제한다.6
주요 옵션
-b <branch-name>또는--branch <branch-name>
저장소를 복제한 후, 원격 저장소의 기본 브랜치(보통 main 또는 master) 대신 지정된 특정 브랜치를 체크아웃한다.6
git clone -b develop https://github.com/user/repo.git
--single-branch
--branch 옵션과 함께 사용되며, 지정된 브랜치 하나에 대한 이력만 가져온다. 다른 모든 브랜치에 대한 참조는 가져오지 않으므로, 수백 개의 브랜치를 가진 거대한 저장소를 복제할 때 네트워크 사용량과 시간을 크게 줄일 수 있다.8
git clone -b develop --single-branch https://github.com/user/repo.git
--depth <depth>
전체 커밋 이력을 가져오는 대신, 가장 최신의
git clone --depth 1 https://github.com/user/repo.git
--bare
git init --bare와 유사하게, 작업 디렉토리 없이 .git 디렉토리의 내용만 복제한다. 이는 원격 저장소의 미러(mirror)를 생성하거나 백업 목적으로 사용된다.6
--mirror
--bare 옵션의 동작을 포함하며, 원격 저장소의 모든 참조(refs), 즉 브랜치, 태그 등을 그대로 복제하여 완벽한 미러를 생성한다. 기존 저장소를 다른 서버로 이전하거나 완전한 백업을 만들 때 사용된다.6
--recurse-submodules
복제하는 저장소에 서브모듈(submodule)이 포함되어 있을 경우, 해당 서브모듈들도 재귀적으로 초기화하고 복제한다. 프로젝트가 다른 저장소에 의존성을 가질 때 유용하다.8
이러한 고급 clone 옵션들(--depth, --single-branch, --filter 등)은 Git이 단순한 소스코드 관리 도구를 넘어, 대규모 저장소(monorepo)나 거대한 바이너리 자산을 관리하는 시스템으로 진화하고 있음을 보여준다. 필요한 데이터만 선택적으로 가져와 네트워크 대역폭과 로컬 저장 공간을 최적화하는 것은 현대적인 개발 환경, 특히 자동화된 CI/CD 파이프라인에서 필수적인 기능이다.
3. 기본 작업 흐름: 상태 확인, 스테이징, 커밋
Git의 가장 기본적인 작업 주기는 ’수정(Modify) → 추가(Stage) → 저장(Commit)’의 3단계로 이루어진다. 이 섹션에서는 이 핵심 주기를 관리하는 명령어들을 상세히 설명한다.
3.1 git status
작업 디렉토리의 상태를 확인한다.
핵심 기능
작업 디렉토리와 스테이징 영역(Index)의 현재 상태를 마지막 커밋과 비교하여 보여준다. 이를 통해 어떤 파일이 수정되었는지, 어떤 변경사항이 다음 커밋에 포함될 예정인지(staged), 그리고 어떤 파일이 아직 Git의 추적 대상이 아닌지(untracked) 명확하게 파악할 수 있다.13
기본 사용법
- 상세 상태 확인
현재 브랜치 정보, 스테이징된 변경사항(Changes to be committed), 스테이징되지 않은 변경사항(Changes not staged for commit), 그리고 추적되지 않는 파일(Untracked files) 목록을 상세히 보여준다.13
git status
주요 옵션
-s또는--short
변경 상태를 간결한 형식으로 한 줄에 하나씩 보여준다. 각 파일명 앞에는 상태를 나타내는 코드가 붙는다. 예를 들어, M은 수정된 파일(Modified), A는 스테이징된 새 파일(Added), ??는 추적되지 않는 파일(Untracked)을 의미한다.13
$ git status -s
M README.md
?? new_file.txt
-b또는--branch
--short 형식으로 출력할 때도 브랜치와 원격 추적 정보를 함께 표시한다.17
-u또는--untracked-files=
추적되지 않는 파일의 표시 방식을 제어한다. no는 표시 안 함, normal은 파일만 표시, all은 디렉토리 내부의 개별 파일까지 모두 표시한다.17
3.2 git add
변경사항을 스테이징 영역에 추가한다.
핵심 기능
작업 디렉토리에서 발생한 변경사항(새 파일 생성, 기존 파일 수정, 파일 삭제)을 다음 커밋에 포함시키기 위해 ‘스테이징 영역(Staging Area)’ 또는 ’인덱스(Index)’라고 불리는 곳으로 옮긴다. git add 명령 없이는 어떠한 변경도 커밋될 수 없다. 이 단계는 여러 변경사항 중 일부만 선택하여 논리적으로 의미 있는 단위의 커밋을 구성할 수 있게 해주는 Git의 강력한 기능이다.18
기본 사용법
- 특정 파일 스테이징
지정한 파일 하나의 변경사항만 스테이징한다.
git add <file>
- 특정 디렉토리 스테이징
지정한 디렉토리 내부의 모든 변경사항을 재귀적으로 스테이징한다.
git add <directory>
- 현재 디렉토리의 모든 변경사항 스테이징
현재 위치한 디렉토리와 그 하위 디렉토리의 모든 변경사항(신규, 수정, 삭제 파일 포함)을 스테이징한다.
git add.
- 저장소 전체의 모든 변경사항 스테이징
현재 위치와 상관없이 저장소 전체에서 발생한 모든 변경사항을 스테이징한다.
git add -A
- 추적 중인 파일의 변경사항만 스테이징
이미 Git이 추적하고 있는 파일들의 수정 및 삭제 내역만 스테이징한다. 새로 생성된 파일(untracked)은 포함하지 않는다.
git add -u
| 명령어 (Command) | 신규 파일 | 수정된 파일 | 삭제된 파일 | 동작 범위 (Scope) |
|---|---|---|---|---|
git add. | 예 | 예 | 예 | 현재 디렉토리 및 하위 |
git add -A | 예 | 예 | 예 | 저장소 전체 |
git add -u | 아니오 | 예 | 예 | 저장소 전체 |
주요 옵션
-p또는--patch
변경사항을 ’청크(hunk)’라는 작은 단위로 나누어 보여주고, 각 청크를 스테이징할지 여부를 대화형으로 선택하게 한다. 하나의 파일 내에서 여러 논리적 변경이 이루어졌을 때, 이를 분리하여 별도의 커밋으로 만들고 싶을 때 매우 유용하다. 이는 ’원자적 커밋(Atomic Commits)’을 만드는 핵심 도구이다.18
- -f 또는 –force
.gitignore 파일에 명시되어 Git이 무시하도록 설정된 파일도 강제로 스테이징 영역에 추가한다.21
- -n 또는 –dry-run
실제로 파일을 스테이징하지 않고, 어떤 파일들이 추가될 것인지만 미리 보여준다. 의도치 않은 파일이 포함되는 것을 방지하기 위해 사용한다.20
Git의 스테이징 영역은 단순히 커밋을 위한 임시 저장소가 아니다. 이는 개발자의 복잡하고 때로는 정돈되지 않은 작업 흐름(messy working directory)과, 프로젝트의 논리적이고 깨끗한 이력(clean history) 사이의 중요한 완충 지대 역할을 한다. git add -p와 같은 기능을 활용하여 관련 없는 변경사항들을 분리하고, 각 커밋이 단 하나의 목적만을 가지도록 구성하는 것은 좋은 버전 관리 습관의 핵심이다.
3.3 git commit
스테이징된 변경사항을 저장소에 기록한다.
핵심 기능
스테이징 영역에 있는 모든 변경사항의 스냅샷을 찍어 로컬 저장소의 이력에 영구적으로 기록한다. 각 커밋은 고유한 40자리 SHA-1 해시값(ID)을 가지며, 작성자, 시간, 그리고 무엇을 변경했는지 설명하는 커밋 메시지 등의 메타데이터를 포함한다.23
기본 사용법
- 편집기를 사용하여 커밋
이 명령을 실행하면 Git이 설정된 기본 텍스트 편집기가 열리고, 이곳에 커밋 메시지를 작성하여 저장한다.
Bash
git commit
- 인라인 메시지로 커밋
-m 옵션을 사용하여 커맨드 라인에서 직접 커밋 메시지를 작성한다. 가장 널리 사용되는 방식이다.
Bash
git commit -m "Fix: User login validation bug"
주요 옵션
- -a 또는 –all
이미 Git이 추적하고 있는 파일들의 수정 및 삭제사항을 자동으로 스테이징한 후 커밋한다. git add -u와 git commit -m “…“을 한 번에 실행하는 것과 같다. 새로 생성된 파일은 이 옵션에 포함되지 않으므로 별도로 git add 해야 한다.23
Bash
git commit -a -m "Refactor: Improve database query performance"
- –amend
가장 최근의 커밋을 수정한다. 새로운 변경사항을 추가하거나 기존 커밋 메시지를 변경할 수 있다. 이 옵션은 이전 커밋을 덮어쓰는 새로운 커밋을 생성하므로, 이미 원격 저장소에 푸시(push)한 커밋에 대해서는 사용하지 않는 것이 좋다. 팀원과의 이력 충돌을 유발할 수 있기 때문이다.23
Bash
# 방금 한 커밋에 파일을 빠뜨렸을 때
git add forgotten_file.js
git commit --amend
- –amend –no-edit
가장 최근 커밋에 파일 추가/제거 등의 변경사항만 반영하고, 기존의 커밋 메시지는 그대로 사용한다.23
Bash
git add forgotten_file.js
git commit --amend --no-edit
- -v 또는 –verbose
커밋 메시지를 작성하는 편집기 화면 하단에 이번 커밋에 포함될 변경 내용(diff)을 함께 표시한다. 이를 통해 변경사항을 다시 한번 확인하면서 정확한 커밋 메시지를 작성하는 데 도움을 준다.23
4. 브랜치: 관리 및 통합
브랜치는 기존 개발 라인에 영향을 주지 않고 새로운 기능 개발이나 버그 수정을 독립적으로 진행할 수 있게 해주는 Git의 핵심 기능이다. 이 섹션에서는 브랜치를 다루고, 분기된 작업을 다시 하나로 합치는 명령어들을 설명한다.
4.1 git branch
브랜치를 관리한다.
핵심 기능
브랜치를 생성, 조회, 이름 변경, 삭제하는 다목적 도구이다. 아무 인자 없이 사용하면 로컬 브랜치의 목록을 보여준다.27
기본 사용법
- 브랜치 목록 조회
로컬 저장소에 있는 모든 브랜치의 목록을 보여준다. 현재 작업 중인 브랜치는 이름 앞에 * 기호가 붙는다.28
Bash
git branch
- 새 브랜치 생성
현재 커밋을 기반으로 새로운 브랜치를 생성한다. 이 명령은 브랜치를 생성만 할 뿐, 해당 브랜치로 작업 환경을 전환하지는 않는다.28
Bash
git branch <branch-name>
- 브랜치 삭제
병합이 완료된 브랜치를 삭제한다. 만약 병합되지 않은 변경사항이 해당 브랜치에 남아있다면, 데이터 유실을 방지하기 위해 삭제가 실패한다.29
Bash
git branch -d <branch-name>
- 브랜치 강제 삭제
병합 여부와 상관없이 브랜치를 강제로 삭제한다. 아직 병합하지 않은 작업 내용을 정말로 버릴 때 사용해야 한다.29
Bash
git branch -D <branch-name>
주요 옵션
- -a
로컬 브랜치뿐만 아니라 원격 추적 브랜치(remote-tracking branches)까지 모두 보여준다.28
- -r
원격 추적 브랜치의 목록만 보여준다.29
- -m
브랜치의 이름을 변경한다. 만약 현재 브랜치의 이름을 바꾸려면
Bash
git branch -m feature/login feature/authentication
- -v
각 브랜치의 이름과 함께 마지막 커밋의 해시와 메시지 요약을 보여준다.28
4.2 git checkout
브랜치를 전환하거나 파일을 복원한다.
핵심 기능
작업 디렉토리의 상태를 특정 브랜치나 커밋의 상태로 전환한다. 이 과정에서 HEAD 포인터가 해당 브랜치나 커밋을 가리키게 된다. 또는, 작업 디렉토리에서 수정한 특정 파일의 내용을 이전 버전으로 복원하는 데에도 사용된다.27
기본 사용법
- 브랜치 전환
지정된 이름의 브랜치로 작업 환경을 전환한다.
Bash
git checkout <branch-name>
- 새 브랜치 생성 및 전환
-b 옵션을 사용하여 새로운 브랜치를 생성하고, 즉시 해당 브랜치로 전환한다. 이는 git branch
Bash
git checkout -b <new-branch-name>
- 파일 변경사항 복원
– 뒤에 파일 이름을 지정하여, 작업 디렉토리에서 수정한 파일의 변경사항을 취소하고 가장 최근 커밋(HEAD)의 상태로 되돌린다. 스테이징되지 않은 변경사항만 영향을 받는다.31
Bash
git checkout -- <file-name>
4.3 git merge
브랜치를 병합한다.
핵심 기능
독립적으로 개발된 다른 브랜치의 변경 이력을 현재 브랜치로 통합한다. git merge는 기본적으로 두 브랜치의 이력을 부모로 갖는 새로운 ’머지 커밋(merge commit)’을 생성하여, 어떤 작업이 언제 합쳐졌는지에 대한 명확한 이력을 남긴다. 이는 프로젝트 이력을 있는 그대로 보존하는 방식이다.35
기본 사용법
- 브랜치 병합
현재 체크아웃된 브랜치에 지정한 브랜치의 변경사항을 병합한다.
Bash
# main 브랜치로 이동
git checkout main
# feature 브랜치의 내용을 main으로 병합
git merge feature
주요 옵션
- –no-ff
병합 대상 브랜치가 현재 브랜치로부터 단순히 앞으로만 진행된 ‘Fast-forward’ 관계일 때도, 강제로 머지 커밋을 생성한다. “feature 브랜치를 병합했다“는 이력을 명확하게 남기고 싶을 때 유용하다.30
- –squash
병합할 브랜치에 있던 여러 커밋들을 하나의 커밋으로 합쳐서 현재 브랜치에 적용한다. 이 옵션은 자동으로 커밋을 생성하지 않고, 합쳐진 변경사항을 스테이징 영역에만 올려둔다. 개발 과정에서 생성된 지저분한 임시 커밋들을 정리하고 하나의 의미 있는 커밋으로 통합할 때 유용하다.30
- –abort
병합 과정에서 충돌(conflict)이 발생했을 때, 병합 작업을 완전히 중단하고 병합을 시도하기 이전의 상태로 되돌린다.30
4.4 git rebase
브랜치를 재배치한다.
핵심 기능
현재 브랜치의 커밋들을 마치 다른 브랜치의 최신 커밋 위에서 새로 작업한 것처럼 이력을 재작성한다. merge가 두 이력을 합치는 새로운 점을 만드는 방식이라면, rebase는 한 이력의 줄기를 다른 줄기 위로 옮겨 붙여서 하나의 선형적인 이력으로 만든다. 이 과정에서 기존 커밋들은 버려지고 새로운 해시를 가진 커밋들이 생성된다.37
기본 사용법
- 브랜치 재배치
현재 브랜치의 시작점(base)을 지정한 브랜치의 최신 커밋으로 변경한다.
Bash
# feature 브랜치로 이동
git checkout feature
# main 브랜치의 최신 변경사항을 feature 브랜치에 반영하고,
# feature 브랜치의 커밋들을 그 위에 재배치
git rebase main
주요 옵션
- -i 또는 –interactive
대화형 리베이스 모드를 시작한다. 재배치될 커밋들의 목록이 편집기에 나타나며, 각 커밋에 대해 순서 변경(reorder), 합치기(squash/fixup), 메시지 수정(reword), 삭제(drop) 등 다양한 작업을 수행할 수 있다. 커밋 이력을 깔끔하게 정리하는 데 매우 강력한 기능이다.37
- –continue
리베이스 도중 충돌이 발생하여 사용자가 수동으로 충돌을 해결한 후, 리베이스 과정을 계속 진행시킨다.30
- –abort
리베이스 작업을 중단하고, 리베이스를 시작하기 전의 원래 상태로 브랜치를 되돌린다.30
- –skip
충돌이 발생한 현재 커밋의 적용을 건너뛰고(포기하고) 리베이스를 계속 진행한다.30
merge와 rebase는 동일한 문제, 즉 분기된 이력의 통합을 해결하지만 그 철학과 결과는 근본적으로 다르다. merge는 “무슨 일이 있었는지“를 정직하게 기록하는 반면, rebase는 “무슨 일이 있었어야 했는지“에 대한 깔끔한 이야기를 만들어낸다. 이 차이를 이해하는 것이 중요하며, 특히 rebase는 공유된 브랜치의 이력을 변경하여 팀 전체에 혼란을 줄 수 있으므로 절대적으로 피해야 한다. 이를 ’리베이스의 황금률(The Golden Rule of Rebasing)’이라 부른다.39
| 특징 (Feature) | git merge | git rebase |
|---|---|---|
| 커밋 이력 | 비선형(Non-linear). 분기 및 병합 이력을 그대로 보존. | 선형(Linear). 이력을 깔끔하게 재작성. |
| 결과물 | 새로운 ‘머지 커밋’ 생성. | 새로운 커밋 생성 (기존 커밋은 버려짐). |
| 협업 | 공유된 원격 브랜치에 안전하게 사용 가능. | 공유된 브랜치에 절대 사용 금지 (Golden Rule). |
| 장점 | 이력의 추적성, 컨텍스트 보존. | 깔끔하고 읽기 쉬운 이력. |
| 단점 | 이력이 복잡해질 수 있음. | 이력을 재작성하여 컨텍스트 손실, 충돌 해결이 더 복잡할 수 있음. |
5. 원격 저장소 연동
Git은 분산 버전 관리 시스템으로, 다른 위치에 있는 저장소와 코드를 주고받는 기능이 핵심이다. 이 섹션에서는 원격 저장소와의 연결을 설정하고 데이터를 동기화하는 명령어들을 다룬다.
5.1 git remote
원격 저장소를 관리한다.
핵심 기능
로컬 저장소가 상호작용할 원격 저장소(remotes)의 목록을 관리한다. 원격 저장소는 보통 네트워크 어딘가에 호스팅된 버전의 프로젝트를 의미한다.41
기본 사용법
- 원격 저장소 목록 확인
등록된 모든 원격 저장소의 단축 이름과 URL을 함께 보여준다.
Bash
git remote -v
- 새 원격 저장소 추가
Bash
git remote add <name> <url>
예: git remote add origin https://github.com/user/repo.git.41
- 원격 저장소 삭제
등록된 원격 저장소를 목록에서 삭제한다.
Bash
git remote remove <name>
- 원격 저장소 이름 변경
기존 원격 저장소의 단축 이름을 변경한다.
Bash
git remote rename <old-name> <new-name>
5.2 git fetch
원격 저장소의 최신 내용을 가져온다.
핵심 기능
원격 저장소에 있지만 로컬 저장소에는 없는 최신 데이터(커밋, 브랜치, 태그 등)를 모두 가져온다. 중요한 점은, fetch는 데이터를 가져오기만 할 뿐 로컬의 작업 디렉토리나 현재 브랜치에 자동으로 병합(merge)하지 않는다는 것이다. 따라서 원격의 변경사항을 확인하고 로컬 작업에 통합하기 전에 검토할 시간을 가질 수 있어 안전한 동기화 방법으로 간주된다.43
기본 사용법
- 특정 원격 저장소에서 가져오기
지정한 원격 저장소의 최신 내용을 모두 가져온다.
Bash
git fetch <remote-name>
예: git fetch origin
- 모든 원격 저장소에서 가져오기
–all 옵션을 사용하여 등록된 모든 원격 저장소의 내용을 한 번에 가져온다.30
Bash
git fetch --all
주요 옵션
- –prune 또는 -p
fetch를 실행하기 전에, 원격 저장소에서는 이미 삭제되어 더 이상 존재하지 않는 브랜치에 해당하는 로컬의 원격 추적 브랜치(remote-tracking branch)를 함께 삭제하여 정리한다.44
5.3 git pull
원격 저장소의 내용을 가져와 병합한다.
핵심 기능
git fetch와 git merge 두 명령어를 순서대로 실행하는 것과 동일한 효과를 가진다. 즉, 원격 저장소의 지정된 브랜치에서 최신 내용을 가져온 후, 그 내용을 현재 체크아웃된 브랜치에 자동으로 병합한다. 가장 일반적인 동기화 명령어이다.43
기본 사용법
- 가져와서 병합하기
현재 브랜치가 추적하고 있는 원격 브랜치로부터 최신 변경사항을 가져와 병합한다.
Bash
git pull
명시적으로 지정할 수도 있다: git pull <remote-name> <branch-name>.45
주요 옵션
- –rebase
변경사항을 통합할 때 merge 대신 rebase 전략을 사용한다. 이 옵션을 사용하면 원격 브랜치의 변경사항 위에 로컬에서 작업한 커밋들을 재배치하여, 불필요한 머지 커밋 없이 선형적인 이력을 유지할 수 있다.45
- –no-commit
병합은 수행하되, 자동으로 머지 커밋을 생성하지 않고 변경사항을 스테이징 상태로 둔다. 병합 결과를 커밋하기 전에 추가적인 수정이나 검토를 하고 싶을 때 사용한다.45
git pull은 편리하지만, 내부적으로 fetch와 merge를 자동으로 수행한다는 점을 인지해야 한다. 이는 사용자가 원치 않는 머지 커밋을 생성하여 이력을 복잡하게 만들 수 있다. 보다 정교한 워크플로우를 위해서는, git fetch로 원격 변경사항을 먼저 안전하게 확인하고, git log 등으로 차이점을 분석한 뒤, 의도적으로 merge나 rebase를 실행하는 것이 더 통제된 방식이다.
5.4 git push
로컬 변경사항을 원격 저장소에 올린다.
핵심 기능
로컬 브랜치에 있는 커밋들을 지정된 원격 저장소의 브랜치로 업로드한다. 이를 통해 다른 팀원들과 작업을 공유할 수 있다.42
기본 사용법
- 원격 저장소로 푸시
로컬 브랜치를 지정한 원격 저장소의 동일한 이름의 브랜치로 푸시한다.
Bash
git push <remote-name> <branch-name>
예: git push origin main
주요 옵션
- -u 또는 –set-upstream
로컬 브랜치를 원격 브랜치로 푸시하면서, 둘 사이에 ‘업스트림(upstream)’ 추적 관계를 설정한다. 한번 이 관계를 설정해두면, 이후에는 해당 브랜치에서 git push 또는 git pull 명령을 인자 없이 실행할 수 있다.30
Bash
git push -u origin feature/new-login
- –force
원격 저장소의 이력과 로컬 이력이 일치하지 않아(non-fast-forward) 푸시가 거부될 때, 이를 무시하고 강제로 푸시하여 원격 저장소의 이력을 로컬 이력으로 덮어쓴다. rebase로 이력을 재작성한 로컬 브랜치를 푸시할 때 사용되지만, 다른 팀원의 작업을 유실시킬 수 있는 매우 위험한 옵션이므로 협업 시에는 극히 신중하게 사용해야 한다.30
- –tags
git push는 기본적으로 태그를 전송하지 않는다. 이 옵션을 사용하면 로컬에 생성된 모든 태그를 원격 저장소로 한 번에 푸시한다.46
- –delete
원격 저장소에 있는 특정 브랜치를 삭제한다.
Bash
git push origin --delete old-feature-branch
6. 이력 조회 및 비교
프로젝트가 어떻게 변화해왔는지 추적하고, 특정 시점 간의 차이를 분석하는 것은 버전 관리의 핵심적인 역할이다. 이 섹션에서는 커밋 이력을 탐색하고 코드의 변화를 비교하는 명령어들을 소개한다.
6.1 git log
커밋 이력을 조회한다.
핵심 기능
현재 브랜치를 기준으로 커밋 이력을 시간의 역순(가장 최신 커밋이 위로)으로 보여준다. 각 커밋의 해시, 작성자, 날짜, 커밋 메시지 등 상세 정보를 제공한다.15
주요 옵션 (출력 형식 제어)
- –oneline
각 커밋을 축약된 해시와 커밋 메시지 제목만으로 구성된 한 줄로 간결하게 표시한다.15
- –graph
브랜치와 병합 이력을 ASCII 문자로 그린 그래프와 함께 보여주어, 이력의 흐름을 시각적으로 파악하기 쉽게 한다.48
- –decorate
각 커밋이 어떤 브랜치나 태그를 가리키고 있는지(예: HEAD -> main, tag: v1.0) 함께 표시한다.50
- –stat
각 커밋에서 변경된 파일들의 목록과 함께, 각 파일에서 추가되거나 삭제된 라인 수를 요약하여 보여준다.15
- -p
각 커밋에 포함된 실제 코드 변경 내용(diff)을 함께 출력한다.15
- –pretty=format:“
”
사용자가 지정한 형식으로 로그를 자유롭게 꾸밀 수 있다. %h(축약 해시), %an(작성자 이름), %ar(상대적 시간), %s(제목) 등 다양한 포맷 지정자를 조합하여 원하는 정보를 출력할 수 있다.48
Bash
git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset'
주요 옵션 (이력 필터링)
- -n
가장 최신의
- –author=“
”
지정된 작성자(author)가 만든 커밋만 필터링하여 보여준다.15
- –grep=“
”
커밋 메시지 내용에서 지정된 패턴(문자열)을 포함하는 커밋만 필터링한다.15
- –since, –until
특정 날짜를 기준으로 그 이후(–since) 또는 그 이전(–until)의 커밋만 필터링한다. “2 weeks ago”, “2023-01-01“과 같은 다양한 형식을 사용할 수 있다.48
..
branch2에는 있지만 branch1에는 없는 커밋들의 이력을 조회한다. 예를 들어 git log origin/main..main은 원격 main 브랜치와 비교하여 로컬 main 브랜치에만 있는 커밋, 즉 아직 푸시하지 않은 커밋들을 보여준다.
6.2 git show
특정 객체의 상세 정보를 조회한다.
핵심 기능
커밋, 태그, 트리(디렉토리), 블롭(파일 내용) 등 특정 Git 객체 하나의 상세한 정보를 보여준다. git log -p -1과 유사하게, 특정 커밋의 메타데이터와 함께 해당 커밋에서 발생한 모든 변경 내용을 diff 형식으로 보여주는 데 주로 사용된다.52
기본 사용법
- 가장 최근 커밋 조회
아무 인자 없이 실행하면 HEAD가 가리키는 가장 최근 커밋의 정보를 보여준다.52
Bash
git show
- 특정 커밋 조회
커밋 해시나 브랜치 이름, 태그 이름 등을 인자로 전달하여 해당 객체의 정보를 조회한다.54
Bash
git show a1b2c3d4
git show v1.0.1
- 특정 커밋의 파일 내용 조회
콜론(:)을 사용하여 특정 커밋 시점의 파일 내용을 조회한다.
Bash
git show a1b2c3d4:src/main.js
6.3 git diff
변경사항을 비교한다.
핵심 기능
두 개의 다른 소스(커밋, 브랜치, 파일, 스테이징 영역, 작업 디렉토리 등) 간의 차이점을 라인 단위로 비교하여 보여준다.56
기본 사용법
- 작업 디렉토리 vs 스테이징 영역
아무 인자 없이 실행하면, 작업 디렉토리에서 수정했지만 아직 스테이징하지 않은 변경사항을 보여준다.59
Bash
git diff
- 스테이징 영역 vs 마지막 커밋
스테이징 영역에 추가되어 다음 커밋에 포함될 예정인 변경사항을 보여준다.56
Bash
git diff --staged
- 작업 디렉토리 vs 마지막 커밋
스테이징 여부와 상관없이, 마지막 커밋 이후 작업 디렉토리에서 발생한 모든 로컬 변경사항을 보여준다.56
Bash
git diff HEAD
- 두 커밋 간의 비교
두 커밋의 해시를 지정하여 두 스냅샷 간의 전체 변경사항을 비교한다.58
Bash
git diff <commit1> <commit2>
- 두 브랜치 간의 비교
두 브랜치의 가장 최신 커밋(tip) 간의 차이를 비교한다. 이는 한 브랜치의 모든 변경사항이 다른 브랜치에 병합되기 전에 코드 리뷰를 하는 데 유용하다.58
Bash
git diff <branch1>..<branch2>
7. 변경사항 되돌리기
실수는 개발 과정의 일부이다. Git은 잘못된 변경사항을 되돌리거나 이전 상태로 돌아갈 수 있는 강력한 명령어들을 제공한다. 이 섹션에서는 이력을 보존하며 되돌리는 안전한 방법과 이력을 재작성하며 되돌리는 강력하지만 위험한 방법을 모두 다룬다.
7.1 git reset
특정 커밋으로 되돌린다 (이력 재작성).
핵심 기능
현재 브랜치가 가리키는 포인터(HEAD)를 지정된 과거의 커밋으로 이동시킨다. 이 과정에서 그 이후의 커밋들은 이력에서 사라지게 된다. 이는 로컬 저장소의 이력을 재작성하는 강력한 명령어이므로, 이미 다른 사람과 공유된 원격 저장소의 이력에 대해서는 사용하지 않아야 한다.60
reset 명령어는 세 가지 주요 모드를 가지며, 각 모드는 Git의 ‘세 개의 트리’(커밋 이력, 스테이징 인덱스, 작업 디렉토리) 중 어디까지를 되돌릴 것인지를 결정한다.
핵심 옵션 (--soft, --mixed, --hard)
- –soft
커밋만 되돌린다. HEAD 포인터만 지정된 커밋으로 이동하고, 스테이징 영역과 작업 디렉토리는 변경 전 상태 그대로 유지된다. 즉, 마지막 커밋을 취소하되, 그 커밋에 포함됐던 변경사항들은 모두 스테이징된 상태로 남는다. 여러 개의 커밋을 하나로 합치거나(squash) 마지막 커밋 메시지를 수정하고 싶을 때 유용하다.60
Bash
git reset --soft HEAD~1
- –mixed (기본값)
커밋과 스테이징을 되돌린다. HEAD 포인터를 이동시키고, 스테이징 영역의 내용도 해당 커밋의 상태와 일치하도록 되돌린다. 하지만 작업 디렉토리의 파일들은 변경되지 않고 그대로 남는다. 즉, 마지막 커밋과 git add를 모두 취소한 것과 같은 효과를 내며, 변경사항은 작업 디렉토리에 unstaged 상태로 보존된다.60
Bash
git reset --mixed HEAD~1
- –hard
커밋, 스테이징, 작업 디렉토리의 변경사항을 모두 되돌린다. HEAD, 스테이징 영역, 작업 디렉토리를 모두 지정된 커밋의 상태로 완전히 초기화한다. 지정한 커밋 이후의 모든 변경사항은 복구 불가능하게 사라진다. 데이터 손실 위험이 매우 크므로 로컬에서만 작업한 내용을 확실히 버리고 싶을 때만 극히 주의하여 사용해야 한다.60
Bash
git reset --hard HEAD~1
| 옵션 (Option) | HEAD (커밋 이력) | Staging Index (스테이징 영역) | Working Directory (작업 디렉토리) | 사용 시나리오 (Use Case) |
|---|---|---|---|---|
--soft | 변경됨 (이전 커밋으로 이동) | 유지됨 | 유지됨 | 마지막 커밋을 취소하고, 변경사항을 다시 커밋할 준비를 할 때. |
--mixed (기본) | 변경됨 (이전 커밋으로 이동) | 변경됨 (HEAD와 동기화) | 유지됨 | 마지막 커밋과 스테이징을 모두 취소하고, 변경사항을 다시 검토/수정할 때. |
--hard | 변경됨 (이전 커밋으로 이동) | 변경됨 (HEAD와 동기화) | 변경됨 (HEAD와 동기화) | 마지막 커밋 이후의 모든 변경사항을 완전히 폐기하고 싶을 때. (데이터 손실 위험) |
7.2 git revert
커밋 내용을 거꾸로 적용한다 (이력 보존).
핵심 기능
특정 커밋에서 이루어진 변경사항을 정확히 반대로 수행하는 새로운 커밋을 생성한다. 예를 들어, 특정 커밋이 파일에 한 줄을 추가했다면, revert는 그 줄을 삭제하는 새로운 커밋을 만든다. 이 방식은 기존 이력을 삭제하거나 수정하지 않고, “실수를 바로잡았다“는 사실 자체를 새로운 이력으로 추가한다. 따라서 이미 원격 저장소에 푸시되어 팀원들과 공유된 커밋을 안전하게 되돌릴 때 사용해야 한다.64
기본 사용법
- 특정 커밋 되돌리기
지정한 커밋의 변경사항을 되돌리는 새 커밋을 생성한다.
Bash
git revert <commit-hash>
- 가장 최근 커밋 되돌리기
HEAD를 사용하여 가장 최근 커밋을 되돌린다.64
Bash
git revert HEAD
주요 옵션
- –no-edit
되돌리기 커밋을 생성할 때, “Revert ‘원래 커밋 메시지’“와 같은 기본 메시지를 사용하고 편집기를 열지 않는다.66
- –no-commit 또는 -n
되돌리는 내용을 자동으로 커밋하지 않고, 작업 디렉토리와 스테이징 영역에만 적용한다. 여러 개의 커밋을 revert한 후, 그 변경사항들을 하나의 커밋으로 묶고 싶을 때 유용하다.64
7.3 git clean
추적되지 않는 파일을 삭제한다.
핵심 기능
작업 디렉토리에 있지만 Git이 버전 관리 대상으로 추적하지 않는(untracked) 파일이나 디렉토리를 영구적으로 삭제한다. 컴파일 결과물(.o, .class), 로그 파일, 임시 파일 등을 한 번에 정리하여 작업 공간을 깨끗하게 만들 때 유용하다.67
기본 사용법 및 주요 옵션
git clean은 복구가 불가능한 삭제 작업을 수행하므로, 안전을 위해 -f 옵션 없이는 실행되지 않는다. 실행 전에는 반드시 -n 옵션으로 어떤 파일이 삭제될지 확인하는 습관이 매우 중요하다.
- -n 또는 –dry-run
실제로 파일을 삭제하지 않고, 어떤 파일들이 삭제될 것인지 목록만 보여주는 ‘가상 실행(dry run)’ 모드이다. 실제 삭제 명령을 내리기 전에 반드시 이 옵션으로 결과를 예측해야 한다.67
Bash
git clean -n
- -f 또는 –force
실제로 추적되지 않는 파일들을 삭제한다. 이 옵션 없이는 기본적으로 동작이 거부된다.67
Bash
git clean -f
- -d
파일뿐만 아니라 추적되지 않는 디렉토리까지 함께 삭제한다.67
Bash
git clean -fd
- -x
.gitignore에 명시되어 Git이 평소에 무시하는 파일까지도 삭제 대상에 포함시킨다. 빌드 산출물을 포함하여 작업 디렉토리를 완전히 깨끗한 상태로 만들고 싶을 때 사용한다.67
Bash
git clean -fdx
8. 고급 및 유틸리티 명령어
기본적인 워크플로우 외에, 특정 상황에서 개발 생산성을 크게 향상시키는 유용한 명령어들이 있다. 이 섹션에서는 임시 작업 저장, 중요 지점 표시, 특정 커밋 가져오기 등의 고급 기능을 다룬다.
8.1 git stash
변경사항을 임시로 저장한다.
핵심 기능
아직 커밋하기에는 작업이 덜 끝났지만, 다른 브랜치로 전환하여 급한 버그를 수정해야 하는 등 컨텍스트를 바꿔야 할 때 사용한다. 현재 작업 디렉토리의 변경사항(staged 및 unstaged)을 ‘스택(stack)’ 구조에 임시로 저장하고, 작업 디렉토리를 마지막 커밋 상태로 깨끗하게 되돌린다. 나중에 다시 돌아와 저장해 둔 작업을 복원할 수 있다.72
기본 사용법
- git stash 또는 git stash push
현재 작업 디렉토리의 변경사항을 스태시 스택의 맨 위에 저장한다.73
Bash
git stash
- git stash list
지금까지 저장된 스태시들의 목록을 보여준다. stash@{0}이 가장 최근의 스태시다.73
- git stash apply [
]
스택에 저장된 스태시를 현재 작업 디렉토리에 다시 적용한다. 스택에서 해당 스태시는 삭제되지 않고 그대로 남는다. 인자를 생략하면 가장 최근 스태시(stash@{0})를 적용한다.73
- git stash pop [
]
apply와 동일하게 스태시를 적용하지만, 적용 성공 시 스택에서 해당 스태시를 삭제한다. 가장 일반적인 복원 방법이다.73
- git stash drop [
]
스태시를 적용하지 않고 스택에서 삭제만 한다.77
주요 옵션
- -u 또는 –include-untracked
기본적으로 스태시는 추적 중인 파일의 변경사항만 저장한다. 이 옵션을 사용하면 새로 생성되어 아직 추적되지 않는(untracked) 파일들도 스태시에 함께 포함시킨다.72
- save “메시지”
스태시를 저장할 때 설명 메시지를 함께 남길 수 있어, 나중에 여러 스태시 중에서 특정 작업을 쉽게 식별할 수 있게 해준다. 현재는 git stash push -m “메시지” 형태가 권장된다.74
Bash
git stash save "WIP: login form validation"
- branch
[ ]
스태시를 만들었던 시점의 커밋을 기반으로 새로운 브랜치를 생성하고, 해당 브랜치로 전환한 뒤 스태시를 적용하고 스택에서 삭제한다. 임시 작업 내용을 별도의 기능 브랜치로 발전시키고 싶을 때 유용하다.73
8.2 git tag
특정 커밋에 이름표를 단다.
핵심 기능
커밋 이력의 특정 지점에 영구적인 이름표(태그)를 붙인다. 주로 소프트웨어의 릴리즈 버전(예: v1.0.0)을 표시하는 데 사용된다. 브랜치는 계속해서 새로운 커밋을 따라 이동하는 포인터지만, 태그는 한번 생성되면 특정 커밋을 영구적으로 가리킨다.46
종류 및 사용법
- Lightweight Tag (경량 태그)
단순히 특정 커밋을 가리키는 이름표 역할만 하는 포인터다. 추가적인 정보는 저장하지 않으며, 개인적인 용도나 임시 표시에 적합하다.
Bash
# 현재 HEAD 커밋에 태그 생성
git tag <tag-name>
# 특정 커밋에 태그 생성
git tag <tag-name> <commit-hash>
- Annotated Tag (주석 태그)
태그를 만든 사람의 이름, 이메일, 태그 생성 날짜, 그리고 태그 메시지 등 풍부한 메타데이터를 포함하는 별도의 Git 객체로 저장된다. GPG 서명도 가능하다. 공식적인 릴리즈나 중요한 마일스톤에는 주석 태그를 사용하는 것이 권장된다.
Bash
git tag -a <tag-name> -m "태그 메시지" [<commit-hash>]
예: git tag -a v1.0 -m "Version 1.0 release".46
기타 사용법
- 태그 목록 조회
저장소에 있는 모든 태그의 목록을 보여준다.
Bash
git tag
- 로컬 태그 삭제
로컬 저장소에서 태그를 삭제한다.
Bash
git tag -d <tag-name>
- 원격 저장소에 태그 푸시
git push는 기본적으로 태그를 전송하지 않는다. 태그를 공유하려면 명시적으로 푸시해야 한다.
Bash
# 특정 태그 하나만 푸시
git push <remote> <tag-name>
# 로컬의 모든 태그를 푸시
git push <remote> --tags
8.3 git cherry-pick
특정 커밋만 가져온다.
핵심 기능
다른 브랜치에 있는 특정 커밋 하나 또는 여러 개의 변경사항을 그대로 복사하여 현재 브랜치에 새로운 커밋으로 적용한다. 브랜치 전체를 병합할 필요 없이, 다른 브랜치에서 이루어진 특정 버그 수정이나 기능 추가 커밋만을 선별적으로 가져오고 싶을 때 사용한다.79
cherry-pick은 커밋을 ’이동’시키는 것이 아니라 ’복제’하는 행위라는 점을 이해하는 것이 매우 중요하다. 원본 커밋과 동일한 코드 변경을 담고 있지만, 부모 커밋과 커밋 해시가 다른 새로운 커밋을 생성한다. 이로 인해 이력에 동일한 내용의 변경이 중복으로 기록될 수 있으며, 남용할 경우 이력 추적을 복잡하게 만들 수 있다.79 따라서
cherry-pick은 merge나 rebase를 사용할 수 없는 불가피한 상황(예: 서로 다른 릴리즈 라인 간에 핫픽스 적용)에 대한 ’외과적 수술’처럼 사용해야 하며, 일반적인 기능 통합 수단으로 사용해서는 안 된다.
기본 사용법
- 단일 커밋 가져오기
지정한 커밋 해시에 해당하는 커밋을 현재 브랜치에 적용한다.
Bash
git cherry-pick <commit-hash>
- 여러 커밋 가져오기
여러 개의 커밋 해시를 공백으로 구분하여 나열하면, 순서대로 현재 브랜치에 적용한다.80
Bash
git cherry-pick <commit1> <commit2>
- 커밋 범위 가져오기
.. 표기법을 사용하여 특정 범위에 있는 커밋들을 가져온다. 시작 커밋은 제외되고 그 다음 커밋부터 끝 커밋까지 포함된다.80
Bash
git cherry-pick <start-commit-hash>^..<end-commit-hash>
주요 옵션
- –no-commit 또는 -n
커밋의 변경사항을 작업 디렉토리와 스테이징 영역에만 적용하고, 자동으로 커밋을 생성하지는 않는다. 여러 커밋을 체리픽한 후 하나의 커밋으로 묶고 싶을 때 유용하다.79
- –continue, –abort
체리픽 과정에서 충돌이 발생했을 때 사용한다. 충돌을 수동으로 해결한 후 –continue를 사용하여 계속 진행하거나, –abort를 사용하여 체리픽 작업을 완전히 취소하고 시작 전 상태로 되돌릴 수 있다.80
9. 참고 자료
- git-init Documentation - Git, https://git-scm.com/docs/git-init
- git init - Create a new Git repository | Learn Version Control with Git - Git Tower, https://www.git-tower.com/learn/git/commands/git-init
- Git Guides - git init - GitHub, https://github.com/git-guides/git-init
- How to Create a Git Repository | Atlassian Git Tutorial, https://www.atlassian.com/git/tutorials/setting-up-a-repository
- git init | Atlassian Git Tutorial, https://www.atlassian.com/git/tutorials/setting-up-a-repository/git-init
- How to Clone a Branch in Git? | Atlassian Git Tutorial, https://www.atlassian.com/git/tutorials/setting-up-a-repository/git-clone
- 1.6 Getting Started - First-Time Git Setup, https://git-scm.com/book/ms/v2/Getting-Started-First-Time-Git-Setup
- Git Clone Command: From Basic Usage to Advanced Techniques - DataCamp, https://www.datacamp.com/tutorial/git-clone-command
- Git Guides - git clone - GitHub, https://github.com/git-guides/git-clone
- Cloning a repository - GitHub Docs, https://docs.github.com/articles/cloning-a-repository
- How to clone a git repository with git clone - Graphite, https://graphite.dev/guides/how-to-clone-a-git-repository-with-git-clone
- git-clone Documentation - Git, https://git-scm.com/docs/git-clone
- Git Status: How To Track Changes in Your Project with Confidence …, https://www.datacamp.com/tutorial/git-status
- How to use the
git statuscommand - Graphite, https://graphite.dev/guides/git-status - Git Status: Inspecting a repository | Atlassian Git Tutorial, https://www.atlassian.com/git/tutorials/inspecting-a-repository
- How to master the Git status command - The Server Side, https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opinions/How-to-master-the-Git-status-command
- git-status Documentation - Git, https://git-scm.com/docs/git-status
- Git Guides - git add - GitHub, https://github.com/git-guides/git-add
- The git add command for beginners - The Server Side, https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opinions/git-add-index-stage-file-staging-commit-combine-untracked-staging-status
- How to use the Git command git add - Graphite, https://graphite.dev/guides/git-add
- git-add Documentation - Git, https://git-scm.com/docs/git-add
- Interactive Staging - Git, https://git-scm.com/book/en/v2/Git-Tools-Interactive-Staging
- Git Commit Command Explained - freeCodeCamp, https://www.freecodecamp.org/news/git-commit-command-explained/
- Git Guides - git commit - GitHub, https://github.com/git-guides/git-commit
- git-commit Documentation - Git, https://git-scm.com/docs/git-commit
- git-commit(1) - The Linux Kernel Archives, https://www.kernel.org/pub/software/scm/git/docs/git-commit.html
- Basic Git Commands | Atlassian Git Tutorial, https://www.atlassian.com/git/glossary
- git-branch Documentation, https://git-scm.com/docs/git-branch
- Git Branches: List, Create, Switch to, Merge, Push, & Delete, https://www.nobledesktop.com/learn/git/git-branches
- Git Commands Cheat Sheet | Learn Git - GitKraken, https://www.gitkraken.com/learn/git/commands
- git checkout - Switching branches and restoring files | Learn Version Control with Git, https://www.git-tower.com/learn/git/commands/git-checkout
- git-checkout Documentation - Git, https://git-scm.com/docs/git-checkout
- Git Checkout - Checkout Branches, Commits, & Tags | Learn Git - GitKraken, https://www.gitkraken.com/learn/git/git-checkout
- Git 체크아웃에 대한 설명: Git에서 브랜치를 체크아웃(변경 또는 전환 …, https://www.freecodecamp.org/korean/news/git-cekeuause-daehan-seolmyeong-giteseo-beuraencireul-cekeuaus-byeongyeong-ddoneun-jeonhwan-haneun-bangbeob/
- git-merge Documentation - Git, https://git-scm.com/docs/git-merge
- What’s the difference between ‘git merge’ and ‘git rebase’? - Stack …, https://stackoverflow.com/questions/16666089/whats-the-difference-between-git-merge-and-git-rebase
- How to Rebase Git? | Atlassian Git Tutorial, https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase
- git-rebase Documentation - Git, https://git-scm.com/docs/git-rebase
- Merging vs. Rebasing | Atlassian Git Tutorial, https://www.atlassian.com/git/tutorials/merging-vs-rebasing
- Merge, rebase, or cherry-pick to apply changes | WebStorm Documentation - JetBrains, https://www.jetbrains.com/help/webstorm/apply-changes-from-one-branch-to-another.html
- git-remote Documentation - Git, https://git-scm.com/docs/git-remote
- Managing remote repositories - GitHub Docs, https://docs.github.com/en/get-started/git-basics/managing-remote-repositories
- git fetch, pull, push, & sync - Visual Studio (Windows) | Microsoft Learn, https://learn.microsoft.com/en-us/visualstudio/version-control/git-fetch-pull-sync?view=vs-2022
- git-fetch Documentation - Git, https://git-scm.com/docs/git-fetch
- git-pull Documentation - Git, https://git-scm.com/docs/git-pull
- Tagging - Git, https://git-scm.com/book/en/v2/Git-Basics-Tagging
- Git Tags - GeeksforGeeks, https://www.geeksforgeeks.org/git/git-tags/
- 2.3 Git Basics - Viewing the Commit History, https://git-scm.com/book/en/v2/Git-Basics-Viewing-the-Commit-History
- git log | A Guide to Using the log Command in Git - Initial Commit, https://initialcommit.com/blog/git-log
- Advanced Git Log | Atlassian Git Tutorial, https://www.atlassian.com/git/tutorials/git-log
- Git log customization | Justin Joyce, https://justinjoyce.dev/customizing-git-log-format/
- Common Git commands - GitLab Docs, https://docs.gitlab.com/topics/git/commands/
- git-show(1) - Linux manual page - man7.org, https://man7.org/linux/man-pages/man1/git-show.1.html
- Git-show | Atlassian, https://www.atlassian.com/git/tutorials/git-show
- Git Show Command Cheat Sheet - DEV Community, https://dev.to/vishnuchilamakuru/git-show-command-cheat-sheet-45ph
- Git Diff | Atlassian Git Tutorial, https://www.atlassian.com/git/tutorials/saving-changes/git-diff
- Git Diff Explained: A Complete Guide with Examples - DataCamp, https://www.datacamp.com/tutorial/git-diff-guide
- Git Diff: A Complete Comparison Tutorial for Git - CloudBees, https://www.cloudbees.com/blog/git-diff-a-complete-comparison-tutorial-for-git
- How to use the Git command git diff - Graphite, https://graphite.dev/guides/git-diff
- Git Reset | Hard, Soft & Mixed | Learn Git - GitKraken, https://www.gitkraken.com/learn/git/git-reset
- Reset Demystified - Git, https://git-scm.com/book/ms/v2/Git-Tools-Reset-Demystified
- Git Reset | Atlassian Git Tutorial, https://www.atlassian.com/git/tutorials/undoing-changes/git-reset
- version control - What’s the difference between git reset –mixed …, https://stackoverflow.com/questions/3528245/whats-the-difference-between-git-reset-mixed-soft-and-hard
- How to Revert a Commit in Git? | Atlassian Git Tutorial, https://www.atlassian.com/git/tutorials/undoing-changes/git-revert
- Resetting, Checking Out & Reverting | Atlassian Git Tutorial, https://www.atlassian.com/git/tutorials/resetting-checking-out-and-reverting
- Git Revert Explained: Safely Undoing Your Changes - CloudBees, https://www.cloudbees.com/blog/git-revert-explained
- git clean: How to remove untracked files in Git - The Server Side, https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opinions/How-to-use-the-git-clean-command
- How to use the git clean Command - Graphite, https://graphite.dev/guides/how-to-use-the-git-clean-command
- How to Remove Untracked Files in Git? | Atlassian Git Tutorial, https://www.atlassian.com/git/tutorials/undoing-changes/git-clean
- Using
git clean- Mostly Python, https://www.mostlypython.com/using-git-clean/ - git-clean Documentation - Git, https://git-scm.com/docs/git-clean
- git-stash Documentation - Git, https://git-scm.com/docs/git-stash
- Stashing and Cleaning - Git, https://git-scm.com/book/en/v2/Git-Tools-Stashing-and-Cleaning
- git stash - Saving Changes | Atlassian Git Tutorial, https://www.atlassian.com/git/tutorials/saving-changes/git-stash
- Simple git stash example | TheServerSide, https://www.theserverside.com/video/An-example-of-how-to-use-the-git-stash-command
- Git | Working with Stash - GeeksforGeeks, https://www.geeksforgeeks.org/git/git-working-with-stash/
- Git STASH Tutorial - YouTube, https://www.youtube.com/watch?v=BSLzA8oCT7g
- What Is Git Tagging? | Atlassian Git Tutorial, https://www.atlassian.com/git/tutorials/inspecting-a-repository/git-tag
- Git Cherry Pick - How to use the “cherry-pick” command in Git …, https://www.git-tower.com/learn/git/faq/cherry-pick
- Copy changes to a branch with cherry-pick - Azure Repos | Microsoft Learn, https://learn.microsoft.com/en-us/azure/devops/repos/git/cherry-pick?view=azure-devops
- How to cherry-pick commits in Git. A Step-by-Step Guide | by Yash Pandit - Medium, https://medium.com/@ypandit/how-to-cherry-pick-on-git-a-step-by-step-guide-bc4b5153331a
- Cherry-pick changes with Git - GitLab Docs, https://docs.gitlab.com/topics/git/cherry_pick/
- Git Cherry-Pick: How to Select and Apply Specific Commits - DataCamp, https://www.datacamp.com/tutorial/git-cherry-pick
- Git - Cherry Pick - GeeksforGeeks, https://www.geeksforgeeks.org/git/git-cherry-pick/