Git Commands Cheat Sheet: The 20 Commands You Actually Need — cod-ai.com

내가 Git을 가르치는 방식을 바꾼 새벽 3시의 생산 위기

화요일 새벽 3시 17분, 내 전화가 알림으로 폭발했다. 우리의 주요 생산 브랜치가 무너졌고, 배포가 실패했으며, 아무도 무슨 일이 잘못되었는지 파악할 수 없었다. 나는 호출된 선임 DevOps 엔지니어였고, 내 노트북으로 비틀거리며 다가가면서 나는 정확히 무슨 일이 일어났는지 알고 있었다 — 누군가 이해하지 못한 채 메인 브랜치에 강제로 푸시했다.

그 사건은 약 47,000달러의 수익 손실을 초래했으며, 4시간 다운타임 동안 발생했다. 하지만 더 중요하게는, 나에게 중요한 것을 가르쳐주었다: 대부분의 개발자는 실제로 200개의 Git 명령어를 알아야 할 필요가 없다. 그들은 약 20개의 명령어를 숙달하고, 재앙적인 실수를 피할 수 있을 만큼 깊이 이해해야 한다.

나는 마커스 첸이고, 지난 12년 동안 주로 중대형 SaaS 기업에서 DevOps 엔지니어 및 기술 리드로 일해왔다. 나는 150명 이상의 개발자를 온보드했고, 수천 개의 풀 리퀘스트를 검토했으며, 기억하기 싫은 수많은 Git 재해를 정리했다. 내가 배운 것은 Git 마스터리가 모든 플래그와 옵션을 암기하는 것이 아니라는 것이다 — 신뢰할 수 있는 정신 모델을 가지고 특정 상황에서 정확히 어떤 명령어를 사용해야 하는지를 아는 것이다.

이 치트 시트는 10년 이상의 실제 Git 사용에서 얻은 정제를 보여준다. 이것들은 내가 문서에서 찾은 이론적인 명령어가 아니다. 이들은 내가 거의 매일 사용하는 20개의 명령어로, 매 새로운 팀원에게 가르치는 것이며, 나의 팀이 수많은 고통의 시간을 절약하게 해준 명령어들이다. 여기 있는 각 명령어는 실용적인 필요에서 그 자리를 얻었으며, 학문적인 완전성을 위해서가 아니다.

본격적으로 시작하기 전에 한 가지 분명히 해두고 싶다: 이것은 Git에 대한 초보자의 소개가 아니다. 버전 관리가 완전히 처음이라면 다른 곳에서 기초부터 시작해야 한다. 이 가이드는 이미 Git이 존재한다는 것을 알고 사용해본 개발자들을 위한 것으로, 효율성과 자신감을 높이고 싶어하는 이들을 위한 것이다. 반복해서 같은 명령어를 구글링하는 것에 지쳤다면, 전문적으로 Git을 생산 환경에서 사용하는 방식을 실제로 반영하는 커뮤니티에 의해 선별된 전투 테스트된 참고자료를 원할 것이다.

기초: 매일 사용할 명령어

절대적으로 필수적인 것들로 시작하자 — 너의 일상 Git 작업 흐름의 근본을 형성하는 명령어들. 나는 이 명령어들을 너무 자주 사용해서 거의 근육 기억 같다. 어떤 규모의 팀에서 일하고 있다면, 이들 각각을 하루에 최소 한 번, 종종 여러 번 사용할 것이다.

"Git 마스터리는 모든 플래그와 옵션을 암기하는 것이 아니다 — 신뢰할 수 있는 정신 모델을 가지고 특정 상황에서 정확히 어떤 명령어를 사용해야 하는지를 아는 것이다."

git status — 이것은 상황 인식 명령어다. 나는 아마 하루에 30-40번 이 명령어를 실행하는데, 과장하지 않는다. 커밋하기 전에, 커밋한 후에, 뭔가 이상하게 느껴질 때, 작업 간 전환을 할 때 — git status는 너의 현재 상황을 정확하게 알려준다. 어떤 파일이 스테이징 되었는지, 어떤 파일이 수정되었지만 스테이징 되지 않았는지, 어떤 파일이 추적되지 않았는지를 보여준다. 이것을 너의 Git 나침반으로 생각하라. 출력 결과는 색상으로 구분되어 있고, 놀랍게도 명확하다. 따라서 이것은 내가 누구에게나 가르치는 첫 번째 명령어이다.

