Git

Git

분산 버전 관리 시스템 (VCS). 프로젝트 파일의 변경 사항을 추적하는 시스템. 프로젝트의 변경 사항을 기록하고, 특정 시점의 버전으로 언제든 돌아갈 수 있음.
이런 버전 관리 시스템은 많은 사람들이 효율적으로 함께 작업하고, 프로젝트를 중심으로 협업할 때 사용할 수 있음. 각 개발자가 자신만의 프로젝트 버전을 본인 컴퓨터에 갖게됨. 나중에 이러한 개별 버전의 프로젝트를 병합하여 기준이 되는 버전의 프로젝트에 적용 할 수 있게 됨.

Git 공식 홈페이지: https://git-scm.com/

• 즉, git은 버전관리를 도와주는 시스템. Github은 Git을 이용해 버전관리한 프로젝트들을 관리 하게 해주는 호스팅 서비스.

Installation Guide (설치 가이드)

Git은 주로 command-line interface (CLI)를 통해 사용
우리 컴퓨터에 Git이 설치되어 있는지 확인부터 해야함

Git 다운로드 링크: https://git-scm.com/downloads

설치를 마쳤으면, Git을 사용할 수 있는지 확인하기 위해 터미널을 여시고 아래 커맨드를 입력

git --version

Git이 정상적으로 설치되었다면, 설치되어 있는 Git 버전이 표시됨.
Mac 혹은 Linux를 사용하신다면 기본으로 제공되는 Bash 터미널을 사용하시면 됨
Windows를 사용하신다면, 기본으로 제공되는 Powershell 을 사용하셔도 되고, Git 설치와 함께 딸려오는 Git Bash 를 사용하셔도 됨.

• 이름 & 이메일 설정
  Git에 본인 정보를 등록하기 위해 터미널에서 아래 커맨드를 입력
  git config --global user.name "이름"
  git config --global user.email "이메일"
  "이름" 과 "이메일" 을 실제 본인의 정보로 대체

Repositories (저장소)

Git repository는 Git으로 관리하는 프로젝트 저장소 ( 쉽게 말해 폴더 )

• 종류
  • Local repository - 본인의 컴퓨터에 저장된 로컬 버전의 프로젝트 저장소
  • Remote repository - 로컬 repository 와는 반대로 내 컴퓨터가 아닌 외부 (일반적으로 원격 서버) 버전의 프로젝트 저장소. 팀에서 작업 할 때 특히 유용함. 이 곳에서 프로젝트 코드를 공유할 수 있고, 다른 사람의 코드를 확인할 수도 있음. 또, 로컬 버전의 프로젝트와 병합하고, 변경 사항을 적용 할 수 있는 곳.

Initializing a repository

새 저장소(repository) 를 만들고 Git으로 프로젝트 관리를 시작하려면 터미널에서 프로젝트 폴더로 이동 후 다음 명령어를 입력

git init

이 명령어는 프로젝트 폴더 내에 숨겨진 .git 디렉토리를 생성
Git은 현재 저장소에 대한 모든 변경사항을 추적/관리

Staging and committing code

Git에서 commit 이란, 프로젝트의 현재 상태를 나타내는 체크포인트 또는 스냅샷으로 생각
현재 버전의 코드를 커밋에 저장한다고 생각
커밋 히스토리에 필요한만큼 커밋을 생성 할 수 있으며, 커밋 간 앞뒤로 이동하여 프로젝트 코드의 다른 변경사항을 확인할 수 있음.
이를 통해 프로젝트의 진행 상황을 효율적으로 관리할 수 있게 됨.
커밋을 남기는 시점은 특정 내용, 기능을 추가한 후 또는 수정 사항을 적용한 후 정도

코드를 커밋하려면 우선 코드를 staging area 에 추가해야 함

• Checking the status (상태 확인)
  터미널에서 (프로젝트 폴더 내) 다음 명령어를 입력하여 repository의 현재 상태를 확인할 수 있음.

git status
위 명령어는 Git으로 작업 할 때 굉장히 자주 사용되는 명령어입니다. 어떤 파일이 변경되었는지, 어떤 파일이 추가되었는지 등을 전부 보여줌.
git status 명령어를 통해 Git 으로 관리(추적)되고 있지 않던 파일(들)이 있다면 해당 파일들을 staging area 로 추가해줄 수 있음.
모든 파일이 Git으로 관리되고 있는 시점에서는, git status 명령어를 통해 모든 변경사항을 확인할 수 있고, 커밋을 남기기 위해 staging area 로 추가해줘야 함.

• Staging files (Staging area에 파일 추가하기)
  프로젝트 폴더에서, git add 라는 명령어를 통해 우리가 원하는 파일들을 staging area 로 추가해줄 수 있음
  아래와 같이 특정 파일만 추가할 수 있음. 파일 수정 이력 기록 준비

git add file.js

여러개의 파일들을 추가하고 싶다면 아래와 같이 할 수 있음.

git add file.js file2.js file3.js

파일을 각각 추가하지 않고, 아래와 같이 모든 파일을 한번에 추가할 수도 있음.

git add .
위 명령어는 프로젝트 폴더 내의 모든 파일과 폴더를 staging area 에 추가하고 커밋을 남길 수 있게 해줌.

