티스토리 뷰
$ 개발 환경 세팅하기
# ESlint 설치 및 적용
npm insatll eslint --save-devnpm eslint --init // .eslintrc 파일 생성# ESlint 적용 예시
//.eslintrc
{
"extends": "eslint:recommend", // eslint에서 추천하는 규칙들을 적용하는 설정
"rules": { //프로젝트에서 자체적으로 덮어쓰고 싶은 규칙들을 정의할 때 사용
"semi": ["error", "always"],
//"always" : 표현식 끝에 항상 세미콜론 설정. 만약 세미콜론 작성하지 않으면 오류 발생
"quotes": ["error", "double"]
// "double : ""(따옴표)사용 설정. 만약 따옴표로 작성하지 않으면 오류발생
}
}
// 규칙을 지정하는 배열의 1번째 요소 : 규칙이 어긋났을 때, 나타내는 표현강도(?)
// 규칙을 지정하는 배열의 2번째 요소 : 규칙의 설정값.
// 예를 들면, "quotes": ["error", "double"]
// 규칙으로 더블 따옴표로 사용 설정, ""(따옴표)작성하지 않으면 오류. 즉, 해당 규칙이 지켜지지 않을 경우, "erro"표시
# ESlint 적용 예시
// .eslintrc
{
"extends":"eslint:recommended", // eslint에서 추천하는 규칙들을 적용
"env": { // 프로젝트의 사용 환경 적용
// 미리 정의된 전역 변수를 정의한다
"node": true, // 전역변수는 node.js로 추측된다.
// Node.js global variables and Node.js scoping.
"es6": ture, // 모듈을 제외한 ECMAScript 6기능을 모두 활성화
// ecmaVersion parser option to 6 로 설정이된다함.
// ecmaVersion parser option가 무엇일까?
// enable all ECMAScript 6 features except for modules (this automatically sets the ecmaVersion parser option to 6).
}
"rule": {
"no-console":"off"
// 콘솔함수 사용 시, 오류 발생 하지 않는 설정.
// 실제로 배포했을 때, 콘솔이 찍혀있으면 안되니깐(?)
}
}
어제부터 나의 첫 프로젝트가 시작되었다. 혼자가 아닌 팀원과 함께 프로젝트를 진행하는 것이 처음이라 모든 것이 쉽지 않다. 예를 들면, ESlint, prettier 세팅하기
어떤 설정을 하면 좋을지 사실 잘 모르겠다. 스프린트 때, 간단하게 설정했던 "no-console":"off" 같은 세팅 밖에 떠오르지 않았다.
1차 개발 환경 설정이 끝나고서야, ESlint 공식 문서로 설정에 대한 의미도 좀 꼼꼼하게 찾아보고, 유어 클래스 ESlint 설정 부분까지 빠르게 훑어봤다. 한편으로는, 혼자서 무심결에 사용했던, 따옴표(""), 작은따옴표('')들도 협업 또는 코드 병합을 위해서는 어떤 따옴표를 사용할지 정하는 것도 아주 중요했다. 이제 쪼금 팀 프로젝트가 실감이 난다. 아마 프로젝트 진행 중에 추가적으로 세팅을 해야겠다.
$ git workflow 이해하기
? upstream이란 무엇이고, upstream에는 왜 2개의 브랜치가 있는걸까?
- upstream : master 레파지토리
- master : dev 브랜치에서 합쳐진 코드가 최종적으로 보내지고 배포하는 브랜치
dev : 개발단계에서 PR요청을 받아서 코드가 합쳐지는 브랜치
< git workflow 순서>
< 팀장 기준 >
1. upstream : 코드 스테이츠에서 만들어 준, 프로젝트 레파지토리를 fork(복사)한다
2. 팀장의 깃 헙, 원격 저장소에서 fork(복사)한 프로젝트 레파지토리를 확인한다.
3. 팀장의 로컬에서 project 이름을 가진 폴더를 생성한다.( mkdir <폴더 이름> )
4. project폴더 안에서 git clone <fork 한 프로젝트 레파지토리 주소> 통해 clone 한다.
<원격 저장소의 레포를 로컬로 clone 하면 master branch(더 정확하게 default branch)만 clone 된다>
5. master branch에서 초기 세팅을 한다
5 - 1. npm init : package.json 파일 생성 / 프로젝트 정보 이름, 버전, 설명, git 주소 등 / 모듈 내용이 기록
5 - 2. eslint / prettier 설정 : .eslintrc / .prettierrc / .gitignore 설정
6. 초기 셋팅 완료 후, git push origin master (원격 저장소로 커밋 보내기)
6. 로컬에서 dev 브랜치 생성 : git branch dev ( git branch <branchname> )
7. 로컬에 있는 dev 브랜치를 upstream 원격 저장소로 push 한다 : git push origin dev
: 로컬, 원격 저장소에 dev 브랜치가 생성됨( 원격 저장소로 dev브랜치(커밋들이 만들어짐) 보내기 / 원격 저장소의 dev브랜치의 commit을 저장하기)
8. : git branch --set-upstream-to origin/dev
8번을 왜 설정해야 할까? 로컬 dev브랜치와 원격 저장소 dev브랜치를 연동하기 위해서(git remote add <이름> 연결할 원격저장소 주소)
**팀원들이 사용할 Project 초기 세팅 완료**
<팀원 기준>
1. upstream인 프로젝트 레파지토리를 fork(복사)한다.
2. 나의 깃 헙, 원격 저장소에서 fork(복사)한 프로젝트 레파지토리를 확인한다.
2. 나의 로컬에서 project 이름을 가진 폴더를 생성한다.
3. 나의 로컬 project 폴더 안에서 git clone <내가 fork 한 프로젝트 레파지토리> 통해 clone 한다
<원격 저장소의 레포를 로컬로 clone 하면 default branch만 clone 된다.>
4. 이 경우, upstream 레파지토리의 settings- branches-설정하고 싶은 기본 브랜치 선택 - update 설정을 해주면, 내가 원하는 default branch를 clone 할 수 있다.
4 - 1 ) 깃 헙에서는 master branch가 default branch로 설정이 되어 있기 때문에, 내가 클론 한 레파지토리의 default branch는 master branch일 경우,
upstream의 dev 브랜치의 merge를 위해서 나의 로컬 안 master branch에서 dev 브랜치를 하나 생성한다!
4 - 2 ) dev branch 위치에서 git push origin dev
: 왜 로컬 dev branch를 push 할까? dev브랜치는 백업용 branch로 이용하기 위해서
5 ) **항상 내가 어디 branch에서 작업을 하고 있는지 확인하고 branch를 생성할 것**
dev branch에서 새로운 기능을 구현할 branch를 생성한다. 예를 들어, dev branch에서 comments branch 생성하기 : git checkout -b comments(comments 브랜치 생성 및 comments 브랜치로 이동)
**주의점** : 로컬의 master branch가 아니라 로컬의 dev branch에서 기능을 구현할 branch를 만든다.
6 ) comments 기능을 다 구현했다고 가정하자. 나의 원격 저장소로 comments branch를 push 해준다
: git push origin comments
: 로컬 comments 브랜치에서 작성한 코드를 원격 저장소로 업데이트 및 upstream dev 브랜치로 코드 병합(merge) 하기 위해서
★ upstream(원격 저장소)과 나의 로컬을 연결해주기 : git remote add upstream <upstream 원격 저장소 주소>
7 ) 원격 저장소에 있는 comments 브랜치를 upstream의 dev 브랜치로 PR 요청을 한다.
8 ) 팀원과의 코드 리뷰가 끝나고, upstream의 dev 브랜치에서 merger를 여부를 결정한다.
9 ) 팀원과 코드 리뷰가 끝이 나고, merge승인을 받아, merge를 진행한다. 그러면 upstream의 dev branch의 코드는 업데이트가 되었다.
10 ) 새로운 기능을 구현하기 위해서 나의 로컬 dev브랜치에서 코드 최신화를 해야 한다.
: git pull upstream dev
11 ) 바로 로컬 dev 브랜치에서 push를 해서 나의 원격 저장소 dev의 코드를 최신화 및 백업해준다.
12 ) 그리고 다시 로컬 dev 브랜치에서 기능을 구현할 새로운 브랜치를 생성하고 위와 같은 flow가 반복된다.
$ 오늘의 꿀팁!
서버 구축하기 위해서 Node.js의 express 모듈을 설치를 진행했다. 항상 --save 옵션을 이용해서 package.json의 dependencies에 등록했었다. 팀원이 아래와 같이 명령어를 작성할 때, 엇! --save옵션! 내가 혹시나 모르는 부분이 있나 싶어서 팀원에서 package.json을 보여달라고 했다. 근데 dependencies에 express가 등록되었다. 띠용! 왜 저렇게 되는지 물어봤어야 했는데, 다른 작업을 수행을 진행하기 위해서 그냥 지나쳤다. 그러다가 다른 팀원이 질문을 하게 되면서 제대로 알게 되었다.
npm install express npm-install 공식문서에서 확인할 수 있었다. 구글링 해보니깐, npm 5에서는 --save 옵션 없이 필요 없다고 한다.
npm install saves any specified packages into dependencies by default.
// npm install는 기본적으로 dependencies(종속성)에 지정된 패키지들을 저장한다.
나도 꿀팁들을 팀원들에게 공유해줄 수 있는 실력을 쌓을 수 있길....💪
$ 👀🤔
git workflow 테스트를 진행하면서 내가 왜 원격 저장소 추가/연결하기를 잘 못 이해하고 있었을까라는 생각이 들었다. git remote -v 를 통해 나의 로컬 폴더에 원격 저장소를 확인할 수 있는데 말이다. 결국 나의 'origin'이라는 원격 저장소는 자동으로 등록이 되고, git remote add upstream <원격저장소 주소> 통해서 'orgin'이 아닌 다른 원격 저장소가 추가된다.
만약에 로컬 dev 브랜치를 생성하고, dev 브랜치에서도 git remote -v 하면 위와 같은 그림의 원격 저장소 나올 것이다. 나는 로컬의 각 브랜치마다 원격 저장소를 연결해야한다고 생각했다 ;; (아님)
결국 원격 저장소를 연결하는 이유는 원격 저장소의 코드들을 로컬에서 가져오고 싶은 것이다. 어렴풋이 알고 있는 것이 더 무섭다.
브랜치 생성 및 브랜치 이동하기
git checkout -b <브랜치 이름> // 브랜치 생성 및 생성된 브랜치로 이동브랜치 삭제하기
git branch -D <브랜치 이름> // 브랜치 삭제하기
$ 내일은 프로젝트 폴더 구조 설정을 마무리하고 싶다. 화이팅!