[GitHub] ProGit 요약 - 1. 시작하기

이 장에서 배우는 것

Git 초보자를 위한 내용 설명

Git 이해, 설치, 서버 설정 및 사용법 설명

Git의 배경, 사용 이유, 설정 및 사용법 이해 가능

 

목차

1.1 버전 관리란?

1.2 짧게 보는 Git의 역사

1.3 Git 기초

1.4 CLI

1.5 Git 설치

1.6 Git 최초 설정

1.7 도움말 보기

1.8 요약

 

---

1.1 버전 관리란?

버전 관리 시스템이란?

• 파일 변화를 시간에 따라 기록하고 특정 시점의 버전을 꺼내올 수 있는 시스템
• 이 책에서는 소프트웨어 소스 코드 예시로 버전 관리 설명, 실제로 거의 모든 컴퓨터 파일의 버전을 관리 가능

 

버전 관리란?

• 버전 관리 시스템은 파일 변화를 시간에 따라 기록하고 특정 시점의 버전을 꺼내올 수 있는 시스템
• 이 책에서는 소프트웨어 소스 코드 예시로 버전 관리 설명, 실제로 거의 모든 컴퓨터 파일의 버전을 관리 가능
• 그래픽 디자이너나 웹 디자이너도 VCS 사용 가능
• VCS로 이미지나 레이아웃의 버전 관리 현명
• VCS 사용 시 각 파일 이전 상태로 되돌리기, 프로젝트 이전 상태로 되돌리기, 시간에 따른 수정 내용 비교, 이슈 추적, 잃어버린 파일 복구 등 각종 장점 제공
• VCS 사용 시 손쉽게 이용 가능

 

로컬 버전 관리

• 사람들은 버전 관리를 위해 파일 복사를 사용한다
• 이 방법은 간단하지만 잘못될 위험이 있다
• 프로그래머들은 이런 이유로 로컬 VCS를 만들었다. 이 VCS는 간단한 데이터베이스를 사용해 파일 변경 정보 관리했다.

그림 1. 로컬 버전 관리.

• RCS(Revision Control System)는 아직까지 많은 회사에서 사용 중
• RCS는 기본적으로 Patch Set(파일의 변경 부분)을 관리
• Patch Set은 특정 형식의 파일로 저장되고, 일련의 Patch Set을 적용해 특정 시점으로 파일을 되돌릴 수 있다.

 

중앙집중식 버전 관리(CVCS)

• 중앙집중식 VCS(CVCS)는 다른 개발자와 함께 작업할 때 발생하는 문제를 해결하기 위해 개발된 시스템
• CVS, Subversion, Perforce 등은 중앙 서버가 있고 클라이언트가 중앙 서버에서 파일을 Checkout해 사용
• 이러한 시스템들은 수년간 사랑을 받았다.

 

그림 2. 중앙집중식 버전 관리(CVCS).

 

장점

• 모두가 작업 상황을 알 수 있고 관리자는 작업을 꼼꼼하게 관리할 수 있다.
• 모든 클라이언트의 로컬 데이터베이스를 관리하는 것보다 VCS 하나를 관리하기가 쉽다.

 

단점

• 중앙 서버가 다운되면 아무도 협업을 할 수 없고 작업 내용을 백업할 방법도 없다.
• 중앙 데이터베이스가 있는 하드디스크에 문제가 생기면 프로젝트의 모든 히스토리를 잃게 된다.

 

분산 버전 관리 시스템

• DVCS는 클라이언트가 저장소 전체를 복제함으로써 서버에 문제가 생기더라도 작업을 시작할 수 있게 한다.
• Clone은 모든 데이터를 가진 진정한 백업이다.

 

그림 3. 분산 버전 관리 시스템(DVCS).

• DVCS는 리모트 저장소가 존재하고, 이를 이용해 다양한 그룹과 방법으로 협업이 가능하다.
• DVCS는 계층 모델 같은 중앙집중식 시스템으로는 할 수 없는 워크플로를 제공한다.

 

---

1.2 짧게 보는 Git의 역사

1. Git은 갈등 속에서 시작된다.
2. Linux 커널은 굉장히 규모가 큰 오픈소스 프로젝트이며, Patch와 압축 파일로 관리되었다.
3. 2002년부터 Linux 커널은 BitKeeper라는 DVCS를 사용한다.
4. 2005년에 BitKeeper의 무료 사용이 재고되었고, 이 사건은 Linux 개발 커뮤니티가 자체 도구를 만드는 계기가 됐다.
5. Git은 이를 기초로 아래와 같은 목표를 세웠다.
   1. 빠른 속도
   2. 단순한 구조
   3. 비선형적인 개발(수천 개의 동시 다발적인 브랜치)
   4. 완벽한 분산
   5. Linux 커널 같은 대형 프로젝트에도 유용할 것(속도나 데이터 크기 면에서)
