git switch는 브랜치를 전환하기 위해서 사용하는 Git 명령어입니다. Git 2.23 버전(2019년 8월)에서 처음 도입되었으며, 기존 git checkout 명령어의 브랜치 전환 기능을 좀 더 명확하고 안전하게 사용할 수 있도록 설계되었습니다. 레거시 명령어인 git checkout에 대해서는 별도 포스팅에서 다루고 있으니 참고 바랍니다. 브랜치 전환 가장 기본적인 사용법은 이미 존재하는 브랜치로 전환하는 것입니다. 예를 들어, main 브랜치로 전환하려면 다음과 같이 입력합니다. feature/user-auth라는 이름
Git은 분산 버전 관리 시스템이라서 하나의 프로젝트에 여러 원격 저장소(remote repository)를 연결할 수 있습니다. git remote 명령어는 이런 원격 저장소들을 관리하는 데 사용하는데요. 원격 저장소를 추가하거나, 연결 상태를 확인하거나, 더 이상 필요 없는 원격을 삭제할 때 모두 이 명령어를 씁니다. 원격 저장소 목록 확인 가장 기본적인 사용법은 현재 등록된 원격 저장소의 이름을 확인하는 것입니다. git clone으로 저장소를 복제하면 기본적으로 origin이라는 이름으로 원격 저장소가 자동 등록됩니다. -v
Git으로 작업하다 보면 브랜치(branch)를 다룰 일이 정말 많죠. git branch 명령어를 사용하면 브랜치를 만들고 목록을 확인하고 이름을 바꾸거나 삭제할 수 있는데요. 이번 글에서는 git branch 명령어의 기본 사용법부터 실전 활용법까지 함께 살펴보겠습니다. 브랜치란? Git에서 브랜치는 특정 커밋을 가리키는 가벼운 포인터입니다. 새 커밋을 만들 때마다 현재 브랜치의 포인터가 자동으로 최신 커밋으로 이동하죠. 보통 Git 저장소를 처음 만들면 main(또는 master)이라는 기본 브랜치가 생성됩니다. 여기서 새로운
git push는 원격 저장소(remote repository)에 코드 변경분을 업로드하기 위해서 사용하는 Git 명령어 입니다. git commit vs. git push git commit 명령어는 로컬 저장소(local repository)에 코드 변경 이력을 남기기 위해서 사용됩니다. 여기서 로컬 저장소란 git clone 명령어를 통해서 내 컴퓨터에 복제해둔 원격 저장소의 복사본을 의미합니다. 따라서, git commit를 통해 로컬 저장소에 아무리 많은 코드 변경 이력을 남기더라도 원격 저장소에서는 알 길이 없습니다. 반
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
자바스크립트 프로젝트의 규모가 커지면 디렉토리 구조도 복잡해지기 마련입니다. 혹시 다음과 같은 코드 때문에 해당 모듈을 찾으려고 상위 디렉토리를 하나씩 짚어가며 올라가다가 스트레스 받으신 적이 있으신가요? 😝 상대 경로 Node.js에서 내부 모듈을 불러올 때 가장 흔히 사용되는 방법은 상대 경로를 사용하는 것입니다. 위에서 보시는 것 처럼 상대 경로를 사용해서 모듈을 불러오면 모듈이 어느 경로에 위치하는지 파악하기가 난해해지는 경우가 생깁니다. 뿐만 아니라, 이 자바스크립트 파일을 다른 디렉토리로 옮기려면 상대 경로를 그에 따라
ES6(ES2105) 이상의 최신 자바스크립트 문법으로 작성된 코드가 노드JS(Node.js)에서 실행이 안 되서 애를 먹는 경우가 종종 있는데요. 이번 포스팅에서는 자바스크립트 트랜스파일러(Transpiler)인 Babel을 이용하여 이 문제를 깔끔하게 해결해보겠습니다. 개발자들이 실행 환경에 구애받지 않고 항상 최신 문법의 자바스크립트로 코딩할 수 있도록 도와주는 유용한 도구인 바벨(Babel)에 대해서는 별도 포스팅을 참고바랍니다. Node.js에서 ES6 코드 실행 오류 먼저 간단한 예제 프로젝트를 하나를 만들겠습니다. js
Docker Compose는 여러 개의 컨테이너(container)로 구성된 애플리케이션을 관리하기 위한 간단한 오케스트레이션(Orchestration) 도구입니다. 이번 포스팅에서는 Compose 애플리케이션을 터미널에서 제어하기 위해 사용되는 Docker Compose 커맨드에서 대해서 알아보겠습니다. -f 옵션 Docker Compose는 기본적으로 커맨드가 실행하는 디렉토리에 있는 docker-compose.yml 또는 docker-compose.yaml를 설정 파일로 사용합니다. 다른 이름이나 경로의 파일을 Docker C
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)에 해당하는 이미지만 필터링해서 보고 싶을 때는, 리파지토리를 인자로 넘겨주면 됩니다. 태그까지 인자로
이전 포스팅에서 AWS CLI의 aws s3 커맨드를 사용하는 방법에 대해서 살펴보았습니다. 이번 포스팅에서는 aws s3api 커맨드를 통해서 Amazon S3를 좀 더 세밀하게 제어하는 방법에대해서 알아보도록 하겠습니다. S3 버킷의 Region 확인 종종 본인이 생성한 S3 버킷이 속한 Region이 어디인지 햇갈릴 때가 있습니다. 이럴 때는 aws s3api get-bucket-location 커맨드를 통해서 Region을 알아낼 수 있습니다. S3 버킷의 Life Cycle 설정 Amazon S3에 저장되어 있는 파일들의
Amazon S3는 AWS에서 제공하는 클라우드 스토리지 서비스입니다. AWS CLI를 이용하면 간편하게 S3 버킷을 제어하고 S3 오브젝트에 접근할 수 있으며, Unix의 파일 시스템 커맨드와 매우 유사해서 배우기도 쉽습니다. 이 번 포스팅에서는 자주 사용되는 AWS CLI의 Amazon S3 관련 커맨드을 살펴보도록 하겠습니다. 버킷 생성하기 Amazon S3에 데이터를 저장하려면 먼저 버킷(Bucket)을 생성해야 합니다. 버킷은 Amazon S3에서 파일 시스템의 최상위 디렉터리나 드라이브 정도의 역할을 하는 저장 단위 개념
DynamoDB는 AWS에서 제공하는 관리형 NoSQL 데이터베이스 서비스입니다. AWS CLI를 이용하면 간편하게 DynamoDB 테이블을 제어하고 테이터에 접근할 수 있습니다. 이 번 포스팅에서는 자주 사용되는 AWS CLI의 DynamoDB 관련 커맨드을 살펴보도록 하겠습니다. 테이블 생성하기 아직 본인 AWS 계정에 DynamoDB 테이블이 없으신 분들은 일단 테이블부터 생성하셔야 합니다. 예제로 과일 정보를 저장하기 위해서 Fruits 테이블을 생성해보겠습니다. aws dynamodb create-table 커맨드를 사용하
AWS(Amazon Web Services)에 접근하기 위해서는 필수적으로 인증 절차가 필요합니다. 웹 브라우저에서 AWS Management Console을 통해 접근하든지, 터미널에서 AWS CLI를 사용하여 접근하든지, 애플리케이션이 AWS SDK를 통해 접근하든지 절대 예외는 없지요. 이번 포스팅에서는 AWS의 인증 정보(Access Key ID, Secret Access Key)에 대한 기본 개념을 잡고, AWS CLI를 통해서 간단하게 AWS 인증 정보를 설정하고 프로파일로 관리하는 방법에 대해서 함께 실습을 해보겠습니다