Node.js, Git, Github 정리포스팅

오늘 배운 node.js, git, github에 대해 다시 정리하면서 적어보려고 한다.

먼저, node.js 에 대한 정의를 알아보자.

Node.js는 JavaScript로 브라우저 밖에서 서버를 구축하는 등의 코드를 실행할 수 있게 해주는 런타임 환경이다. 빈번한 I/O 처리에 있어서 우수한 성능, 서버 확장의 용이성 그리고 JavaScript언어로 작성할 수 있다는 점에서 프론트엔드에서 엄청많은 사용을 하고있다.

Node.js 설치

Node.js 는 홈페이지에 들어가서 가장 최신버전과 LTS버전을 볼 수 있다.
nvm install 버전 을 입력하여 해당 버전의 node.js를 설치할 수 있다.

---

package.json 은??

package.json 이란 남이 만들어 놓은 모듈을 node.js 에서는 npm 모듈이라고 부르며, 이에 대한 정보를 담아둔 곳이 package.json이다.
node.js 환경에서 외부 라이브러리를 다운로드하는 대표적인 방법이 npm이다.
npm= Node Package Manager 로 일종의 앱스토어라고 생각하면 된다.
필요한 모듈을 다운로드할 수 있는 모듈들이 모여있다.

package.json에는 해당 프로그램을 실행시키기 위해 필요한 모듈들이 무엇인지, 프로그램을 실행시키는 방법, 프로그램을 테스트하는 방법 등이 명시되어있다.

🚨 주의 : 해당 프로그램을 실행시키기 위해 필요한 실제 모듈은 node_modules 라는 폴더에 저장이 된다. package.json에는 어떤 모듈인지만 적혀 있다.

---

package.json 내부 설명

1. devDependencies : 어떤 개발을 할때, 보조해주는 라이브러리들이 저장이 된다. 즉, 로직과는 직접적인 연관이 없는 라이브러리들이 저장이 되는 것이다. 보통 devDependencies에 설치를 하려고 할때는 npm install 라이브러리명 -D 로 설치를 한다. 뒤에 -D를 붙이면 dev에 넣겠다는 말인 것이다. prettier, eslint 등이 대표적인 예시이다.

2. dependencies : 프로젝트 작업 중에 npm install 라이브러리명 명령어를 통해서 설치한 라이브러리들이 들어가 있다. 배포할 때 사용할 라이브러리들이 담겨 있는곳이라고 보면된다. 즉, 동작을 도와주는 라이브러리들이기 때문에 배포할 때 포함을 시켜줘야한다. react, underscore 등이 대표적인 예시다.
   ⭐️ 결국 devDependencies 와 구분하는 이유는 배포할 때 빌드 시간도 줄이고, 불필요한 라이브러리를 포함시키지 않으려 구분을 한다.

3. script : 반복적으로 수행해야하는 스크립트를 등록해놓을 수 있다.
   스크립트를 등록할 때는 package.json을 열고 직접 편집할 수도 있으나 그러면 오타의 위험이 있어서 가급적 npm set-script {스크립트 이름} {명령어} 명령어를 사용하는 것을 추천한다.
   예를 들어, 콘솔에 Hi! 를 출력해주는 명령어를 실행해주는 hi 라는 스크립트를 추가하려면 npm set-script hi "echo 'Hi!'" 를 입력하면, package.json 파일에 hi 라는 스크립트가 추가되어있을 것이다.
   등록한 스크립트를 실행하려면 npm run 스크립트이름 으로 실행을 할 수 있다.

---

🔗 Git이란 무엇일까??

Git은 분산 버전 관리 시스템(DVCS)의 일종이며, 형상 관리 도구(CMT)라고도 불린다. 주로 소프트웨어를 개발하는 소스 코드를 효과적으로 관리할 수 있게 도와주는 무료 오픈 소프트웨어이다.
깃은 DVCS의 일종이기 때문에 중앙 저장소가 손상되어도 로컬 저장소를 이용하여 원상복구가 가능하다. 또한 로컬 저장소에서 개발을 진행할 수 있기 때문에 인터넷 연결이 필요하지 않아도 되며, 각각의 개발자들이 브랜치(branch)를 통해 개발한 후 합치는(merge) 방식으로 진행할 수 있기 때문에 협업도 쉬워진다.

❓ 그럼 깃은 왜 사용하나요!?

개발자들이 깃을 사용하는데에는 여러가지 이유들이 있다. 이유들을 알아보자

1. Branching and Merging : 깃은 브랜치(branch)와 합병(Merge)이라는 개념이 있다. 간단하게 소개하자면 브랜치는 말 그대로 가지(branch)라고 볼 수 있다. 나무에서 여러 갈래로 가지가 뻗어나가는 것처럼, 소스 코드도 여러 개의 가지를 뻗어나갈 수 있다. 새로운 아이디어를 적용시켜보거나, 버그를 고치거나, 이전 버전으로 돌아가거나, 패치를 적용시키거나... 많은 가지들을 만들 수 있으며 이것을 합칠(merge) 수 있다.

2. Small and Fast : 깃은 빠르다. 깃은 거의 모든 동작이 로컬에서 진행되기 때문에 다른 VCS처럼 서버와의 통신에 많은 비용을 들이지 않아도 된다. 또한, 깃은 C언어로 작성되어 있어 속도가 빠르다. 깃의 주요 디자인 목표가 속도와 성능이라고 한다.

3. Distributed : 깃은 분산되어 있다. 사용자는 전체 저장소를 복제(clone)해서 로컬 저장소로 가져온다. 이는 수많은 백업들이 분산되어 저장되어 있다는 뜻이다. 따라서 중앙 저장소의 장애를 극복하기 쉬워진다.
   깃은 분산되어 있기 때문에 쉽게 수 많은 workflow를 가질 수 있다.

