Close

Git Status: 리포지토리 검사


git status


git status 명령은 작업 디렉터리와 스테이징 영역의 상태를 표시합니다. 어떤 변경 사항이 스테이징되었는지 또는 스테이징되지 않았는지, 어떤 파일이 Git에서 추적되지 않는지 알 수 있습니다. 상태 출력에는 커밋된 프로젝트 기록에 관한 정보가 표시되지 않습니다. 이를 위해서는 git log를 사용해야 합니다.

관련 git 명령

  • git tag
    • 태그는 Git 기록의 특정 지점을 가리키는 참조입니다. git tag는 보통 표시된 버전 릴리스(예: v1.0.1)에 사용되는 기록의 한 지점을 캡처하는 데 사용됩니다.
  • git blame
    • git blame의 개략적인 수준의 기능은 파일의 커밋된 특정 줄에 연결된 작성자 메타데이터를 표시하는 것입니다. 특정 코드의 기록을 살펴보고 어떤 코드가 리포지토리에 추가되었는지, 추가 방법 및 이유에 대한 질문에 답하는 데 사용됩니다.
  • git log
    • git log 명령은 커밋된 스냅샷을 표시합니다. 프로젝트 기록을 나열하고, 필터링하고, 특정한 변경 사항을 검색할 수 있습니다.
Git 로고
관련 자료

Git 치트 시트

Bitbucket 로고
솔루션 보기

Bitbucket Cloud에서 Git에 대해 알아보기

사용

git status

스테이징된 파일, 스테이징되지 않은 파일, 추적되지 않은 파일을 나열합니다.

토론

git status 명령은 비교적 간단한 명령으로, git addgit commit과 관련하여 무슨 일이 일어났는지 보여줍니다. 상태 메시지에는 파일 스테이징/스테이징 취소와 관련된 설명도 포함되어 있습니다. git status 호출의 세 가지 주요 범주를 보여주는 샘플 출력은 다음과 같습니다.

# On branch main
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
#modified: hello.py
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
#modified: main.py
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
#hello.pyc

파일 무시

추적되지 않은 파일은 일반적으로 두 가지 범주로 나뉩니다. 프로젝트에 방금 추가되었지만 아직 커밋되지 않은 파일이거나 .pyc, .obj, .exe, 등과 같은 컴파일된 바이너리입니다. 전자에 해당하는 파일을 git status 출력에 포함시키면 분명히 유용하지만 후자는 리포지토리에서 실제로 무슨 일이 일어나고 있는지 알기가 어려울 수 있습니다.

그래서 Git은 .gitignore라는 특수 파일에 경로를 넣어 파일을 완전히 무시할 수 있도록 합니다. 무시하려는 모든 파일은 별도의 줄에 포함되며 * 기호를 와일드카드로 사용할 수 있습니다. 예를 들어, 프로젝트 루트에 있는 .gitignore 파일에 다음을 추가하면 컴파일된 Python 모듈이 git status에 나타나지 않게 됩니다.

*.pyc

의도하지 않은 것을 실수로 커밋하지 않도록 변경 사항을 커밋하기 전에 리포지토리의 상태를 확인하는 것이 좋습니다. 이 예시에서는 스냅샷을 스테이징하고 커밋하기 전과 후의 리포지토리 상태를 표시합니다.

# Edit hello.py
git status
# hello.py is listed under "Changes not staged for commit"
git add hello.py
git status
# hello.py is listed under "Changes to be committed"
git commit
git status
# nothing to commit (working directory clean)

The first status output will show the file as unstaged. The git add action will be reflected in the second git status, and the final status output will tell you that there is nothing to commit—the working directory matches the most recent commit. Some Git commands (e.g., git merge) require the working directory to be clean so that you don't accidentally overwrite changes.

git log


git log 명령은 커밋된 스냅샷을 표시합니다. 프로젝트 기록을 나열하고, 필터링하고, 특정한 변경 사항을 검색할 수 있습니다. git status를 사용하면 작업 디렉터리 및 스테이징 영역을 검사할 수 있지만 git log는 커밋된 기록에서만 작동합니다.

Git status vs git log

로그 출력은 간단하게 커밋을 필터링하는 것부터 완전한 사용자 정의 형식으로 표시하는 것까지 여러 가지 방법으로 사용자 지정할 수 있습니다. git log의 가장 일반적인 구성 중 몇 가지는 아래와 같습니다.

사용

git log

