200902_TIL

oh_ji_0·2020년 9월 2일

목록 보기

26/61

Today I learned

nvm

npm

eslint

sprint review (git, arrow function, bind)

@@ 오늘은 페어와 HA assessments를 진행하며, 지난 번 풀었던 7가지 문제를 놓고 리팩토링을 고민하고 eslint를 설치해 반영해보는 시간을 가졌다.

페어분과 번갈아 네비게이터, 드라이버를 하며 우리가 각자 풀었던 코드에서 최신 자바스크립트 문법으로의 변형을 고민해봤다. 스프린트 문제가 살짝 달라지기도 했고, 자주 써보지 못했던 arrow function, 구조 분해 할당, rest/ spread 문법, for..of 문 등을 쓰려니 뭔가 어색하기도 했다. 또 이미 작성한 코드를 보다 더 간결하게 바꾸려니 선뜻 손을 못대겠더라. 물론 완벽한 코드는 아니라는 생각이 들지만, 그 방법밖에 생각나지 않아서 HA에서 그렇게 풀었던거였으니 말이다.

그래도 페어분과 이야기 하며 차근차근 풀어가다보니 시간은 생각보다 많이 할애되지 않았고, 예정 시간보다 일찍 끝났다. 일찍 끝난 김에 어제 배운 git 복습 겸 깃 브랜칭을 배우는 시간을 잠깐 가졌는데 아직은 페어 프로젝트에선 git merge 정도까지 밖에 해보지 못했었는데 게임하듯이 reset, revert, rebase, cherry-pick, interactive rebase 까지 다양하게 배워볼 수 있어서 재미있었다.

오늘은 뭔가 전체적으로 기운이 많이 떨어지는 하루였는데, 그래도 자리를 지키려고 노력하면서 하루를 잘 보낸 것 같다. nvm, npm 등도 이제 점점 배워나가며, eslint 설치 등도 오늘 진행해봤는데 웃긴 게 부트캠프 합류 전에 독학할 때 읽었을 땐 마냥 어렵기만 했는데 그 사이에 내가 성장을 한걸까. 아니면, 누군가 나를 도와줄 사람들이 있다는 영향일까. 어렵게만 느껴졌던 공식문서도 사실 조금은 친근하게 느껴지고, 처음 이걸 접했을 땐 왜 이렇게 어렵기만 했을까 문득 그런 생각이 들었다.

내일 대망의 자료구조가 시작되는데.. 어렵다는 말도 많이 들었고, 중요하다는 얘기도 너무 많이 들어서 긴장되고 두근두근 하다. 그치만 위에 느꼈듯, 마음이 중요한 것이니 또 차분하게 열린 마음으로 진행해 나가야겠다.

nvm

node version manager
다른 버전을 설치해서 쓰고 싶은 버전 별로 사용하는 것이 가능하다.
nvm use <node version>

nvm 설치

$ touch ~/.bash_profile 
$ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.35.3/install.sh | bash

node.js 설치
nvm install <version>
설치 확인
node -v

npm

node package manager
package.json
dependencies
npm install --save <package name>
devDependencies
npm install --save-dev <package name>
npx eslint
npm ls --depth=0
npm ls -g --depth=0
npm uninstall -g eslint

ESlint

linter
문법 체크, 문제를 찾고, 코드 스타일을 강제할 수 있는 도구
설치
npm install eslint --save-dev
설정파일 추가
npx eslint --init
mocha 환경 설정
eslintrc.json 파일에서 env 프로퍼티에 전역적으로 mocha 환경임을 명시할 수도 있고, 개별 파일에서 주석 처리로 mocha 환경임을 알려줄 수 있다.
/* eslint-env node, mocha */
rules 프로퍼티 값에 각각의 오류에 대한 개별 설정 값을 정해줄 수 있다.

Sprint review

git workflow

git remote -v
git remote
git remote add pair <pair 깃허브 레포지토리 url>
git pull <리모트레포지토리 name> <리모트 레포지토리 브랜치이름>
git push origin master

