오늘은 IM 코스의 첫 시작
node 가 무엇인지 + 본격적인 git 을 통한 협업에 대해서 배운 날이다
일단은 임팩트가 있었던 내용인 git 부터 먼저 적어보고
그 다음엔 node 를 적어보려고 한다
GIT PING-PONG : git remote
여태껏 나는 페어프로그래밍을 할 때, 그냥 각자 fork, clone 을 해서, 각자 코드를 띄우고
각자 코드를 zoom 으로 띄워서 피드백을 하고, 그렇게 완료가 되면 각자 제출을 했다
어떻게 보면 말이 협업이지, 각자 책상을 갖다놓고 각자 일하면서 간간히 '잘 되고 계시나요?' 하는
탁구보단 그냥 각자 골프를 치는 그런 상황이었던 것이다
그러나 오늘 배운 것은 조금 달랐다
탁구처럼, 배드민턴처럼 서로 공을 주고받는 식으로
내가 만든 걸 내 git 에 commit & push 하고,
내 페어는 내 git 에 접근해서, 내가 저장한 걸 pull 로 받고
또 자신이 수정을 해서 자신의 git 에 commit & push 하고
나는 페어의 git 에 접근해서 페어가 저장한 걸 pull 로 받는 과정
그리고 상기한 과정의 반복
어떻게 보면 진짜 페어프로그래밍을 시도해 본 것이다
도식으로 그리면, 대충 이런 느낌
일련의 과정을 적어보자면, 다음과 같았다
[ first commit From Inseob ]
//first code
console.log('hello');이런 식으로 내가 먼저 .js 파일을 만들고
그리고 거기에 console.log('hello'); 를 적어준 뒤
'first commit from inseob' 이라는 commit message 를 달고 commit
그리고 그걸 내 git 에 push
그 다음 내 페어분은 내 git 에 remote 를 통해 접근한다
참고) git 에 대한 공식 문서 - remote 저장소(링크, 클릭 시 이동)
git remote add pair github.com/pairGitName적힌 것처럼 git remote add <단축이름> <URL> 을 사용하는 식으로 접근을 하는데
이는 맨 끝의 git repository url 을 단축이름(여기서는 pair 에) 할당하는 명령어의 기능도 포함한다
이렇게 remote 저장소를 추가하면, 우리는 그 저장소에 접근할 수 있고
그 저장소의 변동 사항을 pull (혹은 fetch) 을 통해 받아올 수 있다
git pull github.com/pairGitName master저 git repository 의 주소에 있는, master branch 의 변동사항을 끌어온다는 (pull) 이야기이다
하지만 우리는 아까 pair 라는 단축어 안에 저 github repo URL 을 넣었기 때문에
해당 과정을 조금 더 간단하게 할 수 있다
git pull pair master여기까지가 내가 상대방의 git repo 에 접근하여 pull 로 끌어올 수 있는 방법이었고
거꾸로 동시에 이는 상대방이 내 git repo 에 접근하여 pull 로 끌어올 수 있는 방법이기도 하다
이전에도 몇 번 올렸던 제로초씨의 블로그(링크, 클릭 시 이동)도 이해하는 데 상당히 도움이 될듯 하다
GIT PING-PONG : branch
브랜치, 즉, 나뭇가지
페어 프로그래밍의 과정은 점점 더 발전한다
처음엔 각자 테이블에 앉아서 각자 하고 각자 제출
그 다음엔 하나의 테이블에서 서로서로 핑퐁을 치듯 결과물을 보냈다
그러면 이번엔, 하나의 테이블을 / 셋으로 나누어 / 각자 하나씩 들어가 작업을 하다가 / 다 되면 그 중간에 있는 테이블에 각자의 결과물을 합치는
이런 과정으로 페어프로그래밍을 진행해보는건 어떨까
바로 이 과정에서 필요한게 git 의 branch 개념이다
ㅡ
branch 의 도식
각자 branch 를 만든다 → 어느 지점에서 각자 잘 되었는지를 확인하고, master branch 에다가 merge 를 날린다
그리고 그 branch 는 서로에게 영향을 주지 않는 독립적인 공간이다
마지막으로 branch 를 만들 땐
git checkout -b newBranchName
그리고 branch 로 이동할 땐
git checkout branchWhereIMove
이런 식으로 만들어주면 된다
conflict
여러 명이 모여 “같은 라인의 코드" 를 만지면, 가끔 conflict 가 발생한다
이렇게 구분이 되어서 뜨는데
그냥 별 거 없다
저 중에서 내가 무엇을 고를 것인지 삭제하고, 저장하고, 커밋하고, 푸시하면 된다
끝
이는 GUI 화도 되어 있어서, 위에 나와있는 조그만한 Accept Current Change… 부터 Compare Changes 등의 Button 들을 누르면 된다
그렇게 둘의 conflict 를 위와 같은 방식으로 잡아주고, commit 을 하고, push 를 하게 되면, 최종 commit log 상으로는 이제 여러 명들의 코드 라인이 일단은 다 커밋이 되고 푸시가 되었다는 식으로 커밋이 띄워지게 된다
node.js 와 그 관련 도구들 (npm, nvm)
JS Runtime and node.js
JS Runtime 환경의 일종 중 하나
어떻게 보면 우리의 runtime 은 브라우저 (크롬) 이었다는것
* runtime : 언어가 실행되는 환경
그리고 이번의 node.js 는 브라우저 “밖에서" 돌아가는 runtime 이라는 것
이 포인트이다
다시 말 해, JS 가 탈-브라우저를 할 수 있던 본격적인 계기가 되는 runtime
우리가 html 에서 js 를 돌리고 싶을 때, <script> 태그 안에서 js codeLine 을 넣어주었던 것처럼,
node 에서 돌리고 싶으면, js 파일을 만든 뒤, node fileName.js 를 터미널에 쳐주면 된다
test.js 라는 파일을 만들고, 해당 dir 이 잡혀있는 terminal 에다가 node test.js 를 넣어주면
사진처럼 브라우저 밖에서(터미널에서)도 잘 실행되는 JS 코드를 볼 수 있다
NVM, aka Node Version Manager
쉽게 말 해서 노드의 버전을 관리하는 매니저이다
설치는 NVM 의 공식 git 에 올려져 있는 방식으로 했다(링크, 클릭 시 이동)
+ 꼬일 시 해당 링크 확인하기(링크, 클릭 시 이동)
노드의 다른 버전에서 잘 실행되는지가 궁금하다면?
그럴 때 nvm 에서 node 를 버전별로 다운로드 받고, 다운받은 버전 별 노드를 사용할 수 있게끔 설정을 잡아주면 된다
(nvm install node-version-num, nvm use node-version 등의 기능 이용)
NPM, aka Node Package Manager
노드의 앱스토어 같은 존재
노드의 모듈들을 다운로드 받아서 사용할 수 있음
Package.json (내가 정말정말 궁금했던 거)
누군가 만든 코드를 돌리기 위해 필요한 모듈들을 적어놓은 카탈로그 같은 존재
npm install 을 해당 dir 에서 실행하면, Package.json 에 있는 모듈들을 다운로드 받음
Package.json 의 대략적인 구조는 다음과 같다
dependencies
: 이 프로젝트가 돌아가기 위해 ‘반드시 필요한 모듈' 들을 적어놓음
devDependencies
: 이 프로젝트를 개발하는 환경에서 ‘필요한 모듈' 들을 적어놓음
scprits
: npm 으로 실행시킬 수 있는 명령어를 정의함
: 우리가 일일히 실행시키는 게 아니라, npm starts 라고 치면 starts 에 정의해 놓은 명령어가 실행되는 방식, 간편하게 개발을 하기 위함임
eg. “starts” : “node app.js” 등으로
'code-states' 카테고리의 다른 글
| [code-states][we-win] 36일차 - refactoring with ES6 (0) | 2020.06.11 |
|---|---|
| [code-states][we-win] 35일차 - linting, testing (0) | 2020.06.11 |
| [code-states][we-win] 프리코스 수강 후기 (0) | 2020.06.05 |
| [code-states][we-win] 26일차~33일차 - underbar, recursion, pass me (0) | 2020.06.05 |
| [code-states][we-win] 25일차 - underbar (2일차) (0) | 2020.05.28 |
