대체 메커니즘을 통해 저장는 다른 객체 데이터베이스로부터 자신의 객체 데이터베이의 일부를 상속받을 수 있으며, 이를 "대체(alternate)"라고 합니다.

베어 저장소는 일반적으로 .git 접미사를 가진 적절히 명명된 디렉토리입니다. 이 저장소에는 리비전 관리 대상 파일의 로컬로 체크아웃된 사본이 없습니다. 즉, 일반적으로 숨겨진 `.git`하위 디렉토리에 보통 존재하는 모든 깃 관리 및 제어 파일은 직접적으로 `repository.git`디렉토리에 있으며, 다른 파일은 존재하지 않고 체크아웃되지 않습니다. 일반적으로 공개 저장소의 게시자들은 베어 저장소를 제공합니다.

유형이 지정되지 않은 객체, 예: 파일의 내용.

A "branch" is a line of development. The most recent commit on a branch is referred to as the tip of that branch. The tip of the branch is referenced by a branch head, which moves forward as additional development is done on the branch. A single Git repository can track an arbitrary number of branches, but your working tree is associated with just one of them (the "current" or "checked out" branch), and HEAD points to that branch.

더 이상 사용되지 않음: 인덱스.

목록의 각 객체에 후속 항목에 대한 참조가 포함된 객체 목록입니다(예: 커밋의 후속 항목은 부모들 중 하나일 수 있습니다. ).

BitKeeper/cvsps는 "커밋"을 나타냅니다. 깃은 변경 사항을 저장하지 않고 상태를 나타내기 때문에 깃에서 "changesets"라는 용어를 사용하는 것은 말이 되지 않습니다.

작업 트리의 전체 또는 일부를 객체 데이터베이스에서 트리 객체나 블롭(blob)으로 업데이트하고, 작업 트리 전체가 새 분기를 가리키도록 되어 있다면 인덱스 와 HEAD를 업데이트하는 동작입니다.

SCM 용어로서 "체리픽(cherry pick)"은 일련의 변경 사항(일반적으로 커밋) 중 일부를 선택하여 다른 코드베이스 위에 새로운 일련의 변경 사항으로 기록하는 것을 의미합니다. Git에서는 "git cherry-pick" 명령을 사용하여 기존 커밋에서 도입된 변경 사항을 추출하고 현재 분기 의 끝을 기준으로 새로운 커밋으로 기록합니다.

현재 헤드가 참조하는 리비전에 해당하는 경우, 작업 트리 를 클린(clean)하다고 합니다. "dirty"도 참조해주세요.

명사로서: 프로젝트의 전체 히스토리는 상호 연관된 커밋들의 집합으로 표시됩니다. 깃에서 "커밋(commit)"이라는 용어는 다른 리비전 관리 시스템이 "리비전(revision)" 또는 "버전(version)"이라는 용어를 사용하는 것과 같은 장소에서 자주 사용됩니다. 또한, 커밋 객체의 약어로도 사용됩니다.

객체 데이터베이스에 의해 레퍼런스되는 브랜치 끝점들을 통해 형성된 연결된 커밋들의 체인 을 사용하여 형성된 DAG 구조의 동의어입니다. 이 구조는 확정 커밋 그래프입니다. 이 그래프는 다른 방식으로 표현될 수 있으며, 예를 들어 "커밋-그래프" 파일와 같이 표현될 수 있습니다.

"커밋-그래프"(일반적으로 하이픈으로 구분되는) 파일은 커밋 그래프 탐색을 가속화하기 위한 보조 표현입니다. "commit-graph" 파일은 .git/objects/info 디렉토리나 대체 객체 데이터베이스의 info 디렉토리에 저장됩니다.

특정 리비전에 대한 부모, 커미터, 작성자, 날짜 및 저장된 리비전의 최상위 디렉토리에 해당하는 트리 객체와 같은 정보를 포함하는 객체를 말합니다.

커밋 객체로 재귀적으로 역참조할 수 있는 커밋 객체 또는 객체를 말합니다. 다음은 모두 commit-ish 객체로 간주됩니다: 커밋 객체 자체, 커밋 객체를 가리키는 태그 객체, 커밋 객체를 가리키는 태그 객체를 가리키는 태그 객체 등등.

깃의 기본적인 자료구조와 유틸리티로, 제한된 소스 코드 관리 도구만을 노출합니다.

