우아한 프리코스 1주차 공통피드백을 받고 적잖히 당황했습니다. 1주차 미션의 목표 중 하나가 git에 익숙해지기 였는 데 "나는 과연 익숙한가?"를 생각해보면 익숙하기 하기야 하지만 쓰는 명령어가 지극히 제한돼 있다 느꼈고, git 컨벤션을 제대로 익히고 쓰고 있는 지 확신이 들지 않았습니다.( 그러고 보면 미션 초반 포비가 1주차 미션의 목표는 환경설정에 익숙해지는 것이다라고 말씀하셨던게 이제야 기억이 나네요..) 코드를 잘 작성하고 싶다는 마음과 코드 리뷰중 보인 클래스 문법과 mvc 패턴을 익히고 싶은 욕구때문에 정작 중요한 git에 미쳐 깊게 파고들어 공부하지 못했다고 느꼈습니다. mvc 패턴보다 git을 익숙해지고 정확히 사용하는 것이 더 중요하다 판단해 해당 과정을 공부했습니다.
커밋단위를 너무 짧게 가져가다보니 주석 삭제 와 같은 부가적인 일들을 의미있게 작성하기 어려웠습니다. 이번 미션에는 기능목록단위로 커밋하라고 해서 확실히 커밋량이 대폭 줄여 보다 의미있게 작성할 수 있을 것 같아요. 다시 확인해보니 컨벤션도 엉망이네요;ㅅ; 이를 해결하기위해 커밋메시지틀을 전역으로 설정할 수 있는 것을 발견해 적용했습니다. 이제는 확실히 커밋 컨벤션도 지킬 수 있게 되었습니다. 히야!
node modules는 package.json 파일이 있으면 설치할 수 있다고 하는데 node modules.. 알고 있었던 거 같은데.. 뭘까요? package.json 파일만 있으면 어떻게 node modules 설치 할 수 있을까요? .vscode 폴더 또한 개발 도구가 자동으로 생성하는 폴더이기 때문에 굳이 git 에서 관리하지 않아도 된다고 하는데 제 프로젝트에서는 .vscode폴더가 있을까요? 현재 프로젝트 폴더 구조를 정확히 파악하고 git을 통해 관리할 필요가 있는 지 살펴봅시다. 그리고 제거해 git 환경을 관리해봅시다.
node Module?
필요한 함수들의 집합을 의미합니다.
- core module(built-in module)
- local module
아하! package.json 은 프로젝트의 모듈의존성을 관리하는 패키지매니저 즉 "이 프로젝트는 이 함수,저함수 필요해"라는 주문서이니 주문서만 git 에 들어가면 실질적인 함수들은 설치 할 수 있어 필요가 없는 거였군요! node Module 은 package.json 보고 나중에 설치하면 되니 git 에 넣을 필요가 없다는 말이 확 이해가 됐습니다.
.vscode 폴더
.vscode 폴더 또한 개발 도구가 자동으로 생성하는 폴더이기 때문에 굳이 git 에서 관리하지 않아도 된다고 하는데 로컬이나 리모트 어느곳에도 보이지 않아 당황스러웠습니다. 뭐지?라는 생각이 들어 커뮤니티에 관련 사항을 동기들과 대화나누니 로컬 저장소의 상위폴더
a/b/c/javascript-baseball 라면 /a 나 /a/b 나 /a/b/c 에 .vscode 디렉토리가 있을 수 있다 말씀주셨습니다. 그래서 해당 프로젝트 로컬 저장소 상위폴더를 탐색해보니 상위폴더에도 보이지 않았습니다. 아마 기존 vscode 가 설치된 기존 장소가 아닌 임의의 장소로 클론 받아서 해당 vscode 가 안보이는 듯했어요. 리모트 레파지토리에도 올라가지 않은거 보니 잘된거네요!
프로젝트 폴더 구조를 파악하고 git 관리가 필요한 지 필요없는 지 파악해보자구요~!
이번 2주차 폴더구조를 살펴보며 git 관리가 필요한지 파악해 보겠습니다. __test__ 파일은 테스트코드들이 들어있는 파일입니다. 프로젝트를 출시를 위한 main 브랜치에는 필요없을 수 있을 것 같아요? 근데 이번 2주차 미션은 프로젝트 출시가 아니고 함수마다 각각의 테스트코드를 검토하라고 하셨으니 git 관리에 필요한 폴더로 예상됩니다. does 파일은 기능 명세서가 들어있있습니다. 기능명세서는 협업시 개발자들간에 앞으로 구현해야할 기능들을 충분히 인지할 수 있어 깃관리에 필요한 대상이라 생각됩니다. src 폴더는 소스코드가 모여있는 폴더이고,gitignore 는 깃관리에 제외되어야할 파일을 관리할 수 있는 파일입니다. 따라서 로컬 환경에서만 작성되어 리모트레파지토리에 깃에 올라가기 불필요한 폴더를 선별해주면 되기때문에 gitignore 파일 또한 깃관리에 제외되어야 한다고 생각합니다. 여기서 새롭게 배운 것은 .npmrc 파일인데요. .npmrc 파일는 npm에서 설정을 저장해두는 파일이라는 데 git 관리에 필요한 가요? 파일명 앞에 .을 붙였으니 기본적으로 숨긴 파일로 취급해 깃관리에 필요하지 않을까요? 그리고 gitignore 에는 왜 package-lock.json 파일이 들어있을까요?
.npmrc 파일
npm에서 설정을 저장해두는 파일.
branch ?
개발자들간의 동일한 소스코드를 함께 공유하고자 할때, 동일한 소스코드를 기반으로 서로 다른 작업을 할때 동시에 다양한 작업을 할 수 있게 만들어 주는 기능
실수 했을 때 reset과 revert
로컬에서 혼자 작업할때
git reset HEAD~1
커밋한개가 삭제된다.
git revert HEAD
기존 커밋2는 살아있으면서 커밋2의 내용만 없는 새로운 커밋2`가 생성됨
삭제된 커밋, 브랜치 복구
git reflog
git reset --hard 커밋2의 hash 값
git switch -c step3 커밋3의 hash
git merge
step1가 head 상태에서
git merge bugFix
bugFix 내역을 합친 step1이 커밋4가 만들어지며 이동
bugFix 가 head 인 상태에서
git merge step1
커밋이 생성되지 않고 기존 step1 과 bugFix 가 같은 곳을 가르키게 됨.
git rebase
bugFix 가 HEAD 인상태에서
git rebase step1
커밋2 뒤에 step1을 합친 bugFix 가 기존 연결을 끊고 올려놓은 상태
step1 이 head 인 상태에서
git rebase bugFix
step1가 bugFix의 부모이기때문에 커밋이 만들어지지 않고 위치가 이동하게 됨.
상대 참조
git switch HEAD^^^
head 위치가 캐럿(^)횟수만큼의 부모 커밋으로 이동한다.
git branch -f step2 step1~2
step2를 step1의 2번째 부모 커밋으로 이동한다.
.gitignore 파일
로컬 환경의 정보나 빌드 정보등 원격 저장소에 관리되지 말아야 되는 파일들에 대해 지정하여 원격 저장소에 실수로 올라가지 않도록 관리하는 파일을 말합니다.
- 프로젝트 최상위 위치에 존재한다.
- # 으로 시작하는 라인은 무시한다.
- 표준 *glob 패턴을 사용한다.
*glob 패턴 : 와일드카드 문자를 사용해서 일정한 패턴을 가진 파일 이름들을 지정하기 위한 패턴
- /**/*.js: 현재 디렉토리와 그 하위 디렉토리 내에 존재하는 모든 .js 파일들을 선택
- /*.{js,ts}: 현재 디렉토리 내에 존재하는 모든 .js, .ts파일들을 선택
- /example[1-3].js: 현재 디렉토리 내에 있는 example1.js, example2.js, example3.js파일들을 선택
출처
https://www.youtube.com/watch?v=b72mDco4g78
https://www.youtube.com/watch?v=JsRD2AWxxFg
https://rogerdudler.github.io/git-guide/index.ko.html
git - 간편 안내서 - 어렵지 않아요!
rogerdudler.github.io
https://www.inflearn.com/course/git-and-github
[무료] Git과 GitHub 시작하기 - 인프런 | 강의
배우기 어려운 Git의 사용법을 쉬운 Gui 프로그램인 SourceTree를 통해 익혀봅시다., [임베딩 영상] git과 github git 은 형상 관리 시스템(Verson Control System) 의 한 종류입니다. 주로 개발자들이 프로그램
www.inflearn.com
