시작은 가볍게 마무리는 묵직하게

브랜치란? 기존 작업 환경으로부터 독립된 곳에서 어떤 작업을 진행하기 위한 환경이라고 할 수 있다. 그럼 이 브랜치가 왜 탄생되었을까? 상황을 예시로 들어보자! 팀에서 개발을 하게 되면 같은 소스코드를 공유하는 메인 소스코드가 있다. 이때 각 개발자들마다 개발하는 부분이 다르고 또 어떤 개발자는 기존의 소스코드에서 버그를 고치는 경우도 있을 수 있다. 그렇기 때문에 각 개발자들이 개발한 코드를 서로 공유하는 소스코드에 커밋함으로써 기존의 메인 소스코드에 영향을 끼친다. 이로 인해 다양한 문제가 발생할 수 있기에 여러 개발자가 각자 독립된 브랜치에서 소스코드를 작성하고 커밋해도 특정 액션을 취하지 않는 이상 바로 메인 소스코드의 버전에 영향을 주지 않기 때문에 브랜치라는 환경이 탄생하게 되지 않았나 생각한..

버전 삭제 특정 과거의 버전으로 돌아가고 그 이후의 버전을 지우고 싶을 경우 돌아가고자 하는 버전의 커밋 일련번호 앞 7자리를 복사하고 다음과 같이 터미널에 입력한다. git reset --hard 커밋 일련번호 앞 7자리 해당 버전으로 reset하겠다는 말은 해당 버전과 그 이후의 것들을 삭제하겠다는 것이 아니라 해당 버전으로 돌아가고 그 이후의 버전을 삭제하겠다는 것을 의미한다. 이러한 방법으로 삭제한 버전으로 돌아갈 수 없기 때문에 신중히 선택해야 한다. 버전 되돌리기 이미 commit한 상태에서 해당 commit을 취소하고 commit 이전 상태로 되돌리고 싶은 경우 다음과 같이 다양하게 되돌리는 방법이 있다. git reset --soft HEAD^ git commit하기 직전의 상태로 되돌리는..

git init 프로젝트 최상단 위치에 .git이라는 local repository(지역 저장소)를 추가하는 작업과 동시에 .git이 추가된 위치를 조회할 수 있다. 프로젝트마다 프로젝트 고유의 git을 이용할 때에는 프로젝트 최상단 위치에 git init을 가장 먼저 입력해야 한다. 주의 : .git을 삭제하게 되면 지금까지의 깃 히스토리가 날라가게 되니 주의하자! 작업 단계 Working tree : 아직 버전으로 만들어지기 전에 특정 파일을 수정 중이거나 수정한 파일들이 있는 장소를 의미한다. index : 수정한 파일들을 하나의 버전으로 만들기 위해 등록된 파일의 장소를 의미한다. git status 새로운 버전으로 만들고자 하는 파일 중 수정된 파일이 있는지 확인하는 것이다. 만약 없을 경우 다..

필자는 팀 프로젝트에서 채팅서비스를 도입하여 온라인에서 사용자끼리 상품 거래를 할 수 있도록 클라이언트에서 공부해야 할 기술 스택을 찾고 있다가 sockJS를 알게 되었다. 그리고 다음과 같은 이유로 sockJS를 프로젝트에서 사용하기로 하였다. sockJS websocket과 비슷한 기능을 제공하는 브라우저 javascript 라이브러리다. 그렇다면 그냥 websocket에서 제공하는 기능을 사용하면 되는데 굳이 sockJS를 도입하기로 결심을 한 것일까? 직접 sockJS의 깃헙 주소로 들어간 결과 해당 라이브러리 summary 부분에서 장점을 친절하게 설명하고 있었다. 브라우저와 웹 서버 사이에서 짧은 지연시간, 그리고 크로스 브라우징을 지원하는 API라는 것이다. 이것을 통해 필자가 애용하는 크롬..

웹팩을 실행하여 여러 모듈을 하나의 번들링 파일로 만들 때 자바스크립트에서 에러가 발생하면 브라우저의 콘솔에는 번들링된 하나의 파일 첫째줄에서 에러가 떴다고 알려주기 때문에 어떤 모듈의 몇 번째 줄에서 에러가 떴는지 정확히 알기 쉽지 않다. 쉽게 에러를 트래킹하기 위해 웹팩에서는 source map이라는 모듈을 사용한다. 이것은 에러가 발생하거나 디버깅할 때 번들링하기 전의 파일인 원래 소스 코드로 맵핑해주는 기능을 제공한다. 해당 기능은 다양한 옵션이 있으며 개발모드와 배포모드마다 옵션을 달리해야 적절한 기능을 사용할 수 있다. devtool이라는 key에 source map의 옵션을 적는데 source map의 옵션은 너무나도 많다. devtool을 설정하지 않거나 옵션을 적지 않았을 경우 빌드와 재..

번들링 파일이 포함하고 있는 모듈 시각화하기 지금까지 번들링한 파일들이 어떠한 모듈을 포함하고 있는지 시각적으로 확인한 적이 없으며 확인할 필요가 있다. 왜냐하면 중복된 라이브러리를 각 모듈이 포함하고 있으면 이것은 웹팩 성능 저하를 초래할 수 있기 때문이다. 또한 그와 동시에 번들링한 파일의 크기도 알고 싶을 수도 있다. 이러한 역할을 해주는 플러그인이 바로 webpack-bundle-analyzer이다. 이 플러그인은 웹팩을 실행하거나 npm명령을 입력하면 현재 프로젝트의 번들링 파일이 어떠한 모듈을 포함하고 있고 크기는 얼마인지 번들링 파일별로 확인할 수 있다. 이 플러그인은 다음과 같이 설치한다. npm install --save-dev webpack-bundle-analyzer 또한 설치 후 웹..