Git 워크플로우 향상: 필수 커맨드라인 도구와 GUI

Git은 빠르고 확장 가능하며 분산된 버전 관리 시스템으로, 현대 소프트웨어 개발 워크플로우의 근간을 이룹니다. 핵심 커맨드라인 인터페이스는 버전 관리에 대한 강력한 제어를 제공하지만, 방대한 명령어 세트와 특화된 커맨드라인 도구 및 그래픽 사용자 인터페이스(GUI)를 이해하고 활용하면 생산성을 크게 향상시키고 복잡한 작업을 단순화할 수 있습니다. 이 가이드는 실제 워크플로우 문제를 해결하는 도구에 초점을 맞춥니다: 깔끔한 커밋 준비, 히스토리 읽기, diff 검토, 변경 사항을 놓치지 않고 브랜치 처리하기.

여기 있는 모든 도구가 필요하지는 않습니다. 일상 작업을 더 명확하게 만들어 주는 최소한의 세트를 선택하세요.

핵심 Git 워크플로우: 필수 커맨드라인 작업

Git은 최종 사용자를 위한 고수준 "porcelain" 명령어와 스크립팅 및 내부 객체 관리를 위한 저수준 "plumbing" 명령어로 분류되는 풍부한 명령어 세트를 제공합니다. 여기서는 일상 작업에 필수적인 porcelain 명령어에 초점을 맞춥니다.

저장소 시작하기

새 프로젝트를 시작하거나 기존 프로젝트에 참여하려면 다음 명령어가 출발점입니다:

새 Git 저장소 초기화:
```
git init
```
URL에서 기존 저장소 복제:
```
git clone <url>
```

변경 사항 관리 (스테이징 및 커밋)

커밋하기 전에 Git은 "스테이징 영역"(인덱스라고도 함)을 사용하여 변경 사항을 준비합니다. 이를 통해 각 커밋에 포함될 내용을 세밀하게 제어할 수 있습니다.

특정 파일을 스테이징 영역에 추가:
```
git add <file>
```
추적되지 않은 모든 파일과 수정된 파일을 스테이징 영역에 추가:
```
git add .
```
파일의 일부(hunk)를 대화형으로 스테이징:
```
git add -p
```
파일 이동 또는 이름 변경:
```
git mv <old> <new>
```
작업 디렉토리와 스테이징 영역에서 파일 삭제:
```
git rm <file>
```
파일 시스템에서 삭제하지 않고 Git 추적에서 파일 제거:
```
git rm --cached <file>
```
특정 파일 스테이징 해제:
```
git reset <file>
```
모든 변경 사항 스테이징 해제:
```
git reset
```
작업 디렉토리와 스테이징 영역의 상태 확인:
```
git status
```

변경 사항이 스테이징되면 커밋할 수 있습니다:

스테이징된 변경 사항 커밋 (메시지 작성을 위해 편집기 열림):
```
git commit
```
메시지와 함께 스테이징된 변경 사항 커밋:
```
git commit -m '커밋 메시지'
```
추적된 모든 스테이징되지 않은 변경 사항을 직접 커밋 (수정 사항에 대해 git add 생략):
```
git commit -am '커밋 메시지'
```

브랜치 및 병합

브랜치는 Git의 분산 특성의 기본으로, 병렬 개발을 가능하게 합니다. 병합과 리베이스는 변경 사항을 통합하는 방법입니다.

기존 브랜치로 전환:

git switch <name>
# 또는 (이전 구문)
git checkout <name>

새 브랜치를 생성하고 전환:

git switch -c <name>
# 또는 (이전 구문)
git checkout -b <name>

모든 로컬 브랜치 나열:
```
git branch
```
최근 커밋 순으로 브랜치 나열:
```
git branch --sort=-committerdate
```
로컬 브랜치 삭제 (병합된 경우만):
```
git branch -d <name>
```
로컬 브랜치 강제 삭제 (병합되지 않은 경우도 가능):
```
git branch -D <name>
```
한 브랜치를 현재 브랜치에 병합:
```
git merge <branch-to-merge>
```
한 브랜치를 단일 커밋으로 현재 브랜치에 병합 (스쿼시 병합):
```
git merge --squash <branch-to-merge>
git commit -m '스쿼시 커밋 메시지'
```
현재 브랜치를 다른 브랜치 위로 리베이스 (히스토리 다시 쓰기):
```
git rebase <base-branch>
```

원격 저장소와의 협업

Git은 협업 환경에서 뛰어나며, 원격 저장소에서 변경 사항을 푸시하고 풀합니다.

새 원격 저장소 추가:
```
git remote add <name> <url>
```
현재 브랜치를 원격 추적 브랜치로 푸시:
```
git push
```
새 브랜치를 처음으로 푸시하고 업스트림 설정:
```
git push -u origin <name>
```
강제 푸시 (매우 주의해서 사용, 원격 히스토리 덮어쓰기):
```
git push --force-with-lease
```
원격에서 변경 사항 가져오기 (로컬 브랜치에 통합하지 않음):
```
git fetch origin main
```

변경 사항을 가져와 현재 브랜치에 병합:

