[Git] Git 기초 개념 / 저장소 / 커밋 / 브랜치 / 작업 트리 / 인덱스 / 추적

< 깃(Git)을 배워야 하는 이유 >

* 파일을 편집 전 상태로 되돌리고 싶다면?
-> 편집하기 전에 파일을 미리 복사해둠(사본을 통한 관리). 파일과 폴더명 뒤에 편집한 날짜를 붙여줌. 
-> 파일이 별로 없는 단기, 소규모 프로젝트에서는 합리적.
-> 하지만 장기간, 대규모 프로젝트에서는 비효율적.

* 사본을 통한 관리의 단점
1) 파일 관리의 어려움 : 파일 편집시 매번 복사하는 건 번거로움, 실수할 가능성, 용량 차지
2) 버전 관리의 어려움 : 어느 파일이 최신인지, 파일의 변경된 지점이 어디인지 파악 어려움
3) 협업의 어려움 : 공유한 파일을 동시에 편집하는 경우 다른 사람의 변경 내용을 내가 지워버릴 수 있음.

=> Git이 이런 어려운 점들을 해결.

* Git : History(변경 이력)를 관리하는 도구
- 개발 과정과 소스 파일들이 언제 어떻게 변경되었는지 파악
- 깃으로 파일을 관리하면 업데이트 이력이 깃에 저장 -> 소스 코드가 변경된 이력 쉽게 확인 -> 버전 관리 용이
- 변경시마다 메세지 남김 -> 누가 어떻게 변경했는지, 왜 이런 작업을 했는지 파악 (=> 소스트리를 사용하면 변경 이력을 시각적으로 표현)
- 효율적인 백업 : 사본을 통해 관리하면 파일이 점점 늘어나서 용량 차지 많고, 파일간의 차이점도 제대로 확인할 수 없다는 문제점 -> 깃은 파일 업데이트시 차이점만 저장해서 결과적으로 저장되는 파일은 1개이며 버전간 비교 가능. 특정 이력으로 돌아가서 해당 파일의 내용 확인. 
- 서버에 저장한 내용이 누군가 편집한 내용과 충돌한다면 서버에 업로드할 때 경고 메세지가 발생 -> 차이점을 수정하고 나서야 제대로 된 업로드 가능

 

---

< 깃은 무엇인가, 저장소(지역/원격), 커밋 >

- 리누스 토르발스 : 리눅스 커널을 개발. 리눅스의 소스 코드를 관리할 목적으로 2005년에 Git을 개발.
- CLI(Command Line Interface) :  리눅스 기반으로 깃 명령어를 하나씩 입력하여 실행하는 방법으로 기능 사용.   
- GUI(Graphic User Interface) : 윈도우처럼 커서를 통해 조작하는 방식. ex) Sourcetree

* 깃은 소스코드의 효과적인 관리를 위해 개발된 분산형 버전관리 시스템
- 분산형 : 중앙에 통합된 원격 서버를 두고 각자 컴퓨터의 사본들의 충돌여부를 통합해서 관리
- 버전 관리 시스템 : 소스코드의 변경 이력을 저장 및 파일을 관리해주는 시스템
- 프로그래머가 작성한 소스코드를 압축해서 저장소에 저장해둔 다음, 변경 이력을 열람하거나 불러올 수 있도록 만든 것.

* 저장소(Repository) : 파일이나 폴더를 저장해두는 곳. 
- 변경 이력별로 구분되어 저장됨.
1) 원격 저장소(Remote Repository) : 파일이 원격 저장소 전용 서버에서 일괄 관리되는 저장소. 원격 저장소를 사용하면 여러 사람이 서버에 있는 하나의 저장소를 공유해서 공동 작업이 가능. 기본 설정된 원격 저장소 주소에는 origin이라는 별명을 붙임. 
2) 지역 저장소(Local Repository) : 개별 PC에 파일이 저장되는 개인 전용 저장소. 내 PC의 지역 저장소에서 작업 -> 원격 저장소에 업로드 & 타인의 작업 내용을 다운로드