4. Staging Area : Staging Area는 커밋이 일어나는 곳으로 커밋이 일어나기 전 검증을 할 수 있는 곳이다. 커밋은 이 Staging Area에서 Repository(저장소)로 파일을 보내는 것을 의미한다. 따라서 커밋 할때 코멘트를 통해 누가 어떤 파일을 추가, 수정, 삭제했는지도 확인이 가능하다.

⚙️ Git 초기설정 방법

macOS를 기준으로 homebrew를 통해 git을 install하고,
사용자 이름과 이메일 주소를 설정하는 것이다. 터미널 화면에 다음과 같이 입력해주면 된다.

$ git config --global user.name "나의 사용자 이름"
$ git config --global user.email "내 이메일 주소"

입력하고 난뒤, git config --list 를 통해 입력한 이름과 주소가 잘 들어갔는지 확인을 할 수 있다.

🖋️ Git의 명령어

깃의 명령어들 중 자주 쓰이는 명령어들에 대해 알아보자!

• git init : 깃 초기화. 이 명령어를 실행해야만 깃이 실행된다. 이 명령어 실행 전까지는 그냥 일반 폴더일 뿐이나, 이후엔 추가적인 명령어들을 통해 작업을 진행 할 수 있다.
  
  
• git status : 깃 저장소의 상태를 확인한다. 이 명령어를 통해 현재 상태가 어떤 지 수시로 확인 가능하다.
  
  
• git add : 커밋에 파일의 변경 사항을 포함하도록 한다. 이 명령이 저장소에 새 파일들을 직접적으로 추가하진 않는다.
  
  
• git commit : "git commit -m '저장명'" 등과 같은 명령어로 주로 사용한다. 이 명령어를 통해 커밋을 생성하고, 변경 사항을 확정하여 반영한다.
  
  
• git clone : 기존 소스 코드 다운로드 및 복제한다. 즉, 원격 저장소의 저장소를 로컬에서 이용할 수 있도록 복사해 가져온다.
  
  
• git log : 나의 커밋 내역에 대해 알고 싶을 때 사용하면 현재 커밋 목록들을 확인 가능하다.
  
  
• git checkout : 브랜치에서 브랜치로 이동 가능하다. 현재 버전에서 이전 버전의 커밋으로 이동하거나 변경 전의 브랜치로 접근 가능하다.
  
  
• git checkout master : 이전 버전, 변경 전 브랜치에서 다시 현재의 (master) 브랜치로 되돌아 올 수 있다.
  
  
• git push : 로컬 저장소의 소스 코드 변경 사항을 원격 저장소에 반영한다.
  
  
• git pull : 원격 저장소의 변경 내용이 현재 디렉토리로 가져와진 뒤, (fetch) 병합된다.
  
  
• git merge : 변경 사항 등이 모두 확정되고 난 후, 브랜치들을 병합한다. 작업 마무리 단계에서 시행한다.

---

🗄️ Github란 무엇인가??

깃허브는 소프트웨어 개발 프로젝트를 위한 소스코드 관리서비스(원격 저장소) 입니다. 소스코드 열람 및 간단한 버그정리, 버전관리 그리고 sns기능도 있는 호스팅 플랫폼 서비스입니다. 그래서 함께 개발한 소스코드를 공유할때 또는 상대로부터 받은 코드를 수정할때 굉장히 유용하게 쓰입니다. 즉, 깃을 활용해서 짠 코드를 공유할 수 있는 공간이라 생각하면 됩니다.

❓ 그럼 깃허브는 왜 사용할까요!?

깃허브를 개발자들이 많이 사용하는 이유는 여러가지가 있다. 그 이유에 대해 알아보자

1. 원격 저장소에서 깃을 사용할 수 있습니다.
지역 저장소를 만들지 않아도 깃허브에 원격 저장소를 만들어 사용 할 수도 있고, 지역 저장소가 있다면 원격 저장소와 연결해서 사용 할 수도 있습니다.

2. 지역 저장소를 백업할 수 있습니다.
깃허브에 원격 저장소를 만들고 사용자 컴퓨터의 지역 조장소를 연결한 후 동기화를 하면 지역 저장소를 인터넷상에 백업할 수 있습니다. 깃허브에 백업하면 원격 저장소에 손쉽게 커밋할 수 있습니다.

3. 협업 프로젝트에서 사용할 수 있습니다.
팀 프로젝트를 진행할 때도 이젠 깃허브가 기본 저장소가 된다. 인터넷만 가능하면 누구나 쉽게 접근할 수 있고, 깃과 깃허브에서 여러 가지 협업 도구를 제공하기 때문에 깃허브를 사용하면 여러 명의 팀원이 하나의 프로젝트를 진행하기 쉽습니다.

4. 자신의 개발 이력을 남길 수 있습니다.
깃허브에서 소스를 수정하고 오픈 소스에 참여해서 하는 일들은 사용자 초기 화면에 날짜별로 모두 기록에 남습니다. 지원자가 어떤 주제에 관심이 많은지, 어떤 것들을 개발했는지, 그리고 무엇을 개발 중인지 한눈에 확인할 수 있기 때문에 깃허브는 개발자가 자신의 개발 이력을 관리하기 좋은 플랫폼입니다.

5. 다른 사람의 소스를 살펴볼 수 있고, 오픈 소스에 참여할 수도 있습니다.
개발자로서 실력을 높이는 방법 중 하나가 다른 사람의 소스를 읽어보고 분석하면서 나름대로 소스를 수정하고 작성해 보는 것입니다. 깃허브는 전세계 개발자들이 공개해 놓은 소스들이 많습니다.