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으로 작업하다 보면 "이 커밋에서 뭘 변경했더라?" 하고 궁금해지는 순간이 많습니다. git log로 커밋 목록은 볼 수 있지만 각 커밋의 실제 변경 내용까지 바로 확인하기는 어렵죠. 바로 이럴 때 git show가 유용합니다. git show는 커밋의 메타 정보와 변경 내용을 한 번에 보여주는 명령어인데요. 커밋뿐만 아니라 태그나 브랜치, 특정 파일까지 다양한 Git 객체의 내용을 살펴볼 수 있습니다. 이번 글에서는 git show의 기본 사용법부터 실전에서 유용한 팁까지 함께 알아보겠습니다. 기본 사용법 git show를
Git으로 프로젝트를 진행하다 보면 "지난주에 이 파일 누가 수정했지?" "이 기능은 언제 추가된 거야?" 같은 궁금증이 생기기 마련입니다. 이럴 때 커밋 히스토리를 살펴볼 수 있는 git log 명령어가 유용한데요. git log는 저장소의 커밋 기록을 시간 역순으로 보여주는 명령어입니다. 단순히 커밋 목록만 나열하는 게 아니라 옵션을 조합하면 원하는 정보만 골라서 볼 수 있어서 코드 리뷰나 디버깅, 릴리스 관리 등 여러 상황에서 두루 쓰이죠. 이번 글에서는 git log의 기본 사용법부터 실전에서 유용한 옵션까지 함께 알아보겠습
Git의 pre-commit 훅(hook)은 우리가 작성한 코드를 커밋할 때 마다 자동으로 특정 작업을 실행해줍니다. 많은 프로젝트들이 이를 통해 포맷터(formatter)를 실행하여 코드 스타일을 통일하고, 린터(linter)를 실행하여 코드에 잠재하고 있는 문제들을 찾아냅니다. 이번 포스팅에서는 Git의 pre-commit hook을 편리하게 사용할 수 있도록 도와주는 pre-commit라는 도구에 대해서 알아보겠습니다. 설치 pre-commit은 자신의 컴퓨터에 파이썬이 설치가 되어 있다면 파이썬의 패키지 매니저인 pip를 사
코드를 수정하다 보면 "내가 방금 뭘 바꿨더라?" 하는 순간이 자주 찾아옵니다. 여러 파일을 동시에 고치고 있으면 어디를 얼마나 바꿨는지 감을 잃기 쉽죠. git diff는 변경 내용을 한눈에 확인할 수 있게 해주는 명령어인데요. 작업 디렉토리, 스테이징 영역, 커밋 사이의 차이를 비교해주기 때문에 커밋 전에 변경 내용을 점검하거나 브랜치 간 차이를 파악할 때 쓸 일이 많습니다. 이번 글에서는 git diff의 기본 사용법부터 실전에서 유용한 옵션까지 함께 알아보겠습니다. 기본 사용법 git diff를 인자 없이 실행하면 작업 디렉
git commit은 Git에서 가장 핵심적인 명령어라고 할 수 있습니다. 스테이징 영역(staging area)에 올려놓은 변경 내용을 하나의 변경 이력으로 저장소에 기록할 때 사용하는데요. 프로젝트 개발 과정에서 의미 있는 단위로 작업을 나누어 기록해두면, 나중에 특정 시점으로 돌아가거나 다른 사람이 코드 변경 이력을 이해하기 훨씬 수월해집니다. git add와 git commit git commit 명령어를 사용하기 전에 반드시 git add로 스테이징 영역에 변경 내용을 올려놔야 합니다. Git은 작업 디렉토리의 모든 변경
Git으로 작업하다 보면 "지금 어떤 파일을 수정했더라?", "스테이징에 뭘 올려놨지?" 같은 순간이 자주 옵니다. git status는 바로 이런 질문에 답해주는 명령어인데요. 현재 작업 디렉토리와 스테이징 영역의 상태를 한눈에 보여줘서, 다음에 뭘 해야 할지 파악하는 데 큰 도움이 됩니다. 기본 사용법 사용법은 정말 간단합니다. 그냥 git status를 입력하면 됩니다. 이 출력을 세 구역으로 나눠서 살펴보겠습니다. 출력 내용 읽기 Changes to be committed 구역은 git add로 스테이징 영역에 올라간 파일들
git add는 작업 디렉토리(working directory) 상의 변경 내용을 스테이징 영역(staging area)에 추가하기 위해서 사용하는 Git 명령어입니다. git commit vs. git add git add 명령어는 다음 변경(commit)을 기록할 때까지 변경분을 모아놓기 위해서 사용합니다. 따라서, git commit 명령어를 통해 명시적으로 기록을 남기기 전까지는 아무리 git add 명령어를 많이 실행해도 Git 저장소의 변경 이력에는 어떤 영향도 주지 않습니다. git status git add 명령어를
새로운 프로젝트에 투입되거나 오픈소스에 기여하려면 먼저 원격 저장소의 코드를 내 컴퓨터에 가져와야 합니다. 이때 사용하는 명령어가 바로 git clone인데요. 원격 저장소의 모든 파일과 변경 이력을 통째로 복제해서 로컬에 동일한 저장소를 만들어줍니다. git init vs. git clone git init은 빈 Git 저장소를 새로 생성하는 명령어이고, git clone은 이미 존재하는 원격 저장소를 복사해오는 명령어입니다. 새 프로젝트를 처음부터 시작할 때는 git init을, 이미 존재하는 프로젝트에 참여할 때는 git cl
이번 포스팅에서는 Git 설정을 위해 사용하는 git config 명령어에 대해서 알아보겠습니다. 설정 범위와 설정 파일 git config 명령어에 대해서 배우기 전에 먼저 간단하게 설정 범위에 대해서 짚고 넘어가겠습니다. Git은 지역(local), 전역(global), 시스템(system) 이렇게 크게 3가지 범위로 설정이 가능한데요. 지역 범위로 설정하면 특정 저장소(repository)로 한정되고, 전역 범위는 현재 사용자(user)의 모든 저장소를 포함시킵니다. 자주 사용되지는 않지만 시스템 범위로 설정하면 해당 컴퓨터의
git init는 새로운 Git 저장소(repository)를 생성할 때 사용하는 Git 명령어 입니다. Git 사용할 때 보통 다른 사람이 이미 생성해 놓은 Git 원격 저장소를 git clone 명령어를 통해 내려받는 경우가 많고, 직접 Git 저장소를 생성하더라도 프로젝트 초기에 딱 한 번만 사용하기 때문에 생소하게 느껴질 수도 있는 명령어입니다. 하지만 저처럼 모든 개인 프로젝트를 항상 Git으로 버전 관리를 하는 분들에게는 의외로 자주 사용하게 되는 명령어 입니다. 실습 디렉토리 준비 일단 Git으로 버전 관리를 하고 싶은
코드 스타일 파이썬과 같이 사용차층이 넓은 범용 프로그래밍 언어의 경우, 개발자들이 선호하는 코드 스타일이 다양해지게 됩니다. 개인 프로젝트에서는 자신이 선호에 따라 어떤 방식으로 코드를 포맷팅하든지 코드가 돌아가기면 하면 큰 상관이 없지만, 협업 프로젝트에서는 이러한 개발자 간의 사소한 코드 스타일 차이로 불필요한 감정 싸움이 발생하기도 합니다. 예를 들어, 똑같은 문자열을 표현하기 위해서 개발자 A는 홑따옴표를 사용하고 싶은데, 개발자 B는 쌍따옴표를 사용하고 싶습니다. 만약에 개발자 A가 작성한 코드를 나중에 개발자 B가 수정