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 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)의 모든 저장소를 포함시킵니다. 자주 사용되지는 않지만 시스템 범위로 설정하면 해당 컴퓨터의
자바스크립트 프로젝트의 규모가 커지면 디렉토리 구조도 복잡해지기 마련입니다. 혹시 다음과 같은 코드 때문에 해당 모듈을 찾으려고 상위 디렉토리를 하나씩 짚어가며 올라가다가 스트레스 받으신 적이 있으신가요? 😝 상대 경로 Node.js에서 내부 모듈을 불러올 때 가장 흔히 사용되는 방법은 상대 경로를 사용하는 것입니다. 위에서 보시는 것 처럼 상대 경로를 사용해서 모듈을 불러오면 모듈이 어느 경로에 위치하는지 파악하기가 난해해지는 경우가 생깁니다. 뿐만 아니라, 이 자바스크립트 파일을 다른 디렉토리로 옮기려면 상대 경로를 그에 따라
ES6(ES2105) 이상의 최신 자바스크립트 문법으로 작성된 코드가 노드JS(Node.js)에서 실행이 안 되서 애를 먹는 경우가 종종 있는데요. 이번 포스팅에서는 자바스크립트 트랜스파일러(Transpiler)인 Babel을 이용하여 이 문제를 깔끔하게 해결해보겠습니다. 개발자들이 실행 환경에 구애받지 않고 항상 최신 문법의 자바스크립트로 코딩할 수 있도록 도와주는 유용한 도구인 바벨(Babel)에 대해서는 별도 포스팅을 참고바랍니다. Node.js에서 ES6 코드 실행 오류 먼저 간단한 예제 프로젝트를 하나를 만들겠습니다. js
Docker Compose는 여러 개의 컨테이너(container)로 구성된 애플리케이션을 관리하기 위한 간단한 오케스트레이션(Orchestration) 도구입니다. 이번 포스팅에서는 Compose 애플리케이션을 터미널에서 제어하기 위해 사용되는 Docker Compose 커맨드에 대해서 알아보겠습니다. docker compose와 docker-compose 본격적으로 커맨드를 살펴보기 전에 짚고 넘어갈 부분이 있는데요. 예전에는 파이썬으로 만들어진 별도 실행 파일인 docker-compose(하이픈)를 설치해서 썼지만, 지금은 D
Docker 컨테이너(container)에 쓰여진 데이터는 기본적으로 컨테이너가 삭제될 때 함께 사라지게 됩니다. Docker에서 돌아가는 많은 애플리케이션이 컨테이너의 생명 주기와 관계없이 데이터를 영속적으로 저장을 해야하는데요. 뿐만 아니라 많은 경우 여러 개의 Docker 컨테이너가 하나의 저장 공간을 공유해서 데이터를 읽거나 써야합니다. 이렇게 Docker 컨테이너의 생명 주기와 관계없이 데이터를 영속적으로 저장할 수 있도록 Docker는 두가지 옵션을 제공하는데요. 첫번째는 Docker 볼륨(volume), 두번째는 바인드
Docker 컨테이너(container)는 격리된 환경에서 돌아가기 때문에 기본적으로 다른 컨테이너와의 통신이 불가능합니다. 하지만 여러 개의 컨테이너를 하나의 Docker 네트워크(network)에 연결시키면 서로 통신이 가능해집니다. 이번 포스팅에서는 컨테이너 간 네트워킹이 가능하도록 도와주는 Docker 네트워크에 대해서 알아보도록 하겠습니다. 네트워크 조회 Docker 네트워크의 기본은 내 컴퓨터에서 어떤 네트워크가 생성되어 있는지를 아는 것일 겁니다. docker network ls 커맨드를 사용하면 현재 생성되어 있는 D
Docker CLI 도구는 Docker 컨테이너(container)의 효과적인 관리를 위해서 다양한 커맨드(command)를 제공합니다. 이번 포스팅에서는 자주 쓰이는 커맨드 위주로 어떻게 Docker 컨테이너를 효과적으로 제어할 수 있는지 알아보도록 하겠습니다. 컨테이너 조회 가장 먼저 살펴볼 docker ps 커맨드는 Docker 컨테이너를 조회를 위해 사용되며 기본적으로 실행 중인 컨테이너 목록이 출력됩니다. -a 옵션을 사용하면 현재 중지되어 있는 컨테이너까지 함께 출력됩니다. -s 옵션을 사용하면 각 컨테이너의 디스크 사용
Docker를 사용하면서 가장 자주 접하는 커맨드는 단연 컨테이너를 실행하기 위해서 쓰이는 docker run일 것입니다. docker run 커맨드는 상당히 여러 가지 옵션을 통해 다양한 방식으로 컨테이너를 실행할 수 있도록 해줍니다. 이번 포스팅에서는 이중에서 자주 쓰이는 옵션 위주로 dockr run 커맨드를 어떻게 사용하는지 알아보겠습니다. 기본 포맷 docker run 커맨드의 기본 포맷은 다음과 같습니다. 여기서 이미지 식별자는 필수이며 이미지 ID나 리파지토리(repository):태그(tag)를 사용할 수 있습니다.
Docker CLI 도구는 Docker 이미지(image)의 효과적인 관리를 위해서 다양한 커맨드(command)를 제공합니다. 이번 포스팅에서는 자주 쓰이는 커맨드 위주로 어떻게 Docker 이미지를 제어할 수 있는지 알아보도록 하겠습니다. 이미지 조회 docker images 커맨드는 이미지를 조회할 때 사용됩니다. 인자를 넘기지 않고 이 커맨드를 호출하면 전체 이미지 목록을 출력해줍니다. 특정 리파지토리(repository)에 해당하는 이미지만 필터링해서 보고 싶을 때는, 리파지토리를 인자로 넘겨주면 됩니다. 태그까지 인자로
터미널에서 작업하다 보면 반복적으로 입력하는 명령어가 참 많습니다. git status를 하루에 몇 번이나 치는지, cd ../../../ 같은 긴 경로 이동을 얼마나 자주 하는지 세어 보면 놀라울 정도인데요. 이런 반복 작업을 줄여주는 도구가 바로 Oh My Zsh입니다. Oh My Zsh는 Zsh 쉘의 설정을 관리해주는 오픈 소스 프레임워크입니다. 300개가 넘는 플러그인과 150개 이상의 테마를 제공하고, 커뮤니티가 활발하게 관리하고 있어서 전 세계 개발자가 가장 많이 쓰는 Zsh 프레임워크이기도 합니다. 이 글에서는 Oh M
프로젝트 디렉토리에서 특정 파일을 찾으려고 find . -name '*.ts'를 입력했는데 node_modules 안의 파일까지 끝도 없이 쏟아져 나온 경험, 한 번쯤 있지 않으신가요? 아니면 find 명령어의 옵션이 너무 많아서 매번 검색해보게 되는 분도 계실 거예요. 이럴 때 써볼 만한 도구가 바로 fd입니다. fd는 기존 find 명령어를 대체하기 위해 만들어진 커맨드라인 도구인데요. 직관적인 문법, .gitignore 자동 적용, 병렬 탐색을 통한 빠른 속도가 특징입니다. Rust로 작성되어 있고 ripgrep에서 사용하는
스크립트를 읽다 보면 sed 's/foo/bar/g' 같은 구문이 자주 등장합니다. 뜻은 대충 짐작이 가는데, 정확한 문법이나 다양한 활용법은 막상 모르는 경우가 많죠. CI/CD 파이프라인 설정 파일이나 배포 스크립트에도 단골로 등장하고, 코딩 에이전트가 터미널에서 파일을 수정할 때도 종종 꺼내드는 도구입니다. sed는 Stream Editor의 약자입니다. 파일이나 표준 입력으로 들어오는 텍스트를 줄 단위로 읽어서 변환한 뒤 출력하는 도구예요. 1974년 Bell Labs에서 태어났으니 grep, find와 마찬가지로 반세기가