일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 자바스크립트
- event
- Java
- Docker Desktop
- thread
- 메소드
- Dict
- SSL
- Python
- JavaScript
- StringBuilder
- 배열
- 프로그래머스스쿨
- 스프링부트
- array
- 자바
- 객체
- synchronized
- SpringBoot
- 파이썬
- docker
- JS
- AssertJ
- 저장소
- GIT
- class
- 클래스
- c#
- Swing
- join()
- Today
- Total
정리노트
[기타/Git] 저장소 수정 / 저장 / 관리 본문
수정하고 저장소에 저장하기
워킹 디렉토리의 모든 파일은 크게 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 옵션으로 각 커밋의 통계 정보를 조회할 수 있다.
Git - 수정하고 저장소에 저장하기
.gitignore 를 사용하는 간단한 방식은 하나의 .gitignore 파일을 최상위 디렉토리에 하나 두고 모든 하위 디렉토리에까지 적용시키는 방식이다. 물론 .gitignore 파일을 하나만 두는 것이 아니라 하위
git-scm.com
Git - 커밋 히스토리 조회하기
머지 커밋 표시하지 않기 저장소를 사용하는 워크플로우에 따라 머지 커밋이 차지하는 비중이 클 수도 있다. --no-merges 옵션을 사용하면 검색 결과에서 머지 커밋을 표시하지 않도록 할 수 있다.
git-scm.com
'프로그래밍 > 기타' 카테고리의 다른 글
[기타/Git] SSH 인증키 - id_rsa 외 다른 파일 이름 인증 연결하기 (0) | 2025.01.31 |
---|---|
[기타/Git] IntelliJ 자동 staged 방지 (0) | 2025.01.29 |
[기타/Git] 리모트 저장소 / ⭐branch, merge⭐ (0) | 2025.01.28 |
[기타/Git] git 의 상태 관리 / 저장소 만들기 (0) | 2025.01.28 |
[기타/Git] 버전 관리 시스템(VCS) (0) | 2025.01.28 |