• Making commits (커밋 남기기)
  파일 수정 이력 기록. 커밋은 특정 시간의 코드 스냅샷의 형태로 해당 repository의 커밋 기록에 남게됨. git add 명령어를 사용하여 모든 파일을 staging area에 추가 해주었다면 이제 커밋을 남길 준비가 됨.
  아래 명령어를 통해 staging area에 있는 파일들을 커밋할 수 있음.
  git commit -m "Commit message"

식별을 위해 큰 따옴표안에 커밋 메세지를 작성해야 함
커밋 메시지는 repository에 커밋하는 변경 사항을 설명하는 짧은 summary 여야 함
위 명령어를 실행하면, 터미널에 방금 남긴 커밋에 대한 세부 내용이 보여지게 됨.

새 커밋을 남기려면 staging area에 파일을 추가 한 다음 커밋을 남기는 프로세스를 반복해야함. git status 명령어를 통해 어떤 파일이 수정, 추가 또는 추적되지 않고 있는지 확인할 수 있음.

• Commit history
  프로젝트의 모든 커밋 내역을 보려면 다음 명령어를 입력하면 됨

git log

git log 명령어를 통해 보여지는 log는 각 커밋에 대한 자세한 정보를 담고 있음. (작성자, hash 값, 날짜와 시간, 그리고 커밋 메세지)
만약 특정 커밋 시점의 코드로 되돌리고 싶다면, 아래 명령어를 사용할 수 있음.

git checkout <commit-hash>

<commit-hash> 를 git log 에서 보이는 커밋의 실제 hash 값으로 대체해주세요.
또는
git reset --hard b949fbf1f82c4a322af41b9252b8ca41405f43b6

• Ignoring files
  staging area 에 추가하고 싶지 않거나, git 에서 관리하지 않아도 되는 파일이 있다면, .gitignore 파일을 프로젝트 폴더에 생성해주시면 됨.
  .gitignore 파일 안에, 해당하는 파일명과 폴더명을 나열하면 됨.
  (각 파일, 폴더가 새로운 줄에 입력되어야 함.)

  # 예시
  
  .DS_*
  *.log
  logs
  **/*.backup.*
  **/*.back.*
  node_modules
  bower_components

Branches

독립적으로 어떤 작업을 진행하기 위한 개념. ( 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행할 수 있음. )

• 사용방법

  • 메인 브랜치에서 자신의 작업 전용 브랜치를 만듬( 여러 명이서 동시에 작업을 할 때에 다른 사람의 작업에 영향을 주거나 받지 않도록 )
  • 각자 작업을 진행한 후, 작업이 끝난 사람은 메인 브랜치에 자신의 브랜치의 변경 사항을 적용.
  • '작업 단위', 즉 브랜치로 그 작업의 기록을 중간 중간에 남기게 되므로 문제가 발생했을 경우 원인이 되는 작업을 찾아내거나 그에 따른 대책을 세우기 쉬움.
  • 저장소를 처음 만들면, Git은 바로 'master'라는 이름의 브랜치를 만들어 둠. 새로운 저장소에 새로운 파일을 추가 한다거나 추가한 파일의 내용을 변경하여 그 내용을 저장(커밋, Commit)하는 것은 모두 'master' 라는 이름의 브랜치를 통해 처리할 수 있는 일이 됨.
  • 'master'가 아닌 또 다른 새로운 브랜치를 만들어서 '이제부터 이 브랜치를 사용할거야!'라고 선언(체크아웃, checkout)하지 않는 이상, 이 때의 모든 작업은 'master' 브랜치에서 이루어 짐.

• Creating a new branch (브랜치 생성하기)
  git branch <new-branch-name>
  새로 만들어진 브랜치는 현재 프로젝트의 코드를 그대로 반영하여 생성

  보통 코드를 개선하고 새로운 실험 기능을 추가하는 등의 작업을 할 수있는 development 브랜치를 만드는 것이 좋음. 새로운 기능을 개발하고 테스트 한 후 버그가 없고, 사용할 준비가 되어있는지 확인한 후 최종적으로 master 브랜치에 병합할 수 있음

• Changing branches (브랜치 전환하기)
  git checkout <branch-name>
  원하는 브랜치로 이동하면, 해당 브랜치 안에 있는 마지막 커밋 내용이 작업 트리에 펼쳐침.
  브랜치가 전환 되었으므로 이후에 남기는 커밋은 전환한 브랜치에 추가됨.
  ( 해당 브랜치에만 영향 )
  그 다음, 다른 브랜치로 이동하여 작업 할 수 있으며, 이전 브랜치의 변경 사항 및 커밋의 영향을 받지 않음.

git checkout -b <new-branch-name>
브랜치 생성과 동시에 생성된 브랜치로 이동하고 싶다면 기존 checkout 명령어에 -b 라는 flag 를 추가.

프로젝트에 존재하는 모든 브랜치를 확인하고 싶다면 git branch 명령어를 입력

• Merging branches (브랜치 병합하기)
  git merge <branch-name>
  특정 브랜치에서 새로운 기능을 완벽하게 구현하고 테스트까지 완료한 시점이면, 기준이 되는 master 브랜치에 구현내용을 적용시켜야함.

• Deleting a branch (브랜치 삭제하기)
  git branch -d <branch-name>