Git & Github

Git

소스코드를 효율적으로 관리하기 위해 사용되는 버전 관리 시스템 VCS(Version Control System)이다. 여기서 version은 소스코드 파일의 version을 뜻 한다 (소스코드의 변경사항 내역을 관리하는 시스템) 참고로 소스코드란 코드 파일들을 말한다 server.js 같은 파일이 소스코드 이다.

VCS의 기능

• 코드 변경 사항 내역 기록 및 관리
• 필요시 이전 상태로 rollback
• 팀단위 개발시 체계적이고 효과적인 협업

Git Basics

• Committed
  수정 사항들이 git에 저장 된 상태를 "committed" 이라고 한다 (이러한 행위를 "commit" 한다고 함)

• Modified
  Modified file은 이름 그대로 수정된 file 이다 (아직 "commited" 되지 않은 상태의 file을 이야기 함)

• Staged
  Staged file은 modified file에서 한단계 더 나아가서 곧 commit 될거라고 mark 해놓은 상태이다. (modified 와 committed의 중간 상태)
  이렇게 중간 상태가 존재 하는 이유는, commit 하기전에 중간 상태를 저장할 수 있도록 하기 위함이다. Commit을 하면 commit history에 남기도 하고, 혹시 추가 수정 사항이 있거나 다시 되돌려야 할때 까다롭기 때문에 (commit 후에도 다시 되돌리는게 가능하긴 함) commit 전에 중간 상태에 저장할 수 있도록 하는 것이다. 즉, commit은 해당 개발이 완전 완료 됬을때 하는 것이기 때문에, 아직 완료는 안되었지만 그래도 중간 상태를 저장할 필요가 있을때 staging을 사용하는 것이다.

Git을 사용한 버전 관리의 flow

1. 소스코드 전체를 다운로드 받는다 (git repository를 checkout 한다)
2. 소스코드 파일들을 수정한다 (개발을 한다)
3. 수정한 파일들을 stage 한다
4. 계속 해서 소스코드 파일들을 수정해 나간다
5. 해당 작업이 완료될때까지, 즉 commit 할 준비가 될때까지, 3,4번을 반복한 후 완료되면 commit 한다

Basic Git Commands

• git init
  프로젝트를 git repository로 만들기 위해서 사용하는 명령어 이다. 여기서 프로젝트(project)라 함은 개발하고자 하는 소스코드들이 있는 디렉토리를 말한다. git init을 해서 git repo로 만들어야 git으로 버전 관리가 시작된다.

• git add
  수정 사항들, 즉 modified 파일들을 staged 상태로 옮기고자 할때 사용하는 명령어 이다. 또한, git repo에 새로이 추가된 파일들을 staged 상태로 옮길때도 사용된다. 새롭게 추가된 파일들은 "untracked" 파일 이라고 하는데, git에서는 이들도 수정 사항이라고 보는 것이다.

• git commit
  staged 된 파일들을 commit 하고자 할때 사용하는 명령어 이다.

• git diff
  어떤 수정 사항들이 적용됬는지 보고자 할때 사용하는 명령어 이다. 참고로 staged 된 수정 사항들은 git diff로 볼 수 없다. Modified 된 파일들만 git diff로 볼 수 있다.

• git status
  현재 상태를 보여주는 명령어 이다. 어떠한 파일들이 modified가 되었고 어떠한 파일들이 staged가 되었는지 등의 전체적인 상황을 보여준다.

• git log
  Commit 내역들을 보여준다. Commit history라고도 한다. git log를 통해 이제까지 커밋 내역들을 전부 볼 수 있다. 다만 출력되는 포맷이 보기가 쉽지가 않아서 tig 같은 tool을 사용하면 훨씬 편리하다.

• git rm
  원하는 파일을 git repo에서 삭제

• git mv
  원하는 파일을 git repo 상에서 이동 시킬때 사용하며 주로 rename 할때 사용 된다

• git branch
  Branch를 생성할 때 사용

• git checkout
  어떤 branch를 checkout 할때 사용되는 명령어

Branch & Merging

git을 사용할때는 branch 기반으로 개발하기 때문에 Git 에서 branch는 굉장히 중요한 컨셉이며 꼭 이해하는 컨셉이다. Git branch를 이해할려면 먼저 git이 어떻게 데이터 (수정사항들)을 저장하는지를 알아야 한다.

Git은 데이터를 단순한 변경사항(diff)으로 저장하지 않는다. Git은 파일의 스냅샷의 연속으로 저장한다. Git은 새로 commit이 들어오거나 프로젝트의 상태를 저장할 때마다 파일이 존재하는 그 순간을 중요하게 여긴다. 그래서 파일이 달라지지 않았으면 git은 빠른 성능을 위해서 파일을 새로 저장하지 않고 이전 상태의 파일에 대한 링크만 저장한다. 즉, 수정 사항만을 저장하는게 아니라 파일의 스냅샷(snapshot)을 시간순으로 저장하는 것이다.

그리고 변경사항을 볼때는 현재 스냅샷과 이전 스냅샷을 비교하여 변경사항을 볼 수 있는 것이다.

이렇게 스냅샷으로 저장되어 있기 때문에, 개발자가 central server에서 새로 repo를 checkout 받으면 해당 리포의 어느 특정한 시점의 (일반적으로 가장 최신) 스냅샷을 checkout 받는것이다.

그러면 여기서 질문이 생길 것이다. 개발자들이 각자 snapshot을 checkout 받아서 개발을 하면 어떻게 서로의 변경사항들을 조율을 할수 있을까? 즉 서로의 변경사항들을 합쳐서 새로운 최신 버전의 스냅샷을 만드는 과정이 필요한데, 문제는 어떤 스냅샷을 기준으로 변경사항들을 합치느냐 하는 문제가 생긴다.

그래서 이러한 문제를 해결하기 위해 branch를 사용한다. Branch는 나뭇가지 혹은 분점 을 뜻한다. 즉 기본이 되는 큰 줄기가 있고 그 줄기로 부터 옆으로 가지가 나는걸 뜻 한다. Git의 branch 모델이 바로 이러한 구조이다. 기준이 되는 스냅샷이 있다. (이 기준을 master branch라고 함) 각 개발자는 master branch를 checkout 먼저 하고, master branch로 부터 자신만의 branch를 만든다. 이걸 feature branch라고 한다. 그리고 feature branch를 기반으로 개발을 한 후 개발이 완료가 되고 commit을 하면 자신의 feature branch를 다시 master branch로 합하게 된다. 이렇게 합하는 과정을 merge 한다고 한다.

1. Matser branch를 check out 한다.
2. 자신만의 feature branch를 만든다.
3. Feature branch에서 개발을 한다.
4. 완료되면 commit 한다.
5. Master branch에 feature branch를 merge 한다.