git pull origin main
# 또는 (추적 브랜치가 설정된 경우)
git pull

변경 사항을 가져와 현재 브랜치를 리베이스:
```
git pull --rebase
```

히스토리 및 Diff 검사

무엇이 변경되었고 누가 변경했는지 이해하는 것은 디버깅과 리뷰에 중요합니다.

스테이징된 모든 변경 사항과 스테이징되지 않은 변경 사항의 요약 표시:
```
git diff HEAD
```
스테이징된 변경 사항의 diff만 표시:
```
git diff --staged
```
스테이징되지 않은 변경 사항의 diff만 표시:
```
git diff
```
커밋 로그 보기 (다양한 옵션):
```
git log # 전체 로그
git log --graph # ASCII 아트 히스토리 트리
git log --oneline # 각 커밋을 한 줄로 간결하게
git log <file> # 특정 파일의 히스토리
git log --follow <file> # 이름 변경을 포함한 히스토리
git log -G <pattern>
```
git log -G <pattern>은 일치하는 줄 수가 변경된 커밋을 찾습니다. 예를 들어, git log -G "timeout" -- app/는 서비스 디렉토리에서 타임아웃 처리가 언제 변경되었는지 알아야 할 때 유용합니다.

Git을 더 쉽게 만드는 커맨드라인 도구

기본 Git CLI는 기준으로 유지해야 합니다. 추가 도구는 Git이 하는 일을 숨기지 않고 상태를 더 쉽게 볼 수 있게 해줄 때 가장 좋습니다.

lazygit는 hunk 스테이징, 커밋 탐색, 간단한 충돌 해결, 브랜치 푸시를 위한 대화형 터미널 UI를 제공합니다. 터미널에서 작업하면서 시각적 개요를 원할 때 유용합니다.

tig는 히스토리 탐색을 위한 빠른 텍스트 UI입니다. 전체 데스크탑 GUI를 사용할 수 없는 서버나 원격 개발 환경에서 특히 좋습니다.

delta는 구문 강조와 더 명확한 이동된 줄 표시로 Git diff를 개선합니다. 설치 후 일반적인 설정은 다음과 같습니다:

git config --global core.pager delta
git config --global interactive.diffFilter "delta --color-only"

터미널 색상에 맞는 옵션은 delta의 문서를 확인하세요. 처음에는 구성을 작게 유지하여 일반 Git 출력을 쉽게 복구할 수 있도록 하세요.

저장소 정리나 민감한 히스토리 제거의 경우, git-filter-repo가 이전의 git filter-branch보다 일반적으로 선호됩니다. 히스토리 재작성은 항상 팀 작업으로 취급하세요. 커밋 ID가 변경되고 저장소를 사용하는 모든 사람이 신중하게 재동기화해야 합니다.

GUI가 더 나은 도구인 경우

GUI는 광범위한 변경 사항 검토, 브랜치 비교, 또는 시각적으로 생각하는 사람에게 Git 개념을 가르칠 때 적합한 선택이 될 수 있습니다. GitHub Desktop, GitKraken, Sourcetree, Fork 및 IDE 통합과 같은 도구는 스테이징 및 히스토리 검사를 더 쉽게 만들 수 있습니다.

구체적인 질문에 답하는 데 도움이 될 때 GUI를 사용하세요:

이 브랜치에서 어떤 파일이 변경되었나요?
이 브랜치에 고유한 커밋은 무엇인가요?
이 이름 변경 또는 리팩토링이 실제로 무엇을 건드렸나요?
충돌의 어느 쪽을 유지해야 하나요?

기본 명령어를 이해하는 대신 GUI를 사용하지 마세요. 푸시가 실패하거나, 리베이스 충돌이 발생하거나, CI가 분리된 커밋을 체크아웃할 때 오류 메시지와 복구 단계는 여전히 Git 개념입니다.

일상 작업을 위한 실용적인 설정

균형 잡힌 워크플로우는 다음과 같을 수 있습니다:

git status
git add -p
git diff --staged
git commit -m "헬스 체크 엔드포인트 추가"
git pull --rebase
git push -u origin feature/health-check

그런 다음 git log --oneline --graph --decorate --all 또는 GUI를 사용하여 브랜치가 더 넓은 히스토리에 어떻게 맞는지 검사하세요.

별칭을 추가하는 경우 명확하게 유지하세요:

git config --global alias.st status
git config --global alias.lg "log --oneline --graph --decorate --all"
git config --global alias.unstage "restore --staged"

별칭은 이미 이해하는 명령어를 단축해야 합니다. 이름이 명백하지 않은 한 파괴적인 작업을 수행하는 별칭은 피하세요.

최종 요점

압박 속에서 이해해야 하는 작업에는 Git CLI를 사용하세요: status, diff, add, commit, branch, fetch, pull, push, merge, rebase. 가시성을 향상시키는 곳에 터미널 도구나 GUI를 추가하세요. 최고의 워크플로우는 가장 많은 도구를 가진 것이 아니라, 변경 사항을 공유하기 전에 명확하게 볼 수 있게 해주는 것입니다.