* 커밋(Commit) 
- 어떤 순간 작업 공간의 상태를 저장한 것. -> 작업 공간 안에 있는 모든 파일과 파일의 데이터를 사진 찍듯이 복사해서 저장소에 보존
- 작업 공간의 어떤 시점의 스냅샷
- 커밋한다 = 커밋을 저장소에 추가한다 = 현재 작업 공간의 상태를 커밋으로 만들어 저장소에 저장한다
- 커밋하면 이전 커밋부터 현재 상태까지의 변경 이력이 기록된 커밋 생성
- 시간순으로 저장 -> 최근 커밋부터 거슬러 올라가면 과거 변경 이력과 내용을 알 수 있음.
- 하나의 커밋이 더해질 때 이전 커밋에서 변경된 사항만 추가 -> 커밋끼리는 서로 연결된 체인 구조를 형성 & 이전 커밋 훼손 시 이후 커밋도 망가짐

1) 커밋 해시(Commit Hash) : 각 커밋을 구분하는 식별자. 영문/숫자로 이루어진 40자리 고유 이름(Extended SHA-1 형식) => 저장소에서는 커밋 해시를 보고 각 커밋을 구분 및 선택함
2) 커밋 메세지(Commit Message) : 커밋 시 커밋 메세지 입력은 필수. 메세지가 없으면 커밋 실행 안 됨.

 

---

< 브랜치, 작업 트리, 인덱스, 추적 >

* 브랜치(Branch) 
- 원래 버전에서 갈라져 나온 것(가지) 
- 특정 커밋을 기준으로 원래의 버전에서 갈라져 나온 하나의 새로운 버전
- 각각의 브랜치는 다른 브래치의 영향을 받지 않음. -> 여러 작업을 동시에 진행 가능

* 마스터(Master)
- 처음에 저장소를 만들게 되면 기본으로 브랜치가 생성됨 -> 기본 설정된 브랜치에 붙는 이름이 마스터!
- 완성된 배포 버전이라는 의미도 있음

* HEAD : 지금 작업중인 브랜치(또는 커밋)를 가리키는 포인터.
- 브랜치 또는 커밋 간의 이동은 마치 폴더 간의 이동처럼 자유로움.
- 특정 버전을 조회하려면 브랜치 이름이나 커밋 해시를 기억하고 있어야 함.

* 작업 트리(Work Tree) = 작업 공간(Working Space)
- 개인 컴퓨터 환경에서 소스 코드를 편집하는 일반적인 프로젝트 폴더
- 브랜치 또는 커밋 단위로 헤드를 움직일 시에 작업 트리도 같이 변화하게 됨.

* 인덱스(Index)
- 커밋을 실행하기 전, 저장소와 작업 트리 사이에 존재하는 공간
- 커밋 작업시 작업 트리에 있는 변경 내용을 저장소에 바로 기록하는 것이 아니라 그 사이 공간인 인덱스에 파일 상태를 우선 기록
- 저장소에 변경 사항을 기록(=커밋)하려면 기록하고자 하는 모든 변경 사항들이 인덱스에 존재해야 함.

* 추적(Stage)
- 작업 공간에서 변경이 발생한 파일을 다음 커밋에 포함되도록 예약하는 것.
- 어떤 파일을 추적하면 그 파일을 스테이지되었다고 함 = 인덱스에 등록되었다는 것과 같은 말
- 추적 해제(Unstage) : 변경을 반영하고 싶지 않을 경우, 추적하던 파일을 스테이지에서 제외. 

* 정리
- 인덱스 = 스테이징 영역(Staging Area)
- 인덱스에 등록 = 추적(스테이지)
- 인덱스에서 제외 = 추적 해제(언스테이지)
- 인덱스가 작업 트리와 저장소 중간에 있음 -> 1) 커밋이 필요 없는 파일들을 포함하지 않을 수 있음. 2) 파일에서 내가 원하는 일부 변경사항만 인덱스에 등록해서 저장소에 커밋 가능

 

참고 : https://gmlwjd9405.github.io/2017/10/27/how-to-collaborate-on-GitHub-1.html

[GitHub] GitHub로 협업하는 방법[1] - Feature Branch Workflow - Heee's Development Blog