6.  Git은 2005년에 생긴 DVCS로 초기 목표를 유지하고 있으며, 쉽게 사용할 수 있게 진화하고 성숙해졌다.
7. Git은 대형 프로젝트에 적합하며, 동시다발적인 브랜치에도 끄떡 없는 슈퍼 울트라 브랜칭 시스템이다(Git 브랜치 참고).

 

Git - 브랜치란 무엇인가

 

---

1.3 Git 기초

Git의 핵심은 뭘까?

• Git은 이해하는 것이 중요하고, 이를 이해하기 위해서는 다른 VCS의 개념을 버리고 Git의 차이점을 이해해야 한다.
• Git은 사용자 인터페이스가 비슷하다.
• Git은 미묘하게 달라서 다른 VCS에서 쓰던 개념으로는 헷갈리며, 정보를 취급하는 방식이 다르다.
• 이런 차이점을 이해하면 사용하기 쉬워진다.

 

차이가 아니라 스냅샷

• Subversion과 Subversion과 유사한 VCS 시스템들은 관리하는 정보가 파일 목록이다.
• CVS, Subversion, Perforce, Bazaar 등의 시스템은 각 파일의 변화를 시간 순으로 관리하면서 파일들의 집합을 관리한다.
• 이를 보통 델타 기반 버전관리 시스템이라 한다.
• Git은 데이터를 취급하는 방법이 Subversion 등과 다르다.

그림 4. 각 파일에 대한 변화를 저장하는 시스템들.

 

• Git은 데이터를 파일 시스템 스냅샷의 연속으로 취급한다.
• Git은 커밋하거나 프로젝트의 상태를 저장할 때 파일의 존재 상태를 중요하게 여긴다.
• Git은 성능을 위해 파일이 달라지지 않았을 경우 새로 저장하지 않고 이전 상태의 파일에 대한 링크만 저장한다.
• Git은 데이터를 스냅샷의 스트림처럼 취급한다.

그림 5. 시간순으로 프로젝트의 스냅샷을 저장.

 

• Git은 강력한 도구를 지원하는 작은 파일 시스템이다.
• Git 브랜치에서 설명할 Git 브랜치를 사용하면 이득이 있다.

Git - 브랜치란 무엇인가

 

 

거의 모든 명령을 로컬에서 실행

• Git은 네트워크의 속도와 관계 없이 빠르게 작동한다.
• Git은 로컬 파일과 데이터만을 사용하기 때문에 네트워크가 필요 없다.
• Git의 속도는 다른 CVCS에 비해 놀라울 정도로 빠르다.
• Git은 모든 히스토리가 로컬 디스크에 저장되기 때문에 모든 명령이 순식간에 실행된다.
• Git은 히스토리를 조회할 때 서버 없이 조회한다.
• Git은 파일의 현재 버전과 한 달 전의 상태를 로컬에서 비교할 수 있다.
• Git은 예전 버전의 파일을 찾기 위해 리모트에 있는 서버에 접근할 필요가 없다.
• Git은 오프라인 상태 및 VPN에 연결하지 않아도 작업할 수 있다.
• Git은 로컬에서 커밋할 수 있기 때문에, 다른 VCS 시스템과는 달리 오프라인 상태에서도 작업이 가능하다.

 

Git의 무결성

• Git은 체크섬을 사용하여 파일을 관리한다.
• 체크섬(checksum)은 어떤 값이나 정보가 손실되지 않는지 검증하기 위해 사용되는 수치 값이다.
• Git은 체크섬을 이해하지 않으면 파일을 변경할 수 없다.
• Git은 SHA-1 해시를 사용하여 체크섬을 생성한다.
• 체크섬의 예) 24b9da6552252987aa493b52f8696cd6d3b00373
• Git은 파일을 이름으로 저장하지 않고, 해시값으로 저장한다.

 

Git은 데이터를 추가할 뿐

• Git은 데이터를 삭제하지 않고 추가만 한다.
• Git은 커밋하지 않으면 변경사항을 잃을 수 있다.
• 그러나, Git은 일단 커밋하고 나면 데이터를 잃어버리기 어렵다.
• 되돌리기를 보면 Git에서 데이터 손실을 복구하는 방법을 알 수 있다.

 