git merge

합치려는 곳에서 체크아웃한 뒤, 합치려는 브랜치 대상으로 merge 진행

git merge < Branch name >

git rebase

브랜치 끼리의 작업을 접목하는 방법
기본적으로 커밋들을 모아서 복사한 뒤, 다른 곳에 떨궈 놓는 것
커밋들의 흐름을 보기 좋게 한줄로 만들 수 있다.

git rebase master

git에서 여기저기로 옮겨다니기

프로젝트를 표현하는 커밋 트리에서 이동할 수 있는 여러가지 방법들을 아는 것이 중요하다.
HEAD 는 현재 체크아웃된 커밋을 가리킨다. 항상 가장 최근 커밋을 가리킨다
c1(커밋의 해시값) 커밋을 체크아웃 하면 HEAD를 확인할 수 있다.
HEAD를 분리한다는 것은 HEAD를 브랜치 대신 커밋에 붙이는 것을 의미한다.

git checkout c1

상대참조

git 의 커밋 해시값은 상대적으로 간단하지 않고, 매번 확인해서 참조하기 어렵다.
해시값을 정확히 치지 않더라도 조회할순 있지만 이 방법 또한 편하지 않다.
상대 참조는 이럴 때 사용한다.
한번에 한 커밋 위로 움직이는 ^
한번에 여러 커밋 위로 올라가는 ~<num>
git checkout HEAD^로 HEAD를 기준으로 상대참조를 진행할 수도 있다.
~ 연산자

상대 참조로 여러개 올라가고 싶을때

git checkout HEAD~4
상대참조를 사용하는 가장 일반적인 방법은 브랜치를 옮길 때마다 -f 옵션을 이용해서 브랜치를 특정 커밋에 직접적으로 재지정할 수 있다.

git branch -f master HEAD~3
(마스터 브랜치를 HEAD 에서 세번 뒤로 옮김)

git 작업 되돌리기

git reset
- 히스토리를 고쳐쓴다.
- 애초에 커밋하지 않은 것처럼 예전 커밋으로 브랜치를 옮기는 것
  git reset HEAD~1
- 로컬 브랜치 경우엔 reset을 잘 사용 가능하다. 리모트에선 쓸 수 없다.
git revert
- 변경분을 되돌리고 이 되돌린 내용을 다른 사람들과 공유하기 위해선 git revert를 써야한다.
- git revert HEAD

git cherry-pick

현재 위치 HEAD 아래에있는 일련의 커밋들에 대한 복사본을 만들겠다는 것을 간단히 줄인 말. git cherry-pick <Commit1> <Commit2> <...>
현재 위치 HEAD가 위치했던 c5커밋에서 체리픽 다음에 써잇는 c2 c4를 차례로 복사했다.

git 인터랙티브 리베이스

원하는 커밋을 모르는 상황에서는 인터랙티브 리베이스를 사용한다.
리베이스할 일련의 커밋들을 검토할 수 있는 가장 좋은 방법이다.
리베이스 명령어를 사용할 때 -i 옵션을 같이 사용한다.
이 옵션을 추가하면 깃은 리베이스 목적지가 되는 곳 아래에 복사될 커밋들을 보여주는 ui 를 띄운다. 각 커밋을 구분할 수 있는 각각의 해시들과 메시지도 보여준다.
실제 깃에서는 ui 창을 띄우는 것 대신 vim 같은 텍스트 편집기에서 파일을 연다.
적용할 커밋 들의 순서를 ui 를 통해 바꿀 수 있다.
원하지 않는 커밋들을 뺄 수 있다. (pick을 통해 지정)
커밋을 스쿼시 할 수 있다. (커밋을 합치는 것)
undo와 reset을 통해 실수했던 내용을 되돌릴 수 있다.

git rebase -i <기준 커밋 혹은 브랜치>

커밋 메시지 수정

정정할 커밋이 바로 직전에 있으면 간단히 —amend로 수정할 수 있다.
git commit -ammend

200901_TIL

다음 포스트