Commit이란 어떠한 포인트에서 형상을 기록하는 것

그래서 Commit을 실행하기 전에, 어떠한 코드, 어떠한 파일들을 형상으로 기록할 지 선별하는 작업을 수행해야 한다.

SVN의 Commit 과는 전혀 다른 기능이다.
SVN의 Revision 이라고 생각하면 된다.

선별 작업

Tracked Changes

• 어떠한 파일(디렉터리)가 형상으로 등록되면, 그 이후부터 Git에서는 해당 파일(디렉터리)을 Tracking하기 시작한다.
• 이렇게 Tracking 하고 있는 파일(디렉터리) 중에서 수정사항이 발생한 목록을 의미한다.
• 보통은 파일(디렉터리) 수정/이동/삭제된 경우에 해당

Untracked List

• 형상 등록이 되지 않은 파일(디렉터리) 목록
• 보통은 파일(디렉터리) 추가된 경우에 해당

Stage

• Commit 수행 시 형상으로 기록할 파일이나 코드 등의 리스트
• Tracked changes, untracked list에서 형상으로 기록할 것들을 선별하여 Stage로 이동시킴

관련 명령어

• add
• del
• commit
• rm
• status
• tag

add

### Add to stage ###
# Tracked changes와 Untracked list의 특정 파일(디렉터리)를 Stage에 추가
$ git add [files or dirs]

# Tracked changes와 Untracked list의 모든 파일(디렉터리)를 Stage에 추가
$ git add -A

del

### Delete from stage ###
# Stage에 있는 특정 파일(디렉터리)를 Stage에서 제외
$ git del [files or dirs]

# Stage에 있는 모든 파일(디렉터리)를 Stage에서 제외
$ git del -A

commmit

### Restore stage ###
$ git commit

커맨드를 실행하면, 에디터가 실행되면서 Commit 메세지를 작성하는 화면으로 자동 전환됩니다.

이 때 실행되는 에디터는 Repo config의 core.editor에 설정된 에디터임

메시지를 모두 작성한 후, 에디터를 종료하면 Commit 완료

Commit 메세지를 작성하는 방법은 뒤에서 다룰 예정.

Commit이 완료되면 History가 기록되는데, $ git log 커맨드로 확인할 수 있다.

또한 각 Commit마다 Commit number가 부여되는데 이 또한 log 커맨드로 확인할 수 있다(빨간색 화살표).

rm

### Remove from tracked list
# 특정 파일(디렉터리)를 Tracked list에서 제외시킴과 동시에 삭제
$ git rm [files or dirs]

# 특정 파일(디렉터리)를 Tracked list에서 제외만 시키고 삭제는 하지 않음
$ git rm --cached [files or dirs]

status

### Check unstaged list ###
$ git status
# Staged files
Changes to be committed:
			deleted:    file_a

# Tracked changes
Changes not staged for commit:
			modified:   file_b

# Untracked list
Untracked files:
			file_c
			file_d

tag

# Register tag
$ git tag <tag-name>

# Example
$ git tag v0.0.0

# Check tags
$ git tag

특정 Commit 포인트에서 Tag를 남길 수 있다.

보통은 버전명을 기록할 때 사용된다.

Commit Rule

$ git commit 을 실행하면, Commit 메세지를 작성해야 한다.

각자 환경에 맞게 작성하면 되지만, 일단 먼저 Global conventional commit rule을 소개하고자 한다.

Global conventional commit rule

기본 틀은 다음과 같다.

type : title

body(생략 가능)

footer(생략 가능)

• type

  Commit의 타입을 정의한다. 이 커밋룰에서 정의한 목록은 다음과 같다.

  • feat : 새로운 기능에 대한 커밋
  • fix : 버그 수정에 대한 커밋
  • build : 빌드 관련 파일 수정에 대한 커밋
  • chore : 그 외 자잘한 수정에 대한 커밋
  • ci : CI 관련 설정 수정에 대한 커밋
  • docs : 문서 수정에 대한 커밋
  • style : 코드 스타일 또는 포맷 등에 대한 커밋
  • refactor : 코드 리팩토링에 대한 커밋
  • test : 테스트 코드 수정에 대한 커밋

• title

  Commit의 제목을 정의한다.

• body

  필요 시 본문 및 세부 내용을 명시한다.

  또한 생략 가능하다.

• footer

  사족을 남긴다.

  생략도 가능하다.

  하지만 보통 해당 Commit과 연관된 Issue tracker ID를 명시한다.

  • close #

    일감이 완료되었음을 나타냄

  • resolved #

    이슈가 해결되었음을 나타냄

  • refs #

    현재 진행 중인 일감(or 이슈)를 나타냄

  • related to # # #...

    관련 일감들을 나타냄(복수 지정 가능)

이 Rule에서 정의하는 7가지 규칙은 다음과 같다.

• title 과 body 는 빈 행으로 구분한다.
• title 은 50자 이내로 제한한다.
• title 첫 글자는 대문자로 작성한다.
• title 끝에 마침표를 넣지 않는다.
• title 은 명령문으로 사용하며 과거형을 사용하지 않는다.
• body 의 각 행은 72글자 내로 제한한다.
• 어떻게 보다는 무엇과 왜를 설명한다.

예시는 다음과 같다.

fix : Segmentation fault 현상 해결

For문에서 배열의 최대 인덱스를 초과하여 접근했던 것을 수정
   - main.c 723줄 참고

resolved #4431

Ignore File

이름 그대로 Git에서 아예 신경을 쓰지 않아도 될 파일 목록을 명시할 수 있다. 이 파일에 명시된 파일들은 $ git status 명령어를 실행되면 출력되는 Untracked files 에도 제외된다.

Ignore file은 Git repo에서 .gitignore 파일을 생성하고, 무시할 파일(디렉터리) 리스트를 파일에 작성하면 된다. 각각 개행으로 구분해준다.

표준양식으로 Glob 패턴을 사용한다.

리스트 중에 무시를 취소하고 싶은 게 있다면, 삭제하거나 맨 앞에 #을 추가해준다.

Github standard

C, Jave 등 각 코드 포맷마다 컴파일 등 작업 시 생성되는 부산물들(바이너리 등)이 존재한다. 하지만, 형상관리는 코드 관리를 주로 하기 때문에 이러한 부산물들은 필요없는 존재이다.

그래서 Github에서는 각 코드 포맷 별 Ignore file을 정의하여 제공한다. 그래서 보통 여기서 제공하는 Ignore file을 바탕으로 각자의 환경에 맞게 커스텀하여 사용한다.

Github 양식을 사용하려면 다운로드 받아서 이름을 .gitignore 로 변경하면 된다.

github/gitignore

C.gitignore

# Prerequisites
*.d

# Object files
*.o
*.ko
*.obj
*.elf

# Linker output
*.ilk
*.map
*.exp

# Precompiled Headers
*.gch
*.pch

# Libraries
*.lib
*.a
*.la
*.lo

# Shared objects (inc. Windows DLLs)
*.dll
*.so
*.so.*
*.dylib

# Executables
*.exe
*.out
*.app
*.i*86
*.x86_64
*.hex

# Debug files
*.dSYM/
*.su
*.idb
*.pdb

# Kernel Module Compile Results
*.mod*
*.cmd
.tmp_versions/
modules.order
Module.symvers
Mkfile.old
dkms.conf