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
macOS에서 개발 환경을 처음 셋업할 때 가장 먼저 하는 일이 뭘까요? 대부분의 개발자가 Homebrew부터 설치할 거예요. Git, Node.js, Python, Docker CLI 같은 개발 도구를 터미널 명령어 하나로 설치하고 관리할 수 있게 해주는 도구이기 때문인데요. 한번 쓰기 시작하면 없이는 못 살게 되는 도구죠. 이번 글에서는 2026년 9월에 나온 Homebrew 7을 기준으로 설치부터 Cask, Tap, Bundle, 그리고 새로 들어온 취약점 점검과 GUI 앱까지 하나씩 살펴보겠습니다. Homebrew란? Hom
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 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 옵션을 사용하면 각 컨테이너의 디스크 사용