git add — 이것은 커밋을 위해 너의 변경사항을 스테이징한다. 가장 일반적인 사용법은 git add .로 현재 디렉터리의 모든 것을 스테이징하는 것이지만, 나는 사실보다 더 선택적으로 하는 것을 권장한다. 특정 파일을 스테이징할 때는 git add filename을 사용하거나, 개별 변경 사항의 청크를 검토하고 스테이징할 수 있는 인터랙티브 스테이징에 대해서는 git add -p를 사용할 수 있다. 이 세밀한 제어는 내가 여러 관련 없는 변경을 하던 중에 그들을 별도로 커밋해야 할 필요가 있을 때 수없이 나를 구해주었다. 내 경험상, git add를 무신경하게 사용하는 개발자들은 디버깅 및 코드 리뷰를 상당히 어렵게 만드는 엉망진창 커밋 이력을 만든다.

git commit -m "message" — 이것은 너의 스테이징된 변경의 스냅샷을 생성한다. -m 플래그는 너가 인라인으로 커밋 메시지를 추가할 수 있게 해준다. 이제, 내가 몇 가지 교훈을 공유하겠다: 너의 커밋 메시지는 생각보다 훨씬 더 중요하다. 나는 특정 변경이 왜 이루어졌는지 이해하기 위해 몇 시간을 보낸 뒤, "fix stuff" 또는 "updates"라는 커밋 메시지를 발견한 적이 있다. 좋은 커밋 메시지는 다음 문장을 완성해야 한다: "적용될 경우, 이 커밋은..." 예를 들어: "적용될 경우, 이 커밋은 로그인 엔드포인트에 사용자 인증을 추가할 것입니다." 이러한 규율은 내 팀의 코드 고고학을 무한히 쉽게 만들어 주었다.

git push — 이것은 너의 로컬 커밋을 원격 저장소에 업로드한다. 가장 일반적으로, git push origin branch-name를 사용할 것이다. 새 브랜치를 처음으로 푸시할 때는 git push -u origin branch-name을 사용해야 하며, 여기서 -u 플래그는 추적을 설정하여 이후의 푸시는 그냥 git push로 할 수 있도록 만들어 준다. 이 점을 강조하고 싶다: 공동 브랜치에서 git push --force를 절대 사용하지 마라; 네가 무슨 일을 하고 있는지 확실히 알고 팀과 소통하지 않는 한 말이다. 내가 언급한 그 새벽 3시 사건? 그것은 잘못된 강제 푸시였다.

git pull — 이것은 원격 저장소에서 변경 사항을 가져오고 현재 브랜치에 병합한다. 나는 매 작업 세션을 시작할 때 항상 git pull을 실행하여 최신 코드로 작업하고 있는지 확인한다. 이해해야 할 중요한 점은: git pull은 사실 두 개의 명령어를 결합한 것 — git fetch와 git merge이다. 때로는 더 많은 제어를 위해 이 둘을 각각 사용할 필요가 있으며, 이에 대해서는 나중에 논의할 것이다. 직면한 충돌이 있을 경우 Git은 정확히 어떤 파일에서 충돌이 발생했는지를 알려주며, 계속 진행하기 전에 수동으로 해결해야 한다.

브랜칭: 너의 평행우주 도구 키트

브랜칭은 Git의 진정한 힘이 드러나는 곳이다. 여러 개발자가 서로의 발을 밟지 않고 동시에 다양한 기능에서 작업할 수 있게 해준다. 현재 23명의 개발자로 구성된 내 팀은 어느 시점에서나 통상 40-60개의 활성 브랜치를 가지고 있다. 이러한 브랜칭 명령어를 마스터하는 것은 캐주얼 Git 사용자와 자신감 있는 전문가를 구분짓는 요소이다.

git branch — 실행