Git 스테이징과 커밋 마스터하기: 첫 번째 변경사항

Git 스테이징과 커밋 기본기를 마스터하는 것은 Git을 자신 있게 사용하기 위한 첫 번째 실제 단계입니다. 스테이징을 사용하면 다음 스냅샷에 정확히 무엇을 포함할지 선택할 수 있고, 커밋은 미래의 독자가 이해할 수 있는 메시지와 함께 해당 스냅샷을 기록합니다.

모든 커밋을 작고 검토 가능한 작업 단위로 취급하면 Git을 훨씬 쉽게 사용할 수 있습니다. 변경사항을 검사하고, 관련 없는 편집을 분리하고, 당황하지 않고 실수에서 복구할 수 있습니다.

스테이징 영역이 작동하는 방식

Git은 편집한 모든 파일을 자동으로 커밋하지 않습니다. 작업을 작업 트리, 스테이징 영역, 커밋된 히스토리로 분리합니다.

작업 트리는 프로젝트 폴더입니다. 편집기에서 편집하는 파일들입니다.

스테이징 영역은 다음 커밋을 위한 Git의 체크리스트입니다. git add를 실행할 때 아직 히스토리를 저장하는 것이 아닙니다. 다음 커밋을 위한 변경사항을 선택하는 것입니다.

저장소 히스토리는 이미 기록된 커밋들의 순서입니다.

상태를 확인하는 것으로 시작하세요:

git status

Git은 추적되지 않은 파일, 수정된 파일, 스테이징된 변경사항 및 현재 브랜치를 표시합니다. 이 명령어는 언제든지 실행해도 안전하며 습관이 되어야 합니다.

새 파일이나 수정된 파일을 스테이징하려면:

git add README.md

현재 디렉토리 아래의 모든 변경사항을 스테이징하려면:

git add .

이 명령어는 편리하지만 주의해서 사용하세요. .gitignore가 완전하지 않으면 관련 없는 파일, 로컬 설정 또는 생성된 출력물을 스테이징할 수 있습니다.

더 안전한 검토를 위해 먼저 diff를 확인하세요:

git diff

그런 다음 함께 속하는 변경사항만 스테이징하세요:

git add src/app.js
git add README.md

스테이징 후, 커밋될 내용을 확인하세요:

git diff --staged

이것은 정확한 스테이징된 스냅샷을 보여줍니다. 잘못된 것이 있으면 커밋하기 전에 수정하세요.

첫 번째 커밋 만들기

올바른 변경사항이 스테이징되면 커밋을 생성하세요:

git commit -m "프로젝트 README 추가"

메시지는 변경사항을 설명해야 하며, 당신이 취한 행동을 설명해서는 안 됩니다. "프로젝트 README 추가"는 "변경사항"이나 "파일 업데이트"보다 더 유용합니다.

좋은 커밋은 일반적으로 하나의 명확한 목적을 가집니다. 예를 들어, 배포 스크립트를 업데이트하고 문서 페이지의 오타를 수정했다고 가정해 보세요. 이들은 별개의 변경사항입니다. 별도로 스테이징하고 커밋하세요:

git add scripts/deploy.sh
git commit -m "배포 상태 확인 추가"

git add docs/setup.md
git commit -m "설정 가이드 오타 수정"

이렇게 하면 검토가 더 쉬워집니다. 또한 배포 변경으로 문제가 발생해도 문서 수정은 괜찮은 경우 롤백이 더 쉬워집니다.

-m 없이 git commit을 실행하면 Git이 편집기를 엽니다. 더 긴 메시지가 필요할 때 유용합니다:

배포 상태 확인 추가

서비스 엔드포인트를 확인하여 배포 완료를 표시하기 전에 검증합니다.
이렇게 하면 릴리스 프로세스 초기에 실패한 시작을 더 빨리 잡을 수 있습니다.

첫 번째 줄은 짧고 직접적이어야 합니다. 본문은 변경이 필요한 이유나 절충점을 언급할 수 있습니다.

최근 커밋을 보려면:

git log --oneline -5