세 가지 상태

Git은 파일을 Commited, Modified, Staged 이렇게 세 가지 상태로 관리한다.

• Committed란 데이터가 로컬 데이터베이스에 안전하게 저장됐다는 것을 의미한다.
• Modified는 수정한 파일을 아직 로컬 데이터베이스에 커밋하지 않은 것을 말한다.
• Staged란 현재 수정한 파일을 곧 커밋할 것이라고 표시한 상태를 의미한다.

위 세 가지 상태는 Git 프로젝트의 세 가지 단계(Git 디렉토리, 워킹 트리, Staging Area)와 연결되어 있다.

 

그림 6. 워킹 트리, Staging Area, Git 디렉토리.

• Git 디렉토리는 Git이 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳이다. 다른 컴퓨터에 있는 저장소를 Clone 할 때 Git 디렉토리가 만들어진다.
• 워킹 트리는 프로젝트의 특정 버전을 Checkout 한 것이다. Git 디렉토리는 지금 작업하는 디스크에 있고 그 디렉토리 안에 압축된 데이터베이스에서 파일을 가져와서 워킹 트리를 만든다.
• Staging Area는 Git 디렉토리에 있다. 단순한 파일이고 곧 커밋할 파일에 대한 정보를 저장한다. Git에서는 기술용어로는 “Index” 라고 하지만, “Staging Area” 라는 용어를 써도 상관 없다.

 

Git으로 하는 일은 기본적으로 아래와 같다.

1. 워킹 트리에서 파일을 수정한다.
2. Staging Area에 파일을 Stage 해서 커밋할 스냅샷을 만든다. 모든 파일을 추가할 수도 있고 선택하여 추가할 수도 있다.
3. Staging Area에 있는 파일들을 커밋해서 Git 디렉토리에 영구적인 스냅샷으로 저장한다.

Git 디렉토리에 있는 파일들은 Committed 상태이다. 

파일을 수정하고 Staging Area에 추가했다면 Staged이다.

Checkout 하고 나서 수정했지만, 아직 Staging Area에 추가하지 않았으면 Modified이다.

Git의 기초에서 이 상태에 대해 좀 더 자세히 배운다. 특히 Staging Area를 이용하는 방법부터 아예 생략하는 방법까지도 설명한다.

Git - Git 저장소 만들기

 

---

1.4 CLI

• Git을 사용할 수 있는 방법: CLI, GUI
• 이 책에서는 Git CLI 사용법을 설명함
• GUI는 Git 기능 중 일부만 구현하기 때문에 비교적 단순함
• CLI를 사용할 줄 알면 GUI도 사용 가능, 그러나 반대는 성립하지 않음
• 이 책에서는 Mac의 Terminal과 Windows의 CMD, Powershell을 사용함

 

---

1.5 Git 설치

하단 링크 참조

Git - Git 설치

 

---

1.6 Git 최초 설정

Git을 설치하고 나면 Git의 사용 환경을 적절하게 설정해 주어야 한다. 환경 설정은 한 컴퓨터에서 한 번만 하면 된다. 설정한 내용은 Git을 업그레이드해도 유지된다. 언제든지 다시 바꿀 수 있는 명령어도 있다.

'git config’라는 도구로 설정 내용을 확인하고 변경 가능하다. 사용하는 설정 파일은 아래 세 가지다.

1. /etc/gitconfig 파일: 시스템의 모든 사용자와 모든 저장소에 적용되는 설정. git config --system 옵션으로 이 파일을 읽고 쓸 수 있다. (이 파일은 시스템 전체 설정파일이기 때문에 수정하려면 시스템의 관리자 권한이 필요하다.) 
2. ~/.gitconfig, ~/.config/git/config 파일: 특정 사용자에게만 적용되는 설정. git config --global 옵션으로 이 파일을 읽고 쓸 수 있다. 특정 사용자의 모든 저장소 설정에 적용된다.
3. .git/config 파일: 특정 저장소에만 적용되는 설정. --local 옵션을 사용하면 이 파일을 사용하도록 지정할 수 있다. 하지만 기본적으로 이 옵션이 적용되어 있다. (당연히, 이 옵션을 적용하려면 Git 저장소인 디렉토리로 이동 한 후 적용할 수 있다.)

 

 