유향 비순환 그래프(Directed Acyclic Graph). 깃에서 커밋 객체들은 방향성이 있는 비순환 그래프인 유향 비순환 그래프를 형성합니다. 이는 커밋 객체들이 부모를 가지고 있기 때문에 방향성을 가지며, 커밋 객체들의 그래프는 사이클이 없습니다(시작과 끝이 같은 객체를 가지는 체인은 없습니다).

도달 불가능한 다른 객체에서도 도달 가능하지 않은 도달 불가능 객체로, 댕글링 객체는 어떠한 참조나 저장소 내에 있는 객체로부터도 참조되지 않는 상태로 존재하는 객체를 말합니다.

일반적으로 HEAD는 분기의 이름을 저장하며, HEAD를 기준으로 동작하는 명령은 HEAD가 가리키는 브랜치의 끝으로 이어지는 히스토리에서 동작합니다. 그러나 깃은 임의의 커밋을 체크아웃하여 HEAD가 특정 브랜치의 끝이 아닌 커밋을 가리킬 수도 있습니다. 이러한 상태에서의 HEAD를 "디태치드(detached)"라고 합니다.

"ls"로 표시되는 리스트 :-)

현재 분기에 커밋되지 않은 수정 사항이 있는 경우, 이 작업 트리는 "더티(dirty)" 상태라고 합니다.

An evil merge is a merge that introduces changes that do not appear in any parent.

정방향 진행(fast-forward)은 특정한 유형의 병합으로, 현재 가지고 있는 리비전과 동일한 조상을 가진 다른 분기의 변경 사항을 "병합"하는 경우를 말합니다. 이 경우, 새로운 병합 커밋 을 만들지 않고 대신 분기를 병합하는 분기와 동일한 리비전을 가리키도록 업데이트합니다. 이러한 상황은 원격 저장소의 원격 추적 분기에서 자주 발생할 수 있습니다.

branch를 페치(fetch)한다는 것은 원격 저장소에서 해당 브랜치의 헤드 레퍼런스 를 가져오고, 로컬 객체 데이터베이스에서 누락된 객체를 찾아서 가져오는 것을 의미합니다. git-fetch[1]를 참조하세요.

리누스 토르발스는 처음 깃을 설계할 때 사용자 공간 파일 시스템으로 설계했습니다. 즉, 파일과 디렉토리를 보유하기 위한 인프라입니다. 이를 통해 깃의 효율성과 속도를 보장하고 있습니다.

저장소의 동의어 (arch 사용자 대상).

작업 트리의 루트에 위치한 일반 파일 `.git`은 실제 저장소가 있는 디렉토리를 가리킵니다.

이식(Grafts)은 커밋에 대한 가짜 조상 정보를 기록함으로써 서로 다른 두 개발 라인을 함께 연할 수 있게 해줍니다. 이렇게 하면 깃이 커밋의 부모 집합이 커밋이 생성될 때 기록된 것과 다른 것처럼 가장할 수 있습니다. `.git/info/grafts`파일을 통해 구성할 수 있습니다.

Git의 문맥에서 객체명에 대한 동의어.

분기의 끝에 있는 커밋을 가리키는 명명된 레퍼런스를 헤드(head)라고 합니다. 헤드는 packed refs를 사용하는 경우를 제외하면`$GIT_DIR/refs/heads/` 디렉토리에 있는 파일에 저장되어 있습니다. (git-pack-refs[1]를 참조하세요.)

현재의 브랜치입니다. 좀 더 자세히 설명하면, 작업 트리는 일반적으로 HEAD가 가리키는 트리의 상태에서 유도됩니다. HEAD는 저장소 내의 하나의 헤드를 가리키는 참조입니다. 다만, 분리된 HEAD를 사용하는 경우에는 임의의 커밋을 직접 참조합니다.

헤드와 동의어.

여러 깃 명령의 정상적인 실행 중에는 개발자가 기능 또는 확인을 추가할 수 있는 선택적인 스크립트를 호출합니다. 일반적으로 훅(hooks)은 명령이 사전에 확인되고 중단될 수 있도록 하며, 작업이 완료된 후에 후속 알림을 허용합니다. 훅 스크립트는`$GIT_DIR/hooks/`디렉토리에서 찾을 수 있으며, 파일명에서 `.sample`접미사를 제거함으로써 활성화됩니다. 초기 버전의 깃에서는 이것을 실행할 수 있도록 직접 만들어야 했었습니다.