이것은 최신 히스토리의 간결한 보기를 제공합니다.

파일의 일부 스테이징

때로는 하나의 파일에 여러 개의 관련 없는 편집이 포함될 수 있습니다. Git은 패치 모드로 파일의 일부만 스테이징할 수 있습니다:

git add -p src/config.js

Git은 각 변경 청크를 보여주고 무엇을 할지 묻습니다. 일반적인 선택지는:

• y: 이 청크를 스테이징합니다.
• n: 이 청크를 스테이징하지 않습니다.
• s: 가능하면 청크를 더 작은 조각으로 나눕니다.
• q: 패치 모드를 종료합니다.

패치 스테이징은 커밋 전에 정리할 때 유용합니다. 예를 들어, 새 타임아웃 설정을 추가하고 주석 형식을 다시 지정한 파일이 있을 수 있습니다. 타임아웃 변경을 한 커밋으로 스테이징하고, 주석 정리를 다른 커밋으로 스테이징하세요.

실수로 무언가를 스테이징했다면 작업을 폐기하지 않고 스테이징을 해제하세요:

git restore --staged src/config.js

파일은 작업 트리에서 수정된 상태로 유지됩니다. 단순히 스테이징 영역에서 제거됩니다.

파일의 스테이징되지 않은 변경사항을 폐기하려면 주의하세요:

git restore src/config.js

이 명령어는 해당 파일의 로컬 편집을 삭제합니다. 먼저 git diff를 실행하여 무엇을 잃을지 확인하세요.

더 많은 복구 패턴은 Git 실수 취소 방법을 참조하세요.

일상 작업을 위한 커밋 위생

작고 집중된 커밋은 검토, 테스트 및 되돌리기가 더 쉽습니다. 또한 버그가 시작된 위치를 찾아야 할 때 git bisect와 같은 도구를 더 유용하게 만듭니다.

다음 습관을 사용하세요:

• 스테이징 전에 git status를 실행하세요.
• git add 전에 git diff를 검토하세요.
• 커밋 전에 git diff --staged를 검토하세요.
• 관련 없는 변경사항은 별도의 커밋으로 유지하세요.
• 무엇이 변경되었는지 설명하는 메시지를 작성하세요.
• 프로젝트에서 예상하지 않는 한 생성된 파일을 커밋하지 마세요.
• 비밀, 개인 키 또는 로컬 .env 값을 절대 커밋하지 마세요.

실용적인 워크플로우는 다음과 같을 수 있습니다:

git status
git diff
git add src/server.js
git diff --staged
git commit -m "누락된 상태 확인 응답 처리"
git status

이 순서는 화려하지 않지만 대부분의 초보자 실수를 잡아냅니다. 무엇이 변경되었는지, 무엇이 스테이징되었는지, 무엇이 커밋되었는지, 그리고 무엇이 남아 있는지 알 수 있습니다.

팀에서 사전 커밋 훅이나 자동화된 포맷팅을 사용하는 경우, 포맷팅이나 테스트를 수정할 때까지 커밋이 실패할 수 있습니다. 오류 메시지를 읽고, 제안된 명령어를 실행하고, 결과 변경사항을 스테이징한 다음 다시 커밋하세요.

도움을 요청해야 할 때

실수로 비밀을 스테이징하거나 커밋했거나, 잘못된 브랜치에 커밋했거나, 수정, 되돌리기, 리셋 또는 새 커밋을 만들어야 할지 확실하지 않은 경우 도움을 요청하세요. 이러한 선택은 특히 푸시 후에 다른 영향을 미칩니다.

또한 다른 사람이 가져왔을 수 있는 커밋을 다시 작성하기 전에 물어보아야 합니다. 간단한 로컬 정리가 공유 히스토리를 변경하면 팀 문제로 이어질 수 있습니다.

스테이징과 커밋은 Git의 핵심 루프입니다. 변경사항을 검토하고, 의도적으로 스테이징하고, 집중된 조각으로 커밋하고, 한 달 후에도 이해할 수 있는 메시지를 작성하세요.