정리노트

[기타/Git] 저장소 수정 / 저장 / 관리 본문

프로그래밍/기타

[기타/Git] 저장소 수정 / 저장 / 관리

Rolen 2025. 1. 28. 15:25

수정하고 저장소에 저장하기

워킹 디렉토리의 모든 파일은 크게 Tracked(관리대상임)와 Untracked(관리대상이 아님)로 나눈다.

 

1. Tracked 파일

이미 스냅샷에 포함돼 있던 파일이다.

Tracked 파일은

Unmodified(수정하지 않음)와 Modified(수정함) 그리고 Staged(커밋으로 저장소에 기록할) 상태 중 하나이다.

간단히 말하자면 Git이 알고 있는 파일이라는 것이다.

 

2. Untracked 파일
나머지 파일은 모두 Untracked 파일이다.

Untracked 파일은 워킹 디렉토리에 있는 파일 중 스냅샷에도 Staging Area에도 포함되지 않은 파일이다.

처음 저장소를 Clone 하면 모든 파일은 Tracked이면서 Unmodified 상태이다.

파일을 Checkout 하고 나서 아무것도 수정하지 않았기 때문에 그렇다.

마지막 커밋 이후 아직 아무것도 수정하지 않은 상태에서

어떤 파일을 수정하면 Git은그 파일을 Modified 상태로 인식한다.

실제로 커밋을 하기 위해서는 이 수정한 파일을 Staged 상태로 만들고, Staged 상태의 파일을 커밋한다.

이런 라이프사이클을 계속 반복한다.

 


 

파일 상태 확인하기

저장소와 연결된 프로젝트에 새 파일을 만들고 상태를 확인해보면

$ git status

 

 새로 만든 파일이기 때문에 git status 를 실행하면 'Untracked files’에 들어 있다

 

# status를 Short 하게 확인
$ git status -s

 

붉은색 : unstaged

녹색 : committed

M : 수정한 파일

A : 새 파일

 

- 파일 unstaged 하기

$ git restore --staged <file>

 

파일 추적하기

git add 명령으로 파일을 새로 추적할 수 있다. 아래 명령을 실행하면 Git은 Member 파일을 추적한다.

# 현재 파일의 경로에 있다면
$ git add Member 
# 파일의 경로에 위치하고 있지 않다면 파일의 경로 명시
$ git add .\src\main\java\com\example\demo\Member.java

 

그리고 상태를 확인하면

 

committed 되어있음을 확인 할 수 있다.

 

만약 여러 파일을 add 해야한다면 add * 로 간단하게 가능하며

이미 있던 파일의 내용을 수정하고 add 를 하면 수정(스냅 샷에 의하여 변경 감지)

새로운 파일을 만들고 add 를 하면 새 파일로 등록이 된다.

 

변경사항 커밋하기

수정한 것을 커밋하기 위해 Staging Area에 파일을 정리했다.

Unstaged 상태의 파일은 커밋되지 않는다.

Git은 생성하거나 수정하고 나서 git add 명령으로 추가하지 않은 파일은 커밋하지 않는다.

그 파일은 여전히 Modified 상태로 남아 있다.

커밋하기 전에 git status 명령으로 모든 것이 Staged 상태인지 확인할 수 있다. 그 후에 git commit 을 실행하여 커밋한다.

$ git commit

 

앞의 commit -m "message"에 빠뜨린 파일이 있는 경우

git commit --amend 를 입력하고 원하는 메시지(message2)로 바꾸어 앞의 commit과 하나로 합칠 수 있다.


git을 통하여 관리할 파일의 패턴은

.gitignore 에 작성

(.abc 파일은 제외, /abc/ 의 하위의 내용 제외 등)

https://www.toptal.com/developers/gitignore

 

gitignore.io

Create useful .gitignore files for your project

www.toptal.com

 

Staged와 Unstaged 상태의 변경 내용을 보기

단순히 파일이 변경됐다는 사실이 아니라 어떤 내용이 변경됐는지 살펴보려면

git status 명령이 아니라 git diff 명령을 사용해야 한다.

$ git diff

 

파일 삭제하기

 

Git에서 파일을 제거하려면 git rm 명령으로 Tracked 상태의 파일을 삭제한 후에

(정확하게는 Staging Area에서 삭제하는 것)

커밋해야 한다. 이 명령은 워킹 디렉토리에 있는 파일도 삭제하기 때문에 실제로 파일도 지워진다.

$ git rm <file>

 

커밋 히스토리 조회하기

새로 저장소를 만들어서 몇 번 커밋을 했을 수도 있고, 커밋 히스토리가 있는 저장소를 Clone 했을 수도 있다.

어쨌든 가끔 저장소의 히스토리를 보고 싶을 때가 있다. Git에는 히스토리를 조회하는 명령어인 git log 가 있다.

$ git log
$ git log -p
$ git log -2
$ git log --stat

 

 -p 는 각 커밋의 diff 결과를 보여준다.

-2 옵션은 최근 두 개의 결과만 보여주는 옵션이다.

--stat 옵션으로 각 커밋의 통계 정보를 조회할 수 있다.


https://git-scm.com/book/ko/v2/Git%EC%9D%98-%EA%B8%B0%EC%B4%88-%EC%88%98%EC%A0%95%ED%95%98%EA%B3%A0-%EC%A0%80%EC%9E%A5%EC%86%8C%EC%97%90-%EC%A0%80%EC%9E%A5%ED%95%98%EA%B8%B0

 

Git - 수정하고 저장소에 저장하기

.gitignore 를 사용하는 간단한 방식은 하나의 .gitignore 파일을 최상위 디렉토리에 하나 두고 모든 하위 디렉토리에까지 적용시키는 방식이다. 물론 .gitignore 파일을 하나만 두는 것이 아니라 하위

git-scm.com

https://git-scm.com/book/ko/v2/Git%EC%9D%98-%EA%B8%B0%EC%B4%88-%EC%BB%A4%EB%B0%8B-%ED%9E%88%EC%8A%A4%ED%86%A0%EB%A6%AC-%EC%A1%B0%ED%9A%8C%ED%95%98%EA%B8%B0

 

Git - 커밋 히스토리 조회하기

머지 커밋 표시하지 않기 저장소를 사용하는 워크플로우에 따라 머지 커밋이 차지하는 비중이 클 수도 있다. --no-merges 옵션을 사용하면 검색 결과에서 머지 커밋을 표시하지 않도록 할 수 있다.

git-scm.com

 

728x90