PR 하나에 파일 30개가 바뀌고 코드가 2,000줄 넘게 추가된 걸 리뷰해달라고 받아본 적 있으신가요? 😅 리뷰어 입장에서는 어디서부터 봐야 할지 막막하고, 작성자 입장에서는 피드백을 기다리는 시간이 길어지죠. "PR은 작게 만들어라"라는 원칙은 누구나 알고 있지만 실제로 지키기가 쉽지 않습니다. 큰 기능을 구현하다 보면 인증 레이어, API 엔드포인트, 프론트엔드 화면이 서로 물려 있어서 하나만 떼어내기 어렵거든요. 억지로 쪼개봤자 의존하는 브랜치끼리 rebase를 수동으로 맞추느라 시간을 허비하게 됩니다. 이 문제를 해결하기
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은 정말 강력한 도구이지만 명령어가 너무 많고 옵션도 복잡해서 막상 터미널에서 쓰려면 머리가 아플 때가 있습니다. git log --oneline --graph --all을 외우고 있는 사람이 몇이나 될까요? 😅 그렇다고 GUI 클라이언트를 쓰자니 무겁고, 터미널 작업 흐름이 끊기는 게 싫은 분들도 계실 겁니다. 이런 고민을 단번에 해결해주는 도구가 바로 Lazygit인데요. 터미널 안에서 동작하는 Git TUI(Text User Interface)로, 키보드 몇 번이면 스테이징부터 커밋, 브랜치 관리, 인터랙티브 리베이스까
GitHub에서 코드를 받아오거나 올려보고 싶은데 어디서부터 시작해야 할지 막막하신가요? Git이라는 도구를 깔아야 한다는 건 알겠는데, 설치 후에 뭘 해야 하는지 모르겠다는 분들이 꽤 많습니다. 이 글에서는 Git을 처음 사용하는 분들을 위해 설치부터 GitHub 원격 저장소와 연동하는 것까지 한 번에 정리해보겠습니다. 터미널 명령어가 낯설더라도 하나씩 따라 하다 보면 금방 익숙해질 거예요. Git 설치하기 Git을 사용하려면 먼저 컴퓨터에 설치가 되어 있어야 합니다. 혹시 이미 설치되어 있는지 확인부터 해볼까요? 이렇게 버전 정
Git을 쓰다 보면 "이 파일은 추적하지 마!" 하고 싶을 때가 참 많습니다. .env 파일에 담긴 비밀 키, node_modules처럼 덩치 큰 의존성 폴더, IDE가 만들어내는 .idea나 .vscode 디렉토리까지. 대부분은 .gitignore에 한 줄 추가하면 끝이지만 실제로는 그것만으로 해결되지 않는 상황이 꽤 있습니다. "팀 전체가 아니라 나만 무시하고 싶은 파일이 있는데?", "이미 커밋된 파일인데 이제 와서 무시하려면?", "설정 파일을 로컬에서만 살짝 바꿔 쓰고 싶은데?" 이번 글에서는 Git에서 파일 추적을 막는
이번 포스팅에서는 .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으로 작업하다 보면 브랜치(branch)를 다룰 일이 정말 많죠. git branch 명령어를 사용하면 브랜치를 만들고 목록을 확인하고 이름을 바꾸거나 삭제할 수 있는데요. 이번 글에서는 git branch 명령어의 기본 사용법부터 실전 활용법까지 함께 살펴보겠습니다. 브랜치란? Git에서 브랜치는 특정 커밋을 가리키는 가벼운 포인터입니다. 새 커밋을 만들 때마다 현재 브랜치의 포인터가 자동으로 최신 커밋으로 이동하죠. 보통 Git 저장소를 처음 만들면 main(또는 master)이라는 기본 브랜치가 생성됩니다. 여기서 새로운
팀 프로젝트를 하다 보면 동료가 올린 코드를 내 로컬에 반영해야 하는 상황이 자주 생기는데요. 이때 사용하는 명령어가 바로 git pull입니다. git pull은 원격 저장소(remote repository)의 최신 변경분을 가져와서 현재 브랜치에 합치는 과정을 한 번에 처리해줍니다. git fetch + git merge git pull은 사실 두 가지 명령어를 연달아 실행하는 것과 같습니다. 먼저 git fetch로 원격 저장소의 변경 내용을 로컬로 가져오고, 그 다음 git merge로 현재 브랜치에 합칩니다. 이 두 단계를
git fetch는 원격 저장소(remote repository)의 최신 변경분을 로컬로 가져오되, 현재 작업 중인 코드에는 영향을 주지 않는 명령어입니다. git pull과 혼동하기 쉬운데, git pull이 가져오기와 합치기를 한번에 하는 반면, git fetch는 가져오기만 하고 합치는 건 개발자에게 맡깁니다. git fetch vs. git pull 이 둘의 관계를 코드로 표현하면 다음과 같습니다. git fetch는 원격 저장소의 변경 내용을 origin/main 같은 원격 추적 브랜치(remote-tracking bran
git push는 원격 저장소(remote repository)에 코드 변경분을 업로드하기 위해서 사용하는 Git 명령어 입니다. git commit vs. git push git commit 명령어는 로컬 저장소(local repository)에 코드 변경 이력을 남기기 위해서 사용됩니다. 여기서 로컬 저장소란 git clone 명령어를 통해서 내 컴퓨터에 복제해둔 원격 저장소의 복사본을 의미합니다. 따라서, git commit를 통해 로컬 저장소에 아무리 많은 코드 변경 이력을 남기더라도 원격 저장소에서는 알 길이 없습니다. 반
Git은 분산 버전 관리 시스템이라서 하나의 프로젝트에 여러 원격 저장소(remote repository)를 연결할 수 있습니다. git remote 명령어는 이런 원격 저장소들을 관리하는 데 사용하는데요. 원격 저장소를 추가하거나, 연결 상태를 확인하거나, 더 이상 필요 없는 원격을 삭제할 때 모두 이 명령어를 씁니다. 원격 저장소 목록 확인 가장 기본적인 사용법은 현재 등록된 원격 저장소의 이름을 확인하는 것입니다. git clone으로 저장소를 복제하면 기본적으로 origin이라는 이름으로 원격 저장소가 자동 등록됩니다. -v