파일의 상태 정보를 포함하고, 내용은 객체로 저장되는 파일의 집합입니다. 인덱스는 작업 트리의 저장된 버전입니다. 사실, 인덱스에는 작업 트리의 두 번째 또는 세 번째 버전을 포함할 수도 있으며, 이는 병합시 사용됩니다.

인덱스에 저장된 특정 파일에 대한 정보입니다. 인덱스 엔트리는 병합이 시작되었지만 아직 완료되지 않은 경우(즉, 인덱스에 해당 파일의 여러 버전이 포함된 경우) 병합되지 않은 상태일 수 있습니다.

기본 개발 분기입니다. 깃 저장소를 생성할 때마다 "master"라는 이름의 분기가 생성되고 활성 분기가 됩니다. 대부분의 경우, 이 분기에는 로컬 개발이 포함되지만, 이는 순수히 관례적인 것일 뿐이며 필수적인 요구사항은 아닙니다.

동사로서: 다른 저장소에서 가져온 다른 분기의 내용을 현재 분기로 가져오는 것을 말합니다. 병합된 분기가 다른 저장소에서 가져온 것인 경우, 먼저 원격 분기를 페치(fetch)하고 그 결과를 현재 분기에 병합하는 방식으로 수행됩니다. 이러한 fetch와 merge 작업의 조합을 풀(pull)이라고 합니다. 병합은 두 분기가 분기된 이후에 생긴 변경 사항을 자동으로 식별하고 모든 변경 사항을 함께 적용하는 과정입니다. 변경 사항이 충돌하는 경우 수동 개입이 필요할 수 있습니다.

깃의 저장 단위입니다. 콘텐츠의 SHA-1을 통해 고유하게 식별됩니다. 따라서 객체는 변경될 수 없습니다.

일련의 "객체(objects)"를 저장하며, 각각의 객체는 그 객체명을 통해 식별됩니다. 일반적으로 객체들은`$GIT_DIR/objects/`디렉토리에 저장됩니다.

객체명과 동의어.

객체의 고유 식별자. 객체명은 보통 40자의 16진수 문자열로 표시됩니다. 흔히 SHA-1라고도 불립니다.

One of the identifiers "commit", "tree", "tag" or "blob" describing the type of an object.

두 개 이상의 분기를 병합하기 위해 사용됩니다.

기본 상위 저장소입니다. 대부분의 프로젝트는 추적하는 상위 프로젝트가 최소한 하나 있습니다. 기본적으로 'origin’이 그 목적으로 사용됩니다. 새로운 상위 업데이트는 origin/name-of-upstream-branch라는 이름의 원격 추적 분기로 fetch되며, 이를 git branch -r 명령어를 통해 확인할 수 있습니다.

작업 디렉토리에 파일을 업데이트하고 추가하지만 삭제하지는 않습니다. 마치 'cp -R’이 대상 디렉토리의 내용을 업데이트하는 방식과 유사합니다. 이는 인덱스 또는 유사 트리에서 파일을 체크아웃할 때의 기본 모드입니다. 반면, 오버레이 모드가 아닌 경우에는 소스에 없는 추적 파일도 삭제되는 것과 유사하게 'rsync --delete’와 같이 동작합니다.

공간을 절약하거나 효율적으로 전송하기 위해 여러 개의 객체를 하나의 파일로 압축한 집합입니다.

팩의 객체들의 식별자와 다른 정보들을 포함한 목록입니다. 이는 팩의 내용에 효율적으로 접근하기 위해 도움을 주는 역할을 합니다.

깃 명령어에서 경로를 제한하는 데 사용되는 패턴입니다.

커밋 객체에는 개발 라인에서의 논리적 조상, 즉 그 부모(비어있을 수도 있음) 목록이 포함되어 있습니다.

곡괭이라는 용어는 주어진 텍스트 문자열을 추가하거나 삭제하는 변경 사항을 선택하는 데 도움이 되는 diffcore 루틴의 옵션을 가리킵니다. `--pickaxe-all`옵션을 사용하면 특정 텍스트 줄을 도입하거나 제거한 전체 변경 세트를 볼 수 있습니다. git-diff[1]를 참조해 주세요.

코어 깃의 애칭.

코어 깃에 의존하는 프로그램이나 프로그램 모음의 애칭으로, 코어 깃에 대한 고수준 액세스를 제공합니다. Porcelain은 배관보다 더 많은 SCM 인터페이스를 노출합니다.

