19.1 버전 관리 시스템이란
-
버전 관리 시스템을 사용하면 수동으로 백업하지 않아도 파일의 변경 이력을 관리할 수 있음.
-
파일을 언제, 누가, 무슨 목적으로, 어떤 변경을 했는가를 기록할 수 있고 확인할 수 있음
-
필요에 따라 과거의 특정 시점으로 파일을 복원할 수 있음
19.2 깃 설치와 초기 설정
-
git --version: 깃 설치 여부 확인 -
git config --global user.name 'ldk': 이름 설정 -
git config --global user.email 'ldk@example.com': 이메일 설정 -
cat ~/.gitconfig: 설정 내용을 확인한다.
19.3 기본적인 사용법
-
git init: 리포지터리 초기화-
초기화되어 .git이라는 디렉터리가 만들어진다.
-
.git 디렉터리가 깃 리포지터리의 실체이다.
-
-
리포지터리 : 깃이 관리하는 파일의 이력을 보존하는 공간
-
git add : 깃이 관리할 파일을 추가하는 명령어이다. 커밋 대상으로 등록한다.
-
git diff : 커밋 전/후 차이를 표시한다. +-로 표시됨.
-
git commit : 실제 리포지토리에 변경 이력을 추가하는 명령어이다.
-
git log : 변경 이력 표시
-
-m옵션 없이 git commit 하면 vim에디터가 실행된다. -
요약
빈칸
자세한 메시지
이 형식으로 작성한다.
-
-
git log : 리포지토리 커밋 이력 확인
-
commit으로 시작하는 행이 커밋 하나에 대한 정보가 시작되는 행이다.
-
이 행에는 40글자의 문자열이 포함되어있다.
-
커밋 오브젝트명으로 커밋 하나를 특정하기 위한 키에 해당한다.
-
그 다음 행부터는 저자, 변경 시점, 커밋 메시지가 표시된다.
-
git log --oneline: 한 줄에 보여준다. -
git log -p : 커밋별로 차이점을 함께 표시한다.
-
commit 명 밑에 +-표시로 차이점을 표시한다.
-
- : 해당 커밋 시의 파일 -
+ : 현재 작업 트리의 파일 -
git log --oneline으로 커밋 id만 출력 가능. -
git diff (commit객체 id): 해당 커밋의 변경 사항을 볼 수 있다. id 앞의 7자만 넣어도 식별 가능하다.
19.4 작업 트리와 인덱스
-
index(stage) : 작업 트리와 리포지토리 사이에 존재하는 공간이다. 작업 트리에서 인덱스에 파일을 등록하는 명령어가 add이다.
-
깃을 작업 트리에 있는 변경사항을 stage에 배치한다.
-
작업 트리와 stage는 내용이 일치하지 않을 수 있다. 파일 두 개를 수정한 뒤 파일 하나만 인덱스에 등록할 수 있다. add후 수정하면 수정본은 stage에 포함되지 않는다.
-
보관해야겠다 하면 commit을 한다.
-
git add는 여러 번 실행해도 된다. git diff로 작업 트리, stage, 리포지토리 간의 차이를 확인할 수 있다. git diff에 아무것도 지정하지 않으면 작업 트리와 stage의 차이를 표시한다.
-
---: stage에 있는 파일 -
+++: 작업 트리에 있는 파일 (최신)
아무것도 안 나오면 똑같다는 의미이다.
-
git diff 커밋 id: stage-커밋 비교 -
git diff: stage-add 비교 -
git diff --cached: stage 내용과 리포지토리 내용을 비교한다. 커밋 전 실제 커밋할 내용을 확인하기 위해 사용한다.인덱스-리포 비교 -
git diff HEAD: head는 리포에서 가장 최신 커밋 객체를 가리키는 포인터이다. -
---: 커밋된 파일 -
+++: 작업 트리에 있는 파일(최신)
19.5 커밋 단위와 인덱스
깃에서 작업 트리와 stage가 구분되어 있는 이유는 커밋 하나에 포함할 변경 사항을 선택할 수 있도록 하기 위해서이다.
커밋 하나에는 한 이슈와 관련된 수정 사항만 포함하는 것이 좋다.
버그 수정과 신기능 추가가 커밋 하나에 포함되어 있으면 나중에 변경사항을 추적하기 어려워진다. 따로 stage에 추가해 따로 커밋한다.
git add -u : git add를 한 번 했던 파일들을 한꺼번에 stage로 올린다. 새로 작성한 파일이 등록되지 않는다.
git add -A : 변경한 파일과 add를 한 번도 안했던 파일도 stage에 등록된다.
19.6 실수했을 때 복구하기
버전 관리 시스템을 사용하는 가장 큰 이점은 예전 상태로 쉽게 복원할 수 있다는 점이다.
아직 커밋하지 않았다면 작업 트리의 최상위로 이동하여 다음 이동 명령을 실행한다.
HEAD : 가장 최신 커밋 객체를 가리기는 포인터.
git checkout HEAD : 파일의 변경사항이 전부 복원되며 stage에 추가한 내용도 전부 사라진다. 리포와 동일한 상태가 된다.
커밋하지 않은 작업 내용이 사라지므로 git diff로 확인한 뒤 수행해야 한다.
git revert : 리포지토리에 복원을 위한 커밋 객체가 추가되고, 복원 작업이 트리에도 적용 revert하는순서는 최신 커밋부터 차례대로 하는 것이 좋다.
git revert <이전 커밋 id>…<최신 커밋 id> : 한꺼번에 최신 커밋부터 차례대로 revert할 수 있다.
git revert로 커밋 이력에서 지워지지 않는다. 커밋의 변경 사항을 복구하는 커밋이 하나 더 생긴다. 변경사항을 수정하여 수동으로 커밋하는 것과 동일한 작업을 수행한다.
git revert 실행하면 일반 커밋 할 때와 같이 커밋 로그를 입력하는 에디터가 실행된다.
커밋 로그를 입력하고 종료하면 새로운 커밋이 생성된다.
19.7 브랜치
소프트웨어 개발은 보통 병렬로 진행한다.
새로운 기능을 개발하면서 기존 코드의 버그를 수정하는 일이 동시에 진행된다.
이때 서로 관계가 없는 작업을 전혀 다른 공간에서 진행하면 좋다.
많은 버전 관리 시스템이 리비전 하나에서 복수의 커밋이 파생하는 것을 지원한다.
브랜치에는 이름을 붙일 수 있다.
브랜치란 분기되어 갈라진 이력의 선두에 있는 커밋을 가리키는 라벨이다.
master 브랜치가 프로젝트의 기본이다.
git branch featuer-name : feature-name 이라는 이름의 브랜치를 생성한다.
git branch : 브랜치 목록 확인. 현재 브랜치에 *표시
git checkout <전환할 브랜치> : 브랜치 전환
새로운 브랜치에서 커밋을 수행하면 현재 브랜치가 새로운 커밋을 가리키게 된다.
새 브랜치에서 작업한 내용에 문제가 없다고 판단하면 master 브랜치에 반영할 수 있다.
merge : 한 브랜치의 내용을 다른 브랜치에 반영하는 것
a 브랜치 내용을 b 브랜치로 머지하려면 b브랜치로 전환해야 한다.
git merge <머지할 브랜치 이름> : 머지할 브랜치를 현재 브랜치와 머지한다. 이때 커밋 메시지를 남길 수 있다.
브랜치를 사용하면 서로 다른 작업을 병렬로 진행한 뒤에 머지할 수 있다.
토픽 브랜치 : 한 가지 기능을 추가하기 위해 만든 브랜치
작업을 진행할 때는 언제나 토픽 브랜치를 만들어 진행한 후 master에 머지하는 것이 좋다.
언제든 작업 개시 전의 상태로 돌아갈 수 있기 때문
git branch -D : 아직 머지하지 않은 브랜치 강제로 삭제
19.8 리포지터리의 백업 작성
여러 리포지터리를 만들어 이력을 공유하는 것이 가능하다.
백업용 리포지터리를 만들고 작업 이력을 복사할 수 있다.
git init : 리포 생성
git --bare init : 백업용 리포 생성. 작업 영역 없이 리포지터리만 생성함
작업 중이던 리포에서 git push <전달받을 리포지터리> <이력을 보낼 브랜치>:<전달받을 브랜치> : 커밋 이력 전송할 때는 git push 명령어를 사용한다.
19.9 2인 이상의 작업
19.10 충돌 해결
19.11 깃 매뉴얼
