자바스크립트 프로젝트에서 개발을 하다보면 터미널을 열고 명령어를 실행해야하는 경우가 빈번하게 생기는데요. 대표적인 예로 로컬 환경에서 애플리케이션을 빌드하고 구동하거나 테스트를 실행하는 것을 들 수 있습니다. 이번 포스팅에서는 자바스크립트 프로젝트에서 자주 사용되는 명령어를 스크립트로 등록하고 실행하는 방법에 대해서 알아보겠습니다. 반복 명령은 스크립트로 자바스크립트 프로젝트에서 개발을 진행하다보면 테스트나 빌드(build), 린트(lint), 포맷(format)처럼 반복적으로 수행해야하는 작업들이 생기기 마련입니다. 각 작업은 일
이번 포스팅에서는 React 프로젝트를 쉽고 빠르게 만들 수 있도록 도와주는 Create React App에 대해서 알아보겠습니다. Create React App React로 개발 프로젝트를 맨땅에서 시작하려면 웹팩(Webpack), 바벨(Babel) 등 정말 미리 배워야하는 기술들이 한 두개가 아닙니다. 초보 개발자들이 이러한 선수 기술들을 일일이 학습하다보면 본래 목표했던 React 애플리케이션 개발이 아득하게 멀어지기 일수인데요... React는 각종 개발 편의 도구가 함께 포함된 프레임워크(framework)라기 보다는 어느
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 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)이라는 기본 브랜치가 생성됩니다. 여기서 새로운
이번 포스팅에서는 터미널에서 간단한 명령어를 입력하여 웹 페이지나 API 데이터를 요청하고 받을 수 있는 HTTP 클라이언트 도구인 curl 커맨드에 대해서 알아보겠습니다. curl 커맨드 1998년에 만들어진 curl 커맨드는 Postman이나 Insomnia와 같이 다양한 기능과 화려한 UI를 제공하는 GUI 기반 HTTP 클라이언트가 계속해서 출시되는 와중에도 아직까지 꾸준히 사랑받고 있는 CLI 도구입니다. curl 커맨드는 리눅스나 macOS에 대부분의 경우 기본으로 탑재되어 있으며, 몇 가지 주요 옵션만 숙지하면 매우 간
팀 프로젝트를 하다 보면 동료가 올린 코드를 내 로컬에 반영해야 하는 상황이 자주 생기는데요. 이때 사용하는 명령어가 바로 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
macOS에서 개발 환경을 처음 셋업할 때 가장 먼저 하는 일이 뭘까요? 대부분의 개발자가 Homebrew부터 설치할 거예요. Git, Node.js, Python, Docker CLI 같은 개발 도구를 터미널 명령어 하나로 설치하고 관리할 수 있게 해주는 도구이기 때문인데요. 한번 쓰기 시작하면 없이는 못 살게 되는 도구죠. 이번 글에서는 Homebrew 설치부터 Cask, Tap, Bundle까지 하나씩 살펴보겠습니다. Homebrew란? Homebrew는 macOS(와 Linux)용 패키지 매니저입니다. Ubuntu에 apt가
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로 스테이징 영역에 올라간 파일들