• 설정은 우선순위가 있어서 .git/config가 가장 우선시 된다.
• (확인 필요)Windows에서는 $HOME/.gitconfig 파일과 /etc/gitconfig 파일을 찾는다. /etc/gitconfig 경로는 아마도 MSys 루트의 상대경로일 텐데, MSys 루트는 인스톨러로 Git을 Windows에 설치할 때 결정된다.
• (확인 필요)'Git for Windows' 2.x 버전에서는 Windows XP 사용자는 C:\Documents and Settings\All Users\Application Data\Git\config 디렉토리에서 찾고 Windows Vista 이후 버전 사용자는 C:\ProgramData\Git\config 에서 찾을 수 있다.
• 시스템 설정 파일의 경로는 git config -f <file> 명령으로 변경할 수 있으며, 관리자 권한이 필요하다.

 

사용자 정보

• Git 설치 후 가장 먼저 사용자 이름과 이메일 주소를 설정해야 한다.
• Git은 커밋할 때마다 사용자 이름과 이메일 주소를 사용한다.
• 한 번 커밋한 후에는 사용자 이름과 이메일 주소를 변경할 수 없다.

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

• --global 옵션으로 설정하는 것은 딱 한 번만 하면 된다.
• 만약 프로젝트마다 다른 이름과 이메일 주소를 사용하고 싶으면 --global 옵션을 빼고 명령을 실행한다.
• GUI 도구들은 처음 실행할 때 이 설정을 묻는다.

만약 로그인한 계정을 바꾸고 싶을 때?

[GitHub] Git Bash에서 로그인한 계정 변경하는 법

 

편집기

• Git을 설치한 후 사용할 텍스트 편집기를 설정할 수 있다. 기본적으로 Git은 시스템의 기본 편집기를 사용한다.
• Emacs, notepad++ 등 다른 텍스트 편집기를 사용할 수 있다.

$ git config --global core.editor emacs

• Windows 사용자는 실행파일의 전체 경로를 설정해주어야 한다.

$ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -nosession"

• 64비트 Windows 시스템에서 32비트 Notepad++을 설치한 경우 설치 경로가 C:\Program Files (x86)에 있을 수 있다. 이 경우에는 적절히 수정해주어야 한다.

$ git config --global core.editor "'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -nosession"

 

설정 확인

• git config --list 명령을 실행하면 설정한 모든 것을 보여주어 바로 확인할 수 있다.

$ git config --list
user.name=John Doe
user.email=johndoe@example.com
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto
...

• Git은 같은 키를 여러 파일(/etc/gitconfig 와 ~/.gitconfig 같은)에서 읽기 때문에 같은 키가 여러 개 있을 수도 있다. 그러면 Git은 나중 값을 사용한다.
• git config <key> 명령으로 Git이 특정 Key에 대해 어떤 값을 사용하는지 확인할 수 있다.

$ git config user.name
John Doe

 

NOTE
Git이 설정된 값을 읽을 때 여러 파일에서 동일한 키에 대해 다른 값을 설정하고 있을 수 있다. 값이 기대한 값과 다를 수 있는데 값만 보고 쉽게 그 원인을 찾을 수 없다. 이 때 키에 설정된 값이 어디에서 설정되었는지 확인할 수 있는데 다음과 같은 명령으로 어떤 파일로부터 설정된 값인지를 확인할 수 있다.

$ git config --show-origin rerere.autoUpdate
file:/home/johndoe/.gitconfig	false

 

---

1.7 도움말 보기

다음 두 방법으로 명령어 도움말을 볼 수 있다.

$ git help <verb>
$ man git-<verb>

 

예) git config 명령

$ git help config

 

각 명령에서 사용할 수 있는 옵션들에 대해 간략히 살펴보는 방법: -h, --help 옵션 사용

$ git add -h
usage: git add [<options>] [--] <pathspec>...

    -n, --dry-run         dry run
    -v, --verbose         be verbose

    -i, --interactive     interactive picking
    -p, --patch           select hunks interactively
    -e, --edit            edit current diff and apply
    -f, --force           allow adding otherwise ignored files
    -u, --update          update tracked files
    -N, --intent-to-add   record only the fact that the path will be added later
    -A, --all             add changes from all tracked and untracked files
    --ignore-removal      ignore paths removed in the working tree (same as --no-all)
    --refresh             don't add, only refresh the index
    --ignore-errors       just skip files which cannot be added because of errors
    --ignore-missing      check if - even missing - files are ignored in dry run
    --chmod <(+/-)x>      override the executable bit of the listed files

 

---

1.8 요약

우리는 Git이 무엇이고 지금까지 사용해 온 다른 CVCS와 어떻게 다른지 배웠다. 시스템에 Git을 설치하고 사용자 정보도 설정했다. 다음 장에서는 Git의 사용법을 배운다.