티스토리 뷰

앞서 git을 정리하면서 git ignore와 git reset을 그냥 넘어갔다.

 

짚고 넘어갈 내용이 많아서 챕터를 빼서 정리해보려고한다.

파일 무시하기(gitignore)

Git Working Directory 아래에서 작업을 하다보면 의도하지 않은 파일이 생성되어 Untraked 상태로 나타나게 된다.

보통 로그 파일이나 빌드 시스템이 자동으로 생성한 파일이 그렇다.

 

이러한 경우 .gitignore 파일을 이용해 해당 파일을 자동으로 무시하도록 설정할 수 있다.

 

.gitignore 파일의 경우 다음과 같은 규칙을 따른다.

## '#'로 시작하는 라인은 무시한다.

## 애스터리스크(*)는 문자가 하나도 없거나 하나 이상을 의미
## [abc]는 중괄호 안에 있는 문자 중 하나를 의미
## 물음표(?)는 문자 하나를 의미
## [0-9] 캐릭터 사이에 하이픈(-)은 두 캐릭터 사이에 있는 문자 하나를 의미
## 에스터리스크 2개를 사용해 디렉토리 안의 디렉토리 지정 가능 a/**/z는 a/z, a/b/z, a/b/c/z 등을 모두 포함

## 슬래시(/)로 시작하면 하위 디렉토리에 적용되지(Recursivity) 않는다.
## 디렉토리는 슬래시(/)를 끝에 사용하는 것으로 표현한다.
## 느낌표(!)로 시작하는 패턴의 파일은 무시하지 않는다.

# 확장자가 ".o"나 ".a"인 파일 무시
*.[oa]

# ~로 끝나는 모든 파일 무시
*~

# 확장자가 .a인 파일 무시
*.a

# 윗 라인에서 확장자가 .a인 파일은 무시하게 했지만 lib.a는 무시하지 않음
!lib.a

# 레포지토리 내의 모든 file.c 파일 무시
file.c

# 현재 폴더의 TODO 파일 무시
/TODO

# build/ 디렉토리에 있는 모든 파일 무시
build/

# doc 폴더의 *.txt 파일 무시
## recursive 하지 않음. doc/server/arch.txt는 무시되지 않음
doc/*.txt

# doc 디렉토리 아래의 모든 .pdf 파일 무시
doc/**/*.pdf

.gitignore에서 주의할 점은, 한번이라도 push된 파일에 대해서는 적용할 수 없다는 것이니 올리지 않을 파일들은 미리미리 등록하도록 하자.

 

자세한 정보는 gitignore 공식페이지에서 확인

git reset

git reset은 명령어 하나로 퉁치기엔 내용이 너무 중요하다.

 

git 명령어의 대부분은 삭제하는 기능을 제공하진 않는데, 일부 git reset의 옵션이 삭제하는 기능을 갖고있기 때문이다.

 

git reset의 기본 목적은 작업을 하다보면 되돌리는(Undo) 기능이다. git을 사용하면 우리가 저지른 실수는 대부분 복구할 수 있지만 되돌린 것은 복구할 수 없다.

--amend

종종 완료한 커밋을 수정해야 할 때가 있다. 너무 일찍 커밋했거나 어떤 파일을 빼먹었을 때 그리고 커밋 메시지를 잘못 적었을 때 한다. 다시 커밋하고 싶으면 파일 수정 작업을 하고 Staging Area에 추가한 다음 --amend 옵션을 사용하여 커밋을 재작성 할 수 있다.

git commit --amend

## 아래와 같이 작성하면 커밋이 한개로 기록됨
git commit -m 'initial commit'
git add forgotten_file
git commit --amend

파일 상태를 Unstage로 변경하기

git reset HEAD <file>

Modified 파일 되돌리기

git checkout -- <file>

git reset 명확히 알고가기

reset은 들어가기전에 HEAD, Index, 워킹 디렉토리에 대한 구분을 하고 들어가면 좋다.

  • HEAD : 마지막 커밋 스냅샷, 다음 커밋의 부모 커밋
  • Index : 다음에 커밋할 스냅샷
  • 워킹 디렉토리 : .

 

 

애매한 기준으로 나눠 놓은 이유는, reset의 주요 옵션인 --soft, mixed, hard가 위를 기준으로 동작하기 때문이다.

 

reset은 HEAD의 위치를 이동하며 옵션에 따라 Index와 Working tree도 갱신하는 작업을 수행한다.

전반적인 동작 과정은 다음과 같다.

 

  1. 브랜치의 HEAD를 옮긴다. (—soft 옵션이 붙으면 여기까지)
    : reset 명령은 가장 최근의 git commit 명령을 되돌린다. git commit 명령을 실행하면 Git은 새로운 커밋을 생성하고 HEAD가 가리키는 브랜치가 새로운 커밋을 가리키도록 업데이트한다.
  2. Index를 HEAD가 가리키는 상태로 만든다. (—mixed 옵션이 붙으면 여기까지)
    : 가리키는 대상을 가장 최근의 커밋 으로 되돌리는 것은 같다. 그러고 나서 Staging Area 를 비우기까지 한다. git commit 명령도 되돌리고 git add 명령까지 되돌리는 것
  3. 워킹 디렉토리를 Index의 상태로 만든다. (—hard 옵션이 붙으면 여기까지) 
    : reset 명령을 통해 git add 와 git commit 명령으로 생성한 마지막 커밋을 되돌린다. 그리고 워킹 디렉토리의 내용까지도 되돌린다.

 

이 --hard 옵션은 매우 매우 중요하다. reset 명령을 위험하게 만드는 유일한 옵션이다. 이 옵션을 사용하면 워킹 디렉토리의 파일까지 강제로 덮어쓰기 때문이다.

마치며

3장 정리가 늦었는데, 다음은 마지막으로 bracnh의 내용만 정리하고 끝내려고한다. reset은 공동작업에서 꼬이는 경우가 많아 제법 자주 쓰이니까 잘 알아둬야할 것 같다.

'개발 > git' 카테고리의 다른 글

GIT LFS(Large File Storage)란?  (0) 2023.02.20
Git이란? (4) - branch란?  (0) 2023.02.19
Git 이란? (2) - Git 명령어  (0) 2023.01.29
Git 이란? (1) - Git 기초  (0) 2023.01.28
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/07   »
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
글 보관함