GitHub에서 이슈를 확인하려고 브라우저를 열고, PR을 만들려고 또 브라우저를 열고... 터미널에서 코딩하다가 브라우저와 터미널 사이를 왔다 갔다 하는 게 은근히 번거롭지 않으셨나요? GitHub REST API를 curl로 직접 호출하는 방법도 있지만 URL과 헤더를 매번 타이핑하는 건 솔직히 고통스럽죠. 그래서 GitHub이 만든 게 바로 gh라는 공식 CLI 도구입니다. 터미널을 떠나지 않고도 이슈부터 PR, 릴리스까지 다 처리할 수 있어요. 이번 글에서는 gh CLI의 설치부터 실무에서 자주 쓰는 핵심 명령어까지 살펴보겠
Git 작업을 할 때 에디터와 터미널을 왔다 갔다 하시나요? 코드를 수정하고 터미널로 전환해서 git diff를 확인하고 다시 에디터로 돌아오는 이 반복이 은근히 흐름을 끊죠. Zed 에디터는 Git 기능을 에디터 안에 깊이 통합해서 이런 컨텍스트 전환을 최소화해 줍니다. 단순히 변경된 파일 목록을 보여주는 수준이 아닙니다. 스테이징, 커밋, 푸시, 브랜치 관리, 스태시, 머지 충돌 해결까지 거의 모든 Git 워크플로우가 에디터 안에서 돌아가요. 심지어 AI가 커밋 메시지를 대신 써주기까지 합니다. 이 글에서는 Zed의 Git 통합
혹시 git worktree라는 Git 명령어를 아시나요? 사실 이 명령어는 Git 2.5(2015년)에 도입된 꽤 오래된 기능인데요. 그동안 잘 알려지지 않았다가 최근 Claude Code, Cursor 같은 AI 코딩 에이전트들이 적극적으로 활용하면서 다시 주목받고 있습니다. 여러 작업을 병렬로 처리하면서 변경사항을 안전하게 격리하기 위해서인데요. 이처럼 git worktree는 사람뿐 아니라 AI에게도 빠질 수 없는 도구가 되어가고 있습니다. 이번 글에서는 git worktree의 기본 개념과 실전 활용법에 대해 알아보겠습니다
소프트웨어를 릴리스할 때 "이 커밋이 v1.0.0이다"라고 표시해두면 나중에 특정 버전의 코드를 찾기가 훨씬 수월해지는데요. git tag는 바로 이런 용도로 특정 커밋에 이름표를 붙이는 명령어입니다. 커밋 해시를 외울 필요 없이 v1.0.0, v2.1.3 같은 의미 있는 이름으로 중요한 시점을 기록할 수 있죠. 태그 종류 Git 태그에는 두 가지 종류가 있습니다. Lightweight 태그는 단순히 특정 커밋을 가리키는 포인터입니다. 이름만 붙이고 별도의 정보는 저장하지 않습니다. Annotated 태그는 태그를 만든 사람, 날짜
Git으로 작업을 하다 보면 현재 브랜치에서 뭔가를 한창 수정하고 있는데 급하게 다른 브랜치로 전환해야 하는 상황이 생기곤 합니다. 아직 완성되지 않은 코드를 커밋하자니 찜찜하고 그렇다고 변경사항을 날리기엔 아까운데요. 바로 이럴 때 git stash가 유용합니다. git stash는 현재 작업 중인 변경사항을 임시로 저장해두고 나중에 다시 꺼내 쓸 수 있게 해주는 명령어인데요. 이번 글에서는 기본 사용법부터 실전에서 유용한 고급 활용법까지 함께 알아보겠습니다. 기본 사용법 git stash의 가장 기본적인 사용법은 간단합니다. 이
git restore는 작업 디렉토리(working directory)나 스테이징 영역(staging area)에 있는 파일을 이전 상태로 되돌릴 때 사용하는 Git 명령어입니다. Git 2.23 버전(2019년 8월)에서 처음 도입되었는데요, 기존 git checkout의 파일 복원 기능을 좀 더 명확하고 안전하게 쓸 수 있도록 만들어졌습니다. 레거시 명령어인 git checkout에 대해서는 별도의 포스팅에서 다루고 있으니 참고 바랍니다. 작업 디렉토리의 변경사항 되돌리기 코드를 수정하다 보면 변경한 내용이 마음에 들지 않아서
Git으로 작업하다 보면 방금 한 커밋을 취소하고 싶거나, 스테이징한 파일을 다시 내리고 싶을 때가 있죠. 이럴 때 가장 먼저 떠오르는 명령어가 바로 git reset입니다. git reset은 현재 브랜치의 HEAD 위치를 옮기면서 커밋 히스토리와 스테이징 영역, 작업 디렉토리의 상태를 조절할 수 있는 강력한 명령어인데요. 그만큼 옵션에 따라 동작이 크게 달라지기 때문에 제대로 이해하고 써야 합니다. 이번 글에서는 git reset의 세 가지 모드를 중심으로 기본 개념부터 실전 활용법까지 함께 알아보겠습니다. HEAD가 무엇인지
코드를 수정하다 보면 "내가 방금 뭘 바꿨더라?" 하는 순간이 자주 찾아옵니다. 여러 파일을 동시에 고치고 있으면 어디를 얼마나 바꿨는지 감을 잃기 쉽죠. git diff는 변경 내용을 한눈에 확인할 수 있게 해주는 명령어인데요. 작업 디렉토리, 스테이징 영역, 커밋 사이의 차이를 비교해주기 때문에 커밋 전에 변경 내용을 점검하거나 브랜치 간 차이를 파악할 때 쓸 일이 많습니다. 이번 글에서는 git diff의 기본 사용법부터 실전에서 유용한 옵션까지 함께 알아보겠습니다. 기본 사용법 git diff를 인자 없이 실행하면 작업 디렉
git fetch는 원격 저장소(remote repository)의 최신 변경분을 로컬로 가져오되, 현재 작업 중인 코드에는 영향을 주지 않는 명령어입니다. git pull과 혼동하기 쉬운데, git pull이 가져오기와 합치기를 한번에 하는 반면, git fetch는 가져오기만 하고 합치는 건 개발자에게 맡깁니다. git fetch vs. git pull 이 둘의 관계를 코드로 표현하면 다음과 같습니다. git fetch는 원격 저장소의 변경 내용을 origin/main 같은 원격 추적 브랜치(remote-tracking bran
팀 프로젝트를 하다 보면 동료가 올린 코드를 내 로컬에 반영해야 하는 상황이 자주 생기는데요. 이때 사용하는 명령어가 바로 git pull입니다. git pull은 원격 저장소(remote repository)의 최신 변경분을 가져와서 현재 브랜치에 합치는 과정을 한 번에 처리해줍니다. git fetch + git merge git pull은 사실 두 가지 명령어를 연달아 실행하는 것과 같습니다. 먼저 git fetch로 원격 저장소의 변경 내용을 로컬로 가져오고, 그 다음 git merge로 현재 브랜치에 합칩니다. 이 두 단계를
Git으로 프로젝트를 진행하다 보면 "지난주에 이 파일 누가 수정했지?" "이 기능은 언제 추가된 거야?" 같은 궁금증이 생기기 마련입니다. 이럴 때 커밋 히스토리를 살펴볼 수 있는 git log 명령어가 유용한데요. git log는 저장소의 커밋 기록을 시간 역순으로 보여주는 명령어입니다. 단순히 커밋 목록만 나열하는 게 아니라 옵션을 조합하면 원하는 정보만 골라서 볼 수 있어서 코드 리뷰나 디버깅, 릴리스 관리 등 여러 상황에서 두루 쓰이죠. 이번 글에서는 git log의 기본 사용법부터 실전에서 유용한 옵션까지 함께 알아보겠습
이번 포스팅에서는 Git 설정을 위해 사용하는 git config 명령어에 대해서 알아보겠습니다. 설정 범위와 설정 파일 git config 명령어에 대해서 배우기 전에 먼저 간단하게 설정 범위에 대해서 짚고 넘어가겠습니다. Git은 지역(local), 전역(global), 시스템(system) 이렇게 크게 3가지 범위로 설정이 가능한데요. 지역 범위로 설정하면 특정 저장소(repository)로 한정되고, 전역 범위는 현재 사용자(user)의 모든 저장소를 포함시킵니다. 자주 사용되지는 않지만 시스템 범위로 설정하면 해당 컴퓨터의
Git으로 작업하다 보면 "이 커밋에서 뭘 변경했더라?" 하고 궁금해지는 순간이 많습니다. git log로 커밋 목록은 볼 수 있지만 각 커밋의 실제 변경 내용까지 바로 확인하기는 어렵죠. 바로 이럴 때 git show가 유용합니다. git show는 커밋의 메타 정보와 변경 내용을 한 번에 보여주는 명령어인데요. 커밋뿐만 아니라 태그나 브랜치, 특정 파일까지 다양한 Git 객체의 내용을 살펴볼 수 있습니다. 이번 글에서는 git show의 기본 사용법부터 실전에서 유용한 팁까지 함께 알아보겠습니다. 기본 사용법 git show를
이번 포스팅에서는 .gitignore 파일을 이용하여 Git으로 프로젝트의 버전 관리를 할 때 특정 파일이나 디렉토리를 제외시키는 방법에 대해서 알아보겠습니다. 버전 관리를 하지 않는 파일과 디렉토리 어떤 프로그래밍 언어로 프로젝트를 하든 버전 관리를 할 필요가 없거나 하지 말아야하는 파일이나 디렉토리가 생기기 마련입니다. 대표적인 예로, 자바스크립트(JavaScript) 프로젝트에서는 의존성을 설치하고 나면, 프로젝트에 node_modules 디텍토리가 생성되고 그 안에 npm 저장소로 부터 내려받은 라이브러리 코드가 저장됩니다.
Git으로 협업하다 보면 커밋 이력이 점점 복잡해지는 경험을 한 번쯤 해보셨을 텐데요. git rebase는 커밋 이력을 깔끔하게 재정리해주는 명령어입니다. git merge와 비슷하게 브랜치를 합치는 역할을 하지만, 이력을 다루는 방식에서 큰 차이가 있습니다. merge vs. rebase merge와 rebase의 차이를 그림으로 살펴보겠습니다. main에서 feature 브랜치를 만든 뒤, 양쪽 모두 새 커밋이 생긴 상황입니다. 여기서 merge를 하면 두 브랜치를 합치는 병합 커밋(M)이 생깁니다. 반면 rebase를 하면
Git을 사용한 개발에서 브랜치를 나누어 작업하는 건 기본 중의 기본인데요. 각자의 브랜치에서 작업을 마치고 나면 결국 그 변경 내용을 하나로 합쳐야 합니다. 이때 사용하는 명령어가 git merge입니다. 기본 사용법 git merge는 다른 브랜치의 변경 내용을 현재 브랜치에 합치는 명령어입니다. 예를 들어, feature/login 브랜치의 작업을 main 브랜치에 합치려면 먼저 main으로 이동한 뒤 merge합니다. 이렇게 하면 feature/login에서 작업한 모든 커밋이 main 브랜치에 반영됩니다. Fast-forw
Git을 사용하다 보면 HEAD라는 단어를 자주 접하게 됩니다. git log를 실행하면 (HEAD -> main)이라고 표시되고, git reset HEAD~1처럼 명령어에서도 자주 등장하죠. 하지만 HEAD가 정확히 무엇인지 물어보면 선뜻 대답하기 어려운 분들이 많습니다. "현재 브랜치를 가리키는 거 아니야?"라고 생각할 수 있지만, 사실 HEAD는 그보다 조금 더 복잡한 개념입니다. 이번 글에서는 HEAD의 정확한 의미와 함께, 실무에서 유용하게 활용할 수 있는 HEAD~, HEAD^ 같은 표현식까지 알아보겠습니다. HEAD란
git checkout은 Git에서 브랜치를 전환하고, 파일을 복원하고, 특정 커밋으로 이동하는 등 다양한 작업을 수행할 수 있는 만능 명령어입니다. 마치 도서관에서 책을 check out, 즉 대여하는 것처럼 특징 브랜치나 커밋의 내용을 작업 디렉토리로 가져온다고 생각하시면 됩니다. 브랜치 전환 가장 기본적인 사용법은 이미 존재하는 브랜치로 전환하는 것입니다. 예를 들어, main 브랜치로 전환하려면 다음과 같이 입력합니다. feature/user-auth라는 이름의 feature 브랜치로 전환할 수도 있습니다. 몇 가지 유용한
git switch는 브랜치를 전환하기 위해서 사용하는 Git 명령어입니다. Git 2.23 버전(2019년 8월)에서 처음 도입되었으며, 기존 git checkout 명령어의 브랜치 전환 기능을 좀 더 명확하고 안전하게 사용할 수 있도록 설계되었습니다. 레거시 명령어인 git checkout에 대해서는 별도 포스팅에서 다루고 있으니 참고 바랍니다. 브랜치 전환 가장 기본적인 사용법은 이미 존재하는 브랜치로 전환하는 것입니다. 예를 들어, main 브랜치로 전환하려면 다음과 같이 입력합니다. feature/user-auth라는 이름
Git은 분산 버전 관리 시스템이라서 하나의 프로젝트에 여러 원격 저장소(remote repository)를 연결할 수 있습니다. git remote 명령어는 이런 원격 저장소들을 관리하는 데 사용하는데요. 원격 저장소를 추가하거나, 연결 상태를 확인하거나, 더 이상 필요 없는 원격을 삭제할 때 모두 이 명령어를 씁니다. 원격 저장소 목록 확인 가장 기본적인 사용법은 현재 등록된 원격 저장소의 이름을 확인하는 것입니다. git clone으로 저장소를 복제하면 기본적으로 origin이라는 이름으로 원격 저장소가 자동 등록됩니다. -v