기본 형식을 사용하여 전체 커밋 기록을 표시합니다. 출력이 하나의 화면 이상을 차지하면 Space 키를 사용하여 스크롤하고 q를 사용하여 종료할 수 있습니다.

git log -n <limit>

으로 커밋의 수를 제한합니다. 예를 들어, git log -n 3은 3개의 커밋만 표시합니다.

각 커밋을 한 줄로 압축합니다. 프로젝트 기록의 간략한 개요를 보는 데 유용합니다.

git log --oneline
git log --stat

일반 git log 정보와 함께 어떤 파일이 변경되었는지, 그리고 각 파일에서 추가되거나 삭제된 줄의 상대적인 개수를 포함합니다.

git log -p

각 커밋을 나타내는 패치를 표시합니다. 프로젝트 기록을 가장 자세하게 볼 수 있는 각 커밋의 전체 diff를 보여줍니다.

git log --author="<pattern>"

Search for commits by a particular author. The <pattern> argument can be a plain string or a regular expression.

git log --grep="<pattern>"

Search for commits with a commit message that matches <pattern>, which can be a plain string or a regular expression.

git log <since>..<until>

< since >< until > 사이에 발생하는 커밋만 보여줍니다. 두 인수 모두 커밋 ID, 브랜치 이름, HEAD 또는 다른 종류의 수정본 참조일 수 있습니다.

git log <file>

지정된 파일을 포함하는 커밋만 표시합니다. 특정 파일의 기록을 쉽게 볼 수 있는 방법입니다.

git log --graph --decorate --oneline

고려할 만한 몇 가지 유용한 옵션이 있습니다. --graph 플래그는 커밋 메시지 왼쪽에 커밋의 텍스트 기반 그래프를 그립니다. --decorate는 표시된 커밋의 브랜치 이름이나 태그를 추가합니다. --oneline은 커밋 정보를 한 줄로 표시하여 커밋을 한 눈에 더 쉽게 찾아볼 수 있도록 합니다.

토론

5. 파일의 상태를 확인합니다.

commit 3157ee3718e180a9476bf2e5cab8e3f1e78a73b7
Author: John Smith

대부분 꽤 간단하지만 첫 줄에는 약간의 설명이 필요합니다. commit 뒤의 40자 문자열은 커밋 콘텐츠의 SHA-1 체크섬이며 두 가지 용도로 사용됩니다. 우선 커밋의 무결성을 보장합니다. 커밋이 손상되면 커밋은 다른 체크섬을 생성합니다. 두 번째로 커밋의 고유한 ID 역할을 합니다.

이 ID는 특정한 커밋을 참조하기 위해 git log ..과 같은 명령에 사용될 수 있습니다. 예를 들어, git log 3157e..5ab91은 ID가 3157e5ab91인 커밋 사이의 모든 것을 표시합니다. 체크섬 외에도 개별 커밋을 참조하는 기타 일반적인 방법으로는 브랜치 이름(브랜치 모듈에서 설명함) 및 HEAD 키워드가 있습니다. HEAD는 브랜치든 특정 커밋이든 관계없이 항상 현재 커밋을 참조합니다.

~ 문자는 커밋의 상위 항목을 상대적으로 참조할 때 유용합니다. 예를 들어, 3157e~13157e 이전의 커밋을 의미하고 HEAD~3은 현재 커밋의 최상위 항목에 해당합니다.

사용 방법 섹션에는 git log의 예시가 많이 나와 있는데 여러 옵션을 하나의 명령으로 결합할 수 있다는 점을 명심하세요.

git log --author="John Smith" -p hello.py

이렇게 하면 John Smith가 hello.py 파일에 적용한 모든 변경 사항의 전체 diff가 표시됩니다.

.. 구문은 브랜치를 비교하는 데 매우 유용한 도구입니다. 다음 예시는 main 포함되지 않은 some-feature에 있는 모든 커밋에 대한 간략한 개요를 표시합니다.

git log --oneline main..some-feature

이 문서 공유
다음 토픽

여러분께 도움을 드릴 자료를 추천합니다.

이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.

도구로 가득한 벽을 사용하여 협업하는 사람들

Bitbucket 블로그

DevOps 일러스트레이션

DevOps 학습 경로

Atlassian 전문가와 함께 하는 Demo Den 기능 데모

Bitbucket Cloud가 Atlassian Open DevOps와 작동하는 방법

DevOps 뉴스레터 신청

Thank you for signing up