Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.46.1 → 2.47.0 no changes
- 2.46.0 07/29/24
- 2.44.1 → 2.45.2 no changes
- 2.44.0 02/23/24
- 2.43.2 → 2.43.5 no changes
- 2.43.1 02/09/24
- 2.43.0 11/20/23
- 2.39.1 → 2.42.3 no changes
- 2.39.0 12/12/22
- 2.36.1 → 2.38.5 no changes
- 2.36.0 04/18/22
- 2.33.1 → 2.35.8 no changes
- 2.33.0 08/16/21
- 2.30.1 → 2.32.7 no changes
- 2.30.0 12/27/20
- 2.23.1 → 2.29.3 no changes
- 2.23.0 08/16/19
- 2.22.1 → 2.22.5 no changes
- 2.22.0 06/07/19
- 2.21.1 → 2.21.4 no changes
- 2.21.0 02/24/19
- 2.19.1 → 2.20.5 no changes
- 2.19.0 09/10/18
- 2.18.1 → 2.18.5 no changes
- 2.18.0 06/21/18
- 2.15.4 → 2.17.6 no changes
- 2.14.6 12/06/19
- 2.13.7 05/22/18
- 2.12.5 09/22/17
- 2.9.5 → 2.11.4 no changes
- 2.8.6 07/30/17
- 2.7.6 07/30/17
- 2.6.7 05/05/17
- 2.5.6 no changes
- 2.4.12 05/05/17
- 2.3.10 no changes
- 2.2.3 09/04/15
- 2.1.4 no changes
- 2.0.5 12/17/14
설명
- 대체 객체 데이터베이스
-
대체 메커니즘을 통해 저장는 다른 객체 데이터베이스로부터 자신의 객체 데이터베이의 일부를 상속받을 수 있으며, 이를 "대체(alternate)"라고 합니다.
- 베어 저장소
-
베어 저장소는 일반적으로
.git
접미사를 가진 적절히 명명된 디렉토리입니다. 이 저장소에는 리비전 관리 대상 파일의 로컬로 체크아웃된 사본이 없습니다. 즉, 일반적으로 숨겨진 `.git`하위 디렉토리에 보통 존재하는 모든 깃 관리 및 제어 파일은 직접적으로 `repository.git`디렉토리에 있으며, 다른 파일은 존재하지 않고 체크아웃되지 않습니다. 일반적으로 공개 저장소의 게시자들은 베어 저장소를 제공합니다. - blob 객체
-
유형이 지정되지 않은 객체, 예: 파일의 내용.
- 분기
-
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.
- 캐시
-
더 이상 사용되지 않음: 인덱스.
- 체인
-
목록의 각 객체에 후속 항목에 대한 참조가 포함된 객체 목록입니다(예: 커밋의 후속 항목은 부모들 중 하나일 수 있습니다. ).
- 변경집합(changeset)
-
BitKeeper/cvsps는 "커밋"을 나타냅니다. 깃은 변경 사항을 저장하지 않고 상태를 나타내기 때문에 깃에서 "changesets"라는 용어를 사용하는 것은 말이 되지 않습니다.
- 체크아웃
-
작업 트리의 전체 또는 일부를 객체 데이터베이스에서 트리 객체나 블롭(blob)으로 업데이트하고, 작업 트리 전체가 새 분기를 가리키도록 되어 있다면 인덱스 와 HEAD를 업데이트하는 동작입니다.
- 체리피킹((커밋) 빼오기)
-
SCM 용어로서 "체리픽(cherry pick)"은 일련의 변경 사항(일반적으로 커밋) 중 일부를 선택하여 다른 코드베이스 위에 새로운 일련의 변경 사항으로 기록하는 것을 의미합니다. Git에서는 "git cherry-pick" 명령을 사용하여 기존 커밋에서 도입된 변경 사항을 추출하고 현재 분기 의 끝을 기준으로 새로운 커밋으로 기록합니다.
- 클린
-
현재 헤드가 참조하는 리비전에 해당하는 경우, 작업 트리 를 클린(clean)하다고 합니다. "dirty"도 참조해주세요.
- 커밋
-
As a noun: A single point in the Git history; the entire history of a project is represented as a set of interrelated commits. The word "commit" is often used by Git in the same places other revision control systems use the words "revision" or "version". Also used as a short hand for commit object.
- 커밋 그래프의 개념, 표현 및 사용법
-
A synonym for the DAG structure formed by the commits in the object database, referenced by branch tips, using their chain of linked commits. This structure is the definitive commit graph. The graph can be represented in other ways, e.g. the "commit-graph" file.
- 커밋-그래프 파일
-
"커밋-그래프"(일반적으로 하이픈으로 구분되는) 파일은 커밋 그래프 탐색을 가속화하기 위한 보조 표현입니다. "commit-graph" 파일은 .git/objects/info 디렉토리나 대체 객체 데이터베이스의 info 디렉토리에 저장됩니다.
- 커밋 객체(commit object)
-
특정 리비전에 대한 부모, 커미터, 작성자, 날짜 및 저장된 리비전의 최상위 디렉토리에 해당하는 트리 객체와 같은 정보를 포함하는 객체를 말합니다.
- 유사 커밋(commit-ish, also committish)
-
A commit object or an object that can be recursively dereferenced to a commit object. The following are all commit-ishes: a commit object, a tag object that points to a commit object, a tag object that points to a tag object that points to a commit object, etc.
- 코어 깃(core Git)
-
깃의 기본적인 자료구조와 유틸리티로, 제한된 소스 코드 관리 도구만을 노출합니다.
- DAG
-
유향 비순환 그래프(Directed Acyclic Graph). 깃에서 커밋 객체들은 방향성이 있는 비순환 그래프인 유향 비순환 그래프를 형성합니다. 이는 커밋 객체들이 부모를 가지고 있기 때문에 방향성을 가지며, 커밋 객체들의 그래프는 사이클이 없습니다(시작과 끝이 같은 객체를 가지는 체인은 없습니다).
- 댕글링 객체(dangling object)
-
도달 불가능한 다른 객체에서도 도달 가능하지 않은 도달 불가능 객체로, 댕글링 객체는 어떠한 참조나 저장소 내에 있는 객체로부터도 참조되지 않는 상태로 존재하는 객체를 말합니다.
- dereference
-
기호 참조 참조: 기호 참조가 가리키는 참조에 접근하는 동작입니다. 재귀적 역참조는 비기호적 참조가 발견될 때까지 결과 참조에 대해 앞서 한 과정을 반복하는 것을 포함합니다.
태그 객체 참조: 객체에 접근하는 동작입니다. 태그는 결과가 지정된 객체 유형(적용이 가능한 경우) 또는 비태그 객체 유형을 가질 때까지 결과 객체에 대한 작업을 반복하여 재귀적으로 역참조됩니다. 태그의 맥락에서 “재귀적 역참조”의 동의어는 껍질입니다.
커밋 객체 참조: 커밋 트리 객체에 접근하는 동작. 커밋은 재귀적으로 역참조될 수 없습니다.
별도로 지정하지 않는 한, Git 명령어 또는 프로토콜의 맥락에서 사용되는 “역참조”는 암시적으로 재귀적입니다.
- 분리된 HEAD(detached HEAD)
-
Normally the HEAD stores the name of a branch, and commands that operate on the history HEAD represents operate on the history leading to the tip of the branch the HEAD points at. However, Git also allows you to check out an arbitrary commit that isn’t necessarily the tip of any particular branch. The HEAD in such a state is called "detached".
Note that commands that operate on the history of the current branch (e.g.
git commit
to build a new history on top of it) still work while the HEAD is detached. They update the HEAD to point at the tip of the updated history without affecting any branch. Commands that update or inquire information about the current branch (e.g.git branch --set-upstream-to
that sets what remote-tracking branch the current branch integrates with) obviously do not work, as there is no (real) current branch to ask about in this state. - 디렉토리(directory)
-
"ls"로 표시되는 리스트 :-)
- 더티(dirty)
- 사악한 병합(evil merge)
-
An evil merge is a merge that introduces changes that do not appear in any parent.
- 정방향 진행(fast-forward)
-
정방향 진행(fast-forward)은 특정한 유형의 병합으로, 현재 가지고 있는 리비전과 동일한 조상을 가진 다른 분기의 변경 사항을 "병합"하는 경우를 말합니다. 이 경우, 새로운 병합 커밋 을 만들지 않고 대신 분기를 병합하는 분기와 동일한 리비전을 가리키도록 업데이트합니다. 이러한 상황은 원격 저장소의 원격 추적 분기에서 자주 발생할 수 있습니다.
- 페치(fetch)
-
Fetching a branch means to get the branch’s head ref from a remote repository, to find out which objects are missing from the local object database, and to get them, too. See also git-fetch[1].
- 파일 시스템(file system)
-
리누스 토르발스는 처음 깃을 설계할 때 사용자 공간 파일 시스템으로 설계했습니다. 즉, 파일과 디렉토리를 보유하기 위한 인프라입니다. 이를 통해 깃의 효율성과 속도를 보장하고 있습니다.
- 깃 아카이브(Git archive)
-
저장소의 동의어 (arch 사용자 대상).
- 깃 파일(gitfile)
-
A plain file
.git
at the root of a working tree that points at the directory that is the real repository. For proper use see git-worktree[1] or git-submodule[1]. For syntax see gitrepository-layout[5]. - 이식(grafts)
-
이식(Grafts)은 커밋에 대한 가짜 조상 정보를 기록함으로써 서로 다른 두 개발 라인을 함께 연할 수 있게 해줍니다. 이렇게 하면 깃이 커밋의 부모 집합이 커밋이 생성될 때 기록된 것과 다른 것처럼 가장할 수 있습니다. `.git/info/grafts`파일을 통해 구성할 수 있습니다.
이식(grafts) 메커니즘은 오래되었고, 저장소 간 객체 전송에 문제를 일으킬 수 있습니다. 같은 작업을 수행하는 더 유연하고 견고한 시스템으로서 git-replace[1]를 참조하세요.
- 해시(hash)
-
Git의 문맥에서 객체명에 대한 동의어.
- 헤드(head)
-
A named reference to the commit at the tip of a branch. Heads are stored in a file in
$GIT_DIR/refs/heads/
directory, except when using packed refs. (See git-pack-refs[1].) - HEAD
-
The current branch. In more detail: Your working tree is normally derived from the state of the tree referred to by HEAD. HEAD is a reference to one of the heads in your repository, except when using a detached HEAD, in which case it directly references an arbitrary commit.
- 헤드 레퍼런스(head ref)
-
헤드와 동의어.
- 훅(hook)
-
여러 깃 명령의 정상적인 실행 중에는 개발자가 기능 또는 확인을 추가할 수 있는 선택적인 스크립트를 호출합니다. 일반적으로 훅(hooks)은 명령이 사전에 확인되고 중단될 수 있도록 하며, 작업이 완료된 후에 후속 알림을 허용합니다. 훅 스크립트는`$GIT_DIR/hooks/`디렉토리에서 찾을 수 있으며, 파일명에서 `.sample`접미사를 제거함으로써 활성화됩니다. 초기 버전의 깃에서는 이것을 실행할 수 있도록 직접 만들어야 했었습니다.
- 인덱스(index)
-
파일의 상태 정보를 포함하고, 내용은 객체로 저장되는 파일의 집합입니다. 인덱스는 작업 트리의 저장된 버전입니다. 사실, 인덱스에는 작업 트리의 두 번째 또는 세 번째 버전을 포함할 수도 있으며, 이는 병합시 사용됩니다.
- 인덱스 엔트리(index entry)
-
인덱스에 저장된 특정 파일에 대한 정보입니다. 인덱스 엔트리는 병합이 시작되었지만 아직 완료되지 않은 경우(즉, 인덱스에 해당 파일의 여러 버전이 포함된 경우) 병합되지 않은 상태일 수 있습니다.
- master
-
기본 개발 분기입니다. 깃 저장소를 생성할 때마다 "master"라는 이름의 분기가 생성되고 활성 분기가 됩니다. 대부분의 경우, 이 분기에는 로컬 개발이 포함되지만, 이는 순수히 관례적인 것일 뿐이며 필수적인 요구사항은 아닙니다.
- 병합(merge)
-
As a verb: To bring the contents of another branch (possibly from an external repository) into the current branch. In the case where the merged-in branch is from a different repository, this is done by first fetching the remote branch and then merging the result into the current branch. This combination of fetch and merge operations is called a pull. Merging is performed by an automatic process that identifies changes made since the branches diverged, and then applies all those changes together. In cases where changes conflict, manual intervention may be required to complete the merge.
As a noun: unless it is a fast-forward, a successful merge results in the creation of a new commit representing the result of the merge, and having as parents the tips of the merged branches. This commit is referred to as a "merge commit", or sometimes just a "merge".
- 객체(object)
-
깃의 저장 단위입니다. 콘텐츠의 SHA-1을 통해 고유하게 식별됩니다. 따라서 객체는 변경될 수 없습니다.
- 객체 데이터베이스(object database)
-
일련의 "객체(objects)"를 저장하며, 각각의 객체는 그 객체명을 통해 식별됩니다. 일반적으로 객체들은`$GIT_DIR/objects/`디렉토리에 저장됩니다.
- 객체 식별자(object identifier, oid)
-
객체명과 동의어.
- 객체명(object name)
-
The unique identifier of an object. The object name is usually represented by a 40 character hexadecimal string. Also colloquially called SHA-1.
- 객체 타입(object type)
-
One of the identifiers "commit", "tree", "tag" or "blob" describing the type of an object.
- 옥토퍼스(octopus)
- orphan
-
아직 존재하지 않는 가지 (즉, 태어나지 않은 가지)에 올라타는 행위입니다. 이러한 작업 후에는 처음 생성된 커밋이 상위 커밋이 아닌 새로운 기록을 시작하는 커밋이 됩니다.
- origin
-
기본 상위 저장소입니다. 대부분의 프로젝트는 추적하는 상위 프로젝트가 최소한 하나 있습니다. 기본적으로 'origin’이 그 목적으로 사용됩니다. 새로운 상위 업데이트는 origin/name-of-upstream-branch라는 이름의 원격 추적 분기로 fetch되며, 이를
git branch -r
명령어를 통해 확인할 수 있습니다. - 오버레이(overlay)
-
Only update and add files to the working directory, but don’t delete them, similar to how cp -R would update the contents in the destination directory. This is the default mode in a checkout when checking out files from the index or a tree-ish. In contrast, no-overlay mode also deletes tracked files not present in the source, similar to rsync --delete.
- 팩(pack)
-
공간을 절약하거나 효율적으로 전송하기 위해 여러 개의 객체를 하나의 파일로 압축한 집합입니다.
- 팩 인덱스(pack index)
-
팩의 객체들의 식별자와 다른 정보들을 포함한 목록입니다. 이는 팩의 내용에 효율적으로 접근하기 위해 도움을 주는 역할을 합니다.
- 경로명세(pathspec)
-
깃 명령어에서 경로를 제한하는 데 사용되는 패턴입니다.
Pathspecs are used on the command line of "git ls-files", "git ls-tree", "git add", "git grep", "git diff", "git checkout", and many other commands to limit the scope of operations to some subset of the tree or working tree. See the documentation of each command for whether paths are relative to the current directory or toplevel. The pathspec syntax is as follows:
-
어떤 경로든 자기 자신과 일치
-
the pathspec up to the last slash represents a directory prefix. The scope of that pathspec is limited to that subtree.
-
the rest of the pathspec is a pattern for the remainder of the pathname. Paths relative to the directory prefix will be matched against that pattern using fnmatch(3); in particular, * and ? can match directory separators.
예를 들어, Documentation/*.jpg는 Documentation 서브트리에 있는 모든 .jpg 파일과 일치합니다. 이는 Documentation/chapter_1/figure_1.jpg를 포함합니다.
A pathspec that begins with a colon
:
has special meaning. In the short form, the leading colon:
is followed by zero or more "magic signature" letters (which optionally is terminated by another colon:
), and the remainder is the pattern to match against the path. The "magic signature" consists of ASCII symbols that are neither alphanumeric, glob, regex special characters nor colon. The optional colon that terminates the "magic signature" can be omitted if the pattern begins with a character that does not belong to "magic signature" symbol set and is not a colon.긴 형식에서는 선행하는 콜론
:
다음에 여는 괄호(
, 영문자로 이루어진 "매직 워드"의 쉼표로 구분된 리스트(0개 이상), 그리고 닫는 괄호 `)`가 옵니다. 그리고 나머지는 경로와 일치시킬 패턴입니다.단순히 콜론만 있는 경로명세는 "경로명세가 없음"을 의미합니다. 이 형식은 다른 경로명세와 결합해서 사용되어서는 안 됩니다.
- top
-
매직 워드인
top
(매직 시그니처:/
)는 패턴이 작업 트리의 루트부터 일치하도록 만듭니다. 이는 현재 작업 중인 디렉토리 내에서 명령을 실행하더라도 적용됩니다. - literal
-
패턴 내의
*
또는 `?`와 같은 와일드카드는 리터럴 문자로 처리됩니다. - icase
-
대소문자 구분 없이 매치.
- glob
-
Git treats the pattern as a shell glob suitable for consumption by fnmatch(3) with the FNM_PATHNAME flag: wildcards in the pattern will not match a / in the pathname. For example, "Documentation/*.html" matches "Documentation/git.html" but not "Documentation/ppc/ppc.html" or "tools/perf/Documentation/perf.html".
패턴 내에서 전체 경로명에 대해 일치하는 경우, 두 개의 연속된 별표("
**
")는 특별한 의미를 가질 수 있습니다:-
슬래시 뒤에 오는 선두의 "
**
"는 모든 디렉토리에서 일치하는 것을 의미합니다. 예를 들어 "**/foo
"는 어디에서나 파일 또는 디렉토리 "foo
"와 일치하며, 패턴 "foo
"와 동일합니다. "**/foo/bar
"는 "foo
" 디렉토리 바로 아래에 있는 어느 곳에서나 파일 또는 디렉토리 "bar
"와 일치합니다. -
말미의 "
/**
"는 그 안에 있는 모든 파일과 매치됩니다. 예를 들어, "abc/**
"는 디렉토리 "abc" 내의 모든 파일에 매치됩니다. 이는.gitignore
파일의 위치를 기준으로 하며, 깊이는 무한입니다. -
말미 이외에서의 "
/**
"는 0개 이상의 디렉토리에 매치됩니다. 예를 들어, "a/**/b
"는 "a/b
", "a/x/b
", "a/x/y/b
"와 같은 식으로 매치됩니다. -
이 이외의 연속된 별표는 무효로 취급됩니다.
글로브 매직과 리터럴 매직은 서로 호환되지 않습니다.
-
- attr
-
After
attr:
comes a space separated list of "attribute requirements", all of which must be met in order for the path to be considered a match; this is in addition to the usual non-magic pathspec pattern matching. See gitattributes[5].패스의 각 속성 요구사항은 다음 중 하나의 형식을 취합니다:
-
"
ATTR
"은 속성 `ATTR`이 설정되어야 함을 요구합니다. -
"
-ATTR
"은 속성 `ATTR`이 설정되지 않아야 함을 요구합니다. -
"
ATTR=VALUE
"는 속성 `ATTR`이 문자열 `VALUE`로 설정되어야 함을 요구합니다. -
"
!ATTR
"은 속성 `ATTR`이 지정되지 않아야 함을 요구합니다.여기서 주의할 점은 트리 객체와 매치시킬 때 속성은 주어진 트리 객체에서 가져오는 것이 아니라, 작업 트리에서 가져온다는 것입니다.
-
- exclude
-
After a path matches any non-exclude pathspec, it will be run through all exclude pathspecs (magic signature:
!
or its synonym^
). If it matches, the path is ignored. When there is no non-exclude pathspec, the exclusion is applied to the result set as if invoked without any pathspec.
-
- 부모(parent)
-
커밋 객체에는 개발 라인에서의 논리적 조상, 즉 그 부모(비어있을 수도 있음) 목록이 포함되어 있습니다.
- peel
- 곡괭이(pickaxe)
-
곡괭이라는 용어는 주어진 텍스트 문자열을 추가하거나 삭제하는 변경 사항을 선택하는 데 도움이 되는 diffcore 루틴의 옵션을 가리킵니다. `--pickaxe-all`옵션을 사용하면 특정 텍스트 줄을 도입하거나 제거한 전체 변경 세트를 볼 수 있습니다. git-diff[1]를 참조해 주세요.
- 배관(plumbing)
-
코어 깃의 애칭.
- 자기(porcelain)
-
코어 깃에 의존하는 프로그램이나 프로그램 모음의 애칭으로, 코어 깃에 대한 고수준 액세스를 제공합니다. Porcelain은 배관보다 더 많은 SCM 인터페이스를 노출합니다.
- 작업트리별 레퍼런스(per-worktree ref)
-
Refs that are per-worktree, rather than global. This is presently only HEAD and any refs that start with
refs/bisect/
, but might later include other unusual refs. - 의사참조(pseudoref)
-
A ref that has different semantics than normal refs. These refs can be read via normal Git commands, but cannot be written to by commands like git-update-ref[1].
The following pseudorefs are known to Git:
-
FETCH_HEAD
is written by git-fetch[1] or git-pull[1]. It may refer to multiple object IDs. Each object ID is annotated with metadata indicating where it was fetched from and its fetch status. -
MERGE_HEAD
is written by git-merge[1] when resolving merge conflicts. It contains all commit IDs which are being merged.
-
- 풀(pull)
-
Pulling a branch means to fetch it and merge it. See also git-pull[1].
- 푸시(push)
-
분기를 푸시(push)하는 것은 원격 저장소에서 해당 분기의 헤드 레퍼런스를 가져와 이를 로컬 분기의 헤드 레퍼런스와 비교하여 조상인지 확인한 후, 조상일 경우 로컬 헤드 레퍼런스로부터 도달 가능한 모든 객체를 원격 객체 데이터베이스에 없는 객체들로 이동시키고, 원격 헤드 레퍼런스를 업데이트하는 것을 의미합니다. 원격 헤드가 로컬 헤드의 조상이 아닌 경우, 푸시는 실패합니다.
- 도달 가능(reachable)
-
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.
- 도달 가능성 비트맵(reachability bitmaps)
-
Reachability bitmaps store information about the reachability of a selected set of commits in a packfile, or a multi-pack index (MIDX), to speed up object search. The bitmaps are stored in a ".bitmap" file. A repository may have at most one bitmap file in use. The bitmap file may belong to either one pack, or the repository’s multi-pack index (if it exists).
- 리베이스(rebase)
-
한 분기에서 베이스로 일련의 변경사항을 다시 적용하고, 해당 브랜치의 헤드를 결과로 재설정하는 작업을 수행합니다.
- 참조(ref)
-
A name that points to an object name or another ref (the latter is called a symbolic ref). For convenience, a ref can sometimes be abbreviated when used as an argument to a Git command; see gitrevisions[7] for details. Refs are stored in the repository.
The ref namespace is hierarchical. Ref names must either start with
refs/
or be located in the root of the hierarchy. For the latter, their name must follow these rules:-
The name consists of only upper-case characters or underscores.
-
The name ends with "
_HEAD
" or is equal to "HEAD
".There are some irregular refs in the root of the hierarchy that do not match these rules. The following list is exhaustive and shall not be extended in the future:
-
AUTO_MERGE
-
BISECT_EXPECTED_REV
-
NOTES_MERGE_PARTIAL
-
NOTES_MERGE_REF
-
MERGE_AUTOSTASH
Different subhierarchies are used for different purposes. For example, the
refs/heads/
hierarchy is used to represent local branches whereas therefs/tags/
hierarchy is used to represent local tags..
-
- 참조 로그(reflog)
-
A reflog shows the local "history" of a ref. In other words, it can tell you what the 3rd last revision in this repository was, and what was the current state in this repository, yesterday 9:14pm. See git-reflog[1] for details.
- 레퍼런스 규범(refspec)
-
A "refspec" is used by fetch and push to describe the mapping between remote ref and local ref. See git-fetch[1] or git-push[1] for details.
- 원격 저장소(remote repository)
-
동일한 프로젝트를 추적하는 데 사용되지만 다른 위치에 있는 저장소입니다. 원격 저장소와 통신하기 위해서는 페치(fetch) 또는 푸시(push)를 참조해 주십시오.
- 원격 추적 분기(remote-tracking branch)
-
다른 저장소에서 변경 사항을 추적하는 데 사용되는 레퍼런스입니다. 일반적으로 refs/remotes/foo/bar’와 같은 형식을 가지며, 이는 'foo’라는 원격 저장소의 'bar 분기를 추적한다는 것을 나타냅니다. 이는 설정된 fetch 레퍼런스 규범의 오른쪽 부분과 일치합니다. 원격 추적 분기에는 직접적인 수정이 포함되어 있거나 해당 분기에 로컬 커밋이 적용되어서는 안 됩니다.
- 저장소(repository)
-
레퍼런스의 모음과 레퍼런스들로부터 도달 가능한 모든 객체를 포함하는 객체 데이터베이스로 구성된 모음입니다. 이는 하나 이상의 자기(porcelains)로부터의 메타 데이터와 함께 제공될 수도 있습니다. 저장소는 대체 매커니즘을 통해 다른 저장소와 객체 데이터베이스를 공유할 수 있습니다.
- resolve
-
자동 병합 작업이 실패한 후 수동으로 수정하는 동작을 의미합니다. 즉, 자동 병합이 남긴 오류를 수동으로 해결하는 것을 말합니다.
- 리비전(revision)
-
커밋(명사)과 동의어.
- rewind
- SCM
-
소스 코드 관리(도구).
- SHA-1
-
“보안 해시 알고리즘 1”; 암호화 해시 함수. Git의 맥락에서 객체명의 동의어로 사용됩니다.
- 얕은 복사
-
대부분 얕은 저장소와 동의어지만, 이 문구를 사용하면 git clone --depth=… 명령을 실행하여 생성되었음을 더 명확히 알 수 있습니다.
- 얕은 저장소
-
얕은 저장소에는 몇몇 커밋의 삭제된 불완전한 기록이 있습니다. (즉, Git은 커밋들이 커밋 객체에 기록되었더라도 부모들을 가지지 않는 것처럼 가장하라고 지시 받습니다.) 이것은 때때로 업스트림에 기록된 실제 기록이 훨씬 더 크더라도 프로젝트의 최신 기록에만 관심이 있을 때 유용합니다. 앝은 저장소는 git-clone[1]의
--depth
옵션을 제공하여 만들어지게 되고 기록은 이후에 git-fetch[1]을 사용하여 심화할 수 있습니다. - 숨김 항목
- 서브 모듈
- 슈퍼프로젝트
-
작업 트리에 있는 다른 프로젝트의 저장소들을 서브 모듈로 참조하는 저장소입니다. 슈퍼 프로젝트는 포함된 서브 모듈들의 커밋 객체들의 이름(사본은 보관하지 않습니다.)에 대해 알고 있습니다.
- 기호 참조
-
기호 참조: SHA-1 ID 자체를 포함하는 대신’ref: refs/some/thing' 형식으로 포함하고 참조될 때, 재귀적으로 역참조합니다. '<<def_HEAD,HEAD'는 기호 참조의 대표적인 예입니다. 기호참조는 git-symbolic-ref[1] 명령으로 조작되어 집니다.
- 태그
-
임의의 유형의 객체(일반적으로 태그는 태그 또는 커밋 객체를 가리킵니다.)를 가리키는 네임스페이스 refs/tags/ 아래의 ' 참조입니다. 헤드와는 대조적으로 태그는 commit 명령어로 업데이트되지 않습니다. Git 태그는 Lisp 태그(Git에서는 객체 타입으로 불립니다)와 아무 관련 없습니다. 태그는 커밋 조상 체인의 특정 지점을 표시하는 데 가장 일반적으로 사용됩니다.
- 태그 객체
-
커밋 객체와 마찬가지로 메세지를 포함할 수 있는 다른 객체를 가리키는 참조를 포함하는 객체입니다. 또한 PGP 서명을 포함할 수 있으며, 이 경우 "서명된 태그 객체"라고 합니다.
- 주제 분기
-
개발자가 개념적인 개발 라인을 식별하기 위해 사용하는 일반적인 Git 브랜치. 브랜치는 매우 쉽고 비용이 저렴하기 때문에, 각각 매우 잘 정의된 개념이나 점진적이지만 관련된 변경 사항을 포함하는 여러 작은 브랜치를 갖는 것이 종종 바람직합니다.
- 트리
- 트리 객체
-
파일 이름과 모드의 목록과 함께 관련된 블롭 및/또는 트리 객체에 대한 참조를 포함하는 객체. 트리는 디렉토리와 동일합니다.
- 유사 트리
-
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.
- unborn
-
HEAD는 아직 존재하지 않으며 커밋이 없는 분기를 가리킬 수 있으며, 이러한 브랜치를 미탄생 분기라고 합니다. 사용자가 미탄생 분기를 접하는 가장 일반적인 방법은 다른 곳에서 복제하지 않고 새로 저장소를 생성하는 경우입니다. 이때 HEAD는 아직 생성되지 않은 main (또는 설정에 따라 master) 분기를 가리키게 됩니다. 또한 일부 작업은 고아 옵션으로 미탄생 분기에 접어들게 할 수 있습니다.
- 병합되지 않은 인덱스
- 접근할 수 없는 객체
- 업스트림 브랜치
-
해당 브랜치에 병합된 기본 브랜치(또는 해당 브랜치는 리베이스된다.) 입니다. 이는 branch.<name>.remote 그리고 branch.<name>.merge를 통해 구성됩니다. 만약 'A’의 업스트림 브랜치가 'origin/B’인 경우 때때로 우리는 "'A’가 'origin/b’를 추적하고 있습니다."라고 말합니다.
- 작업 중인 트리
-
실제 우리의 눈에 보이는 트리입니다. 작업 트리는 일반적으로 헤드 커밋 트리의 내용과 사용자가 만들고 아직 커밋하지 않은 로컬 변경 사항을 포함합니다.
- 작업 트리
-
저장소는 0개 또는 한개 또는 더 많은 작업 트리들이 연결될 수 있습니다. 하나의 "작업 트리"는 "작업 중이 트리"와 저장소 메타데이터로 구성됩니다. 대부분의 단일 저장소의 다른 작업 트리들 간에 공유되고 작업 트리별로 별도로 유지 관리됩니다.(예: 인덱스, HEAD 그리고 MERGE_HEAD와 같은 의사 참조들, 각 작업 트리 참조 및 각 작업 트리의 구성 파일.)
GIT
git[1] 모음의 일부