본 포스트는 책 모두의 깃&깃허브를 읽고 작성되었습니다.
앞선 글에서 Git은 원활한 버전관리를 위한 DVCS의 일종이라고 소개 했었다.
그렇다면 버전 관리란 무엇일까
이를 이해하기 위해선 local에서 git이 관리하는 세가지 공간(working directory, stage, local repository)을 먼저 이해해야 한다.
Local repository와 Working directory
Local repository를 생성하면, repository의 이름과 같은 폴더가 생성된다. 이때 폴더는 크게 Local repository와 Working directory로 나뉘게 된다.
Working directory는 버전 관리의 대상인 파일들이 위치하는 공간으로, 세가지 공간 중 유일하게 사용자에게 명시적으로 보이는 공간이다. Local repository를 생성한 폴더 중, 사용자가 직접 수정할 수 있는 영역이라고 정의할 수 있다.
Local repository는 Local repository를 생성한 폴더 내부의 위치한 .git이라는 숨김 폴더 안에 존재한다. 다만 해당 영역은 직접 수정이 불가능하며, Git 명령어를 통해 간접적으로 관리된다.
Stage와 Add
Working directory에서 파일을 추가, 수정, 삭제하면, 이전에 저장된 버전과의 변경사항이 발생한다. 이때, 발생한 변경사항 중 새로운 버전에 포함시키고 싶은 파일을 선별하여 특별한 공간에 옮기게 된다. 이를 Stage 또는 Staging Area라고 한다.
+) 만일 버전에 절대 포함하고 싶지 않은 파일이 있는 경우, .gitignore 파일(무시할 파일 또는 폴더명 목록)에 추가한다. 그러면 얼마나 변경하든 자동으로 무시된다.
Commit을 통한 버전 생성
Stage에 파일들이 존재한다면, 이를 Commit 하여 새로운 버전을 만들 수 있다.
하나의 Commit은 종종 하나의 버전을 뜻하기도 한다. 따라서 한 커밋은 하나의 논리적 작업단위를 나타내야 하며, 불필요한 파일이나 디버그용 코드는 포함하지 않도록 한다.
git commit "commit message"라는 명령어를 통해 Commit이 이루어진다.
Commit시에는 다음과 같은 메세지 규칙을 따른다(해당 포스트 참조).
Commit 메세지 규칙
- 제목과 본문을 빈 행으로 구분
- 제목은 50글자 이내로 제한
- 제목의 첫글자는 대문자로 작성
- 제목에는 마침표를 넣지 않음
- 제목은 명령문으로 작성하며, 과거형은 사용하지 않음
- 본문의 각 행은 72자 이내로 제한
- How 보다는 Why에 집중
다음은 규칙을 준수한 Commit 메세지의 format이다.
// 제목 앞에 type을 명시하여 commit의 성격을 알린다.
<type> : <제목> // header, 생략 불가
<본문 (선택)> // body, 생략 가능
<꼬리말 (선택)> //footer, 생략 가능commit 메세지에는 다음과 같은 type을 사용할 수 있다
| type | 설명 |
|---|---|
| feat | 새로운 기능 추가 |
| perf | 성능 개선 |
| fix | 버그 수정 |
| docs | 문서 수정 (README, 주석 등) |
| style | 코드 스타일 변경 (포맷팅, 세미콜론 수정 등; 기능 변경 없음) |
| refactor | 코드 리팩토링 (기능 변경 없음) |
| test | 테스트 추가 또는 수정 |
| build | 프로젝트의 빌드 시스템(컴파일, 패키징 등)이나 외부 의존성 관리와 관련된 변경 사항 |
| chore | 기타 변경 사항 (프로젝트의 기능이나 코드 동작에 직접적으로 영향을 미치지 않는 유지보수성 작업) |
| ci | ci(코드 병합 및 병합된 코드 테스트) 관련 설정 수정 |
| cd | cd(ci 이후 단계를 포함해 코드가 production 환경에 배포되는 과정) 관련 설정 수정 |
