tech.junha.kr

GIT 라이프사이클: git 관리상태 확인: status, log

좌: 파일 영역의 라이프 사이클 // 우: 파일 상태 라이프 사이클

좌: 파일 영역의 라이프 사이클 // 우: 파일 상태 라이프 사이클

좌: 파일 영역의 라이프 사이클 // 우: 파일 상태 라이프 사이클

좌: 파일 영역의 라이프 사이클 // 우: 파일 상태 라이프 사이클

  • untracked: 새로운 파일
  • modified : 추적파일 and 수정함

1. staging area 영역 파일 확인: git status

$ git status
  • Staging area의 어떤 파일이 변경되었는지, Staging file들의 상태를 확인할 수 있다.

  • 새로 만든 파일의 ADD 여부 확인

  • 커밋된 파일을 수정하고 있는지의 여부 확인

  • untracked, tracked 상태 확인

  • 명령어가 동작하지 않을 때 에러 확인

  • 내가 작업한 파일 외에 다른 파일이 수정되진 않았는지 확인

​

2. 코드로 살펴보는 파일 상태

  1. article.js, comment.js, user.js 파일을 생성하고 add하지 않은 상황이다.

  1. git add 명령어를 통해 article.js 파일을 staging area에 올렸다.
$ git add article.js

  1. add 명령어를 취소
  • 어떤 파일을 add 하면 안되는데 add한 경우, 파일을 add하기 전 상태인 unstage 상태로 만들 수 있다.
$ git reset article.js
# staging area에서 파일을 내리기 위해 자주 쓴다.

$ git rm --cahce article.js
# git rm 명령어는 Git이 추적하지 않는 untracked file로 만든다.
# git rm은 원격저장소와 로컬저장소의 staging area 에서 파일을 내리면서 실제 파일도 삭제한다.
# --cached 옵션과 함께 원격저장소의 파일을 삭제하고, staging area에서 파일을 내리기 위해 쓴다.
  1. 커밋된 article.js를 수정할 경우

article.js의 상태는 modified상태가 된다.

  1. $ git diff 명령어를 통해 commit된 파일상태와 현재 수정중인 상태 비교한다.

3. Local Repo 저장소 반영 내역 확인: git log

$ git log

Local Repo에 반영된 commit 내역을 확인한다.

$ git log -p -3

# -p, --patch : 각 commit 의수정 결과를 보여주는 diff와 같은 역할을 수행한다.
# -n : 상위 n개의 commit만 보여준다.
$ git log --stat

# --stat: 어떤 파일이 commit에서 수정되고 변경되었는지, 피일 내 라인의 수정사항 확인
$ git log --pretty=onelie

# --pretty=onelie: 각 commit을 한 줄로 출력한다.
$ git log  --graph

# --graph: commit간의 연결된 관계를 아스키 그래프로 출력한다.
$ git log -S function_name

# -S: 코드에서 추가되거나 제거된 내용 중 특정 텍스트가 포함되어있는지 검사한다.
# 위 코드에서는 funcion_name이 추가 혹은 제거 되었는지 검사한다.

4. 정리

- git add 명령어를 거친 파일은 Stagged 상태가 된다.

- Untracked 파일을 Git에 추가하기 위해서는 add를 해야한다.

- Unmodified 파일은 항상 Git 저장소에 있는 파일과 내용이 같음을 보장할 수 있다.

- Modified 파일들의 갱신된 내역을 저장소에 반영하기 위해 add와 commit의 과정을 거친다.

- commit을 진행하면 Stagged 파일들이 저장소에 반영되며, unmodified상태가 된다.