전역적 참조가 아닌 작업 트리를 통째로 참조하는 것. 현재는 HEAD와 `refs/bisect/`로 시작하는 참조만이지만, 추후 다른 특이한 참조도 포함될 수 있습니다.

의사참조는 `$GIT_DIR`하위에 있는 파일의 한 유형으로, rev-parse의 목적을 위해 참조처럼 동작하지만, 깃에서 특별하게 처리됩니다. 의사참조는 모두 대문자로 된 이름을 가지고 있으며, 항상 공백으로 구분된 SHA-1으로 시작하는 줄로 시작합니다. 따라서 HEAD는 때때로 심볼릭 참조가 될 수 있기 때문에 의사참조가 아닙니다. 의사참조는 선택적으로 일부 추가 데이터를 포함할 수도 있습니다.`MERGE_HEAD`와 `CHERRY_PICK_HEAD`가 그 예시입니다. 작업트리별 레퍼런스와 달리, 이 파일들은 심볼릭 참조일 수 없으며, 참조 로그도 가지지 않습니다. 또한, 일반적인 참조 업데이트 메커니즘을 통해 업데이트할 수도 없습니다. 대신, 파일에 직접 쓰는 방식으로 업데이트됩니다. 그러나 참조처럼 읽을 수 있으므로 `git rev-parse MERGE_HEAD`와 같은 명령이 작동합니다.

분기를 풀(pull)하는 것은 해당 분기를 페치하고 병합하는 것을 의미합니다. 자세한 내용은 git-pull[1]을 참조하십시오.

분기를 푸시(push)하는 것은 원격 저장소에서 해당 분기의 헤드 레퍼런스를 가져와 이를 로컬 분기의 헤드 레퍼런스와 비교하여 조상인지 확인한 후, 조상일 경우 로컬 헤드 레퍼런스로부터 도달 가능한 모든 객체를 원격 객체 데이터베이스에 없는 객체들로 이동시키고, 원격 헤드 레퍼런스를 업데이트하는 것을 의미합니다. 원격 헤드가 로컬 헤드의 조상이 아닌 경우, 푸시는 실패합니다.

All of the ancestors of a given commit are said to be "reachable" from that commit. More generally, one object is reachable from another if we can reach the one from the other by a chain that follows tags to whatever they tag, commits to their parents or trees, and trees to the trees or blobs that they contain.

도달 가능성 비트맵은 팩 파일(packfile)이나 멀티팩 인덱스(MIDX)에 있는 선택된 일련의 커밋에 대한 도달 가능성 정보를 저장하여 객체 검색 속도를 향상시키는데 사용됩니다. 비트맵은 ".bitmap" 파일에 저장됩니다. 한 저장소에는 최대 하나의 비트맵 파일을 사용할 수 있습니다. 비트맵 파일은 하나의 팩에 속할 수도 있고, 저장소의 멀티팩 인덱스에 속할 수도 있습니다(멀티팩 인덱스가 있는 경우).

한 분기에서 베이스로 일련의 변경사항을 다시 적용하고, 해당 브랜치의 헤드를 결과로 재설정하는 작업을 수행합니다.

refs/`로 시작하는 이름(예: `refs/heads/master)은 객체명 또는 다른 참조(후자는 심볼릭 참조라고도 합니다)를 가리킵니다. 편의상 깃 명령의 인수로 사용될 때 참조(ref)는 때때로 축약될 수도 있습니다. 자세한 내용은 gitrevisions[7]을 참조하십시오. 참조는 저장소에 저장됩니다.

참조 로그(reflog)는 참조(ref)의 로컬 "히스토리"를 보여줍니다. 다시 말해, _이 저장소_에서 3번째로 최근의 리비전이 어떤 내용이었는지, 그리고 _이 저장소_에서 어제 오후 9시 14분에 현재 상태가 어떠했는지를 알려줄 수 있습니다. 자세한 내용은 git-reflog[1]을 참조하십시오.

"Refspec"은 페치(fetch)와 푸시(push) 시 사용되며, 원격 레퍼런스와 로컬 레퍼런스간의 매핑을 설명하는 데 사용됩니다.

동일한 프로젝트를 추적하는 데 사용되지만 다른 위치에 있는 저장소입니다. 원격 저장소와 통신하기 위해서는 페치(fetch) 또는 푸시(push)를 참조해 주십시오.

다른 저장소에서 변경 사항을 추적하는 데 사용되는 레퍼런스입니다. 일반적으로 refs/remotes/foo/bar’와 같은 형식을 가지며, 이는 'foo’라는 원격 저장소의 'bar 분기를 추적한다는 것을 나타냅니다. 이는 설정된 fetch 레퍼런스 규범의 오른쪽 부분과 일치합니다. 원격 추적 분기에는 직접적인 수정이 포함되어 있거나 해당 분기에 로컬 커밋이 적용되어서는 안 됩니다.

레퍼런스의 모음과 레퍼런스들로부터 도달 가능한 모든 객체를 포함하는 객체 데이터베이스로 구성된 모음입니다. 이는 하나 이상의 자기(porcelains)로부터의 메타 데이터와 함께 제공될 수도 있습니다. 저장소는 대체 매커니즘을 통해 다른 저장소와 객체 데이터베이스를 공유할 수 있습니다.

자동 병합 작업이 실패한 후 수동으로 수정하는 동작을 의미합니다. 즉, 자동 병합이 남긴 오류를 수동으로 해결하는 것을 말합니다.

커밋(명사)과 동의어.

개발 사항의 일부를 버리는 것을 말합니다. 즉, 현재의 헤드를 이전의 리비전에 할당하는 것을 말합니다.

소스 코드 관리(도구).

"Secure Hash Algorithm 1"; a cryptographic hash function. In the context of Git used as a synonym for object name.

Mostly a synonym to shallow repository but the phrase makes it more explicit that it was created by running git clone --depth=... command.

A shallow repository has an incomplete history some of whose commits have parents cauterized away (in other words, Git is told to pretend that these commits do not have the parents, even though they are recorded in the commit object). This is sometimes useful when you are interested only in the recent history of a project even though the real history recorded in the upstream is much larger. A shallow repository is created by giving the --depth option to git-clone[1], and its history can be later deepened with git-fetch[1].

An object used to temporarily store the contents of a dirty working directory and the index for future reuse.

A repository that holds the history of a separate project inside another repository (the latter of which is called superproject).

A repository that references repositories of other projects in its working tree as submodules. The superproject knows about the names of (but does not hold copies of) commit objects of the contained submodules.

Symbolic reference: instead of containing the SHA-1 id itself, it is of the format ref: refs/some/thing and when referenced, it recursively dereferences to this reference. HEAD is a prime example of a symref. Symbolic references are manipulated with the git-symbolic-ref[1] command.

A ref under refs/tags/ namespace that points to an object of an arbitrary type (typically a tag points to either a tag or a commit object). In contrast to a head, a tag is not updated by the commit command. A Git tag has nothing to do with a Lisp tag (which would be called an object type in Git’s context). A tag is most typically used to mark a particular point in the commit ancestry chain.

An object containing a ref pointing to another object, which can contain a message just like a commit object. It can also contain a (PGP) signature, in which case it is called a "signed tag object".

A regular Git branch that is used by a developer to identify a conceptual line of development. Since branches are very easy and inexpensive, it is often desirable to have several small branches that each contain very well defined concepts or small incremental yet related changes.

Either a working tree, or a tree object together with the dependent blob and tree objects (i.e. a stored representation of a working tree).

An object containing a list of file names and modes along with refs to the associated blob and/or tree objects. A tree is equivalent to a directory.

A tree object or an object that can be recursively dereferenced to a tree object. Dereferencing a commit object yields the tree object corresponding to the revision's top directory. The following are all tree-ishes: a commit-ish, a tree object, a tag object that points to a tree object, a tag object that points to a tag object that points to a tree object, etc.

An index which contains unmerged index entries.

An object which is not reachable from a branch, tag, or any other reference.

The default branch that is merged into the branch in question (or the branch in question is rebased onto). It is configured via branch.<name>.remote and branch.<name>.merge. If the upstream branch of A is origin/B sometimes we say "A is tracking origin/B".

The tree of actual checked out files. The working tree normally contains the contents of the HEAD commit’s tree, plus any local changes that you have made but not yet committed.

A repository can have zero (i.e. bare repository) or one or more worktrees attached to it. One "worktree" consists of a "working tree" and repository metadata, most of which are shared among other worktrees of a single repository, and some of which are maintained separately per worktree (e.g. the index, HEAD and pseudorefs like MERGE_HEAD, per-worktree refs and per-worktree configuration file).