gitglossary - A Git Glossarygitglossary - Gitの用語集




alternate object database 代替オブジェクトデータベース

Via the alternates mechanism, a repository can inherit part of its object database from another object database, which is called an "alternate".代替メカニズムを介して、リポジトリはそのオブジェクトデータベースの一部を別のオブジェクトデータベースから継承できます。これを「代替」と呼びます。

bare repository ベアリポジトリ

A bare repository is normally an appropriately named directory with a .git suffix that does not have a locally checked-out copy of any of the files under revision control. That is, all of the Git administrative and control files that would normally be present in the hidden .git sub-directory are directly present in the repository.git directory instead, and no other files are present and checked out. Usually publishers of public repositories make bare repositories available.ベアリポジトリは通常、リビジョン管理下にあるファイルのうちローカルにチェックアウトされたコピーを持たない接尾辞を持つ適切な名前のディレクトリ.gitです。つまり、隠し.gitサブディレクトリに通常存在するGitの管理ファイルと制御ファイルはすべてディレクトリに直接存在し、repository.git他のファイルは存在せず、チェックアウトもされません。通常、パブリックリポジトリの発行者は、裸のリポジトリを利用可能にします。

blob object BLOBオブジェクト

Untyped object, e.g. the contents of a file.型なしオブジェクト、例えばファイルの内容

branch ブランチ

A "branch" is an active 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.「ブランチ」は活発な開発ラインです。ブランチに対する最新のコミットは、そのブランチのチップと呼ばれます。ブランチの先端はブランチヘッドによって参照されます。ブランチヘッドは、ブランチで追加の開発が行われるにつれて前進します。単一のGit リポジトリは任意の数のブランチを追跡することができますが、あなたの作業ツリーはそれらのうちの1つのみ( "現在"または "チェックアウト")に関連付けられ、HEADはそのブランチを指します。

cache キャッシュ

Obsolete for: index.indexでは廃止されました。


A list of objects, where each object in the list contains a reference to its successor (for example, the successor of a commit could be one of its parents).オブジェクトのリスト。リスト内の各オブジェクトには、その後続オブジェクトへの参照が含まれています(たとえば、コミットの後続オブジェクトは、その親クラスの 1つです)。

changeset チェンジセット

BitKeeper/cvsps speak for "commit". Since Git does not store changes, but states, it really does not make sense to use the term "changesets" with Git.BitKeeper / cvspsは " commit "のことを言っています。Gitは変更を保存しませんが、Gitで「チェンジセット」という用語を使用することは意味がありません。

checkout チェックアウト

The action of updating all or part of the working tree with a tree object or blob from the object database, and updating the index and HEAD if the whole working tree has been pointed at a new branch.全部または一部を更新するアクション作業ツリーをしてツリーオブジェクトまたはBLOBからオブジェクトデータベース、および更新インデックスHEADの全作業ツリーが新しいで指摘されている場合は、分岐

cherry-picking さくらんぼ狩り

In SCM jargon, "cherry pick" means to choose a subset of changes out of a series of changes (typically commits) and record them as a new series of changes on top of a different codebase. In Git, this is performed by the "git cherry-pick" command to extract the change introduced by an existing commit and to record it based on the tip of the current branch as a new commit.SCMの専門用語、「桜のピックは、」一連の変更(一般的にコミット)のうち、変更のサブセットを選択し、異なるコードベースの上に変化の新シリーズとしてそれらを記録することを意味します。Gitでは、これは "git cherry-pick"コマンドによって実行され、既存のコミットによって導入された変更を抽出し、現在のブランチの先端に基づいて新しいコミットとしてそれを記録します。

clean クリーン

A working tree is clean, if it corresponds to the revision referenced by the current head. Also see "dirty".作業ツリーは、それが対応する場合、クリーンで改正現在で参照されるヘッド。「汚れた」も見てください。

commit コミット

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.名詞として:Gitの歴史の中での一点。プロジェクトの全履歴は、相互に関連する一連のコミットとして表されます。「コミット」という言葉は、他のリビジョン管理システムが「リビジョン」や「バージョン」という言葉を使うのと同じ場所でGitによってしばしば使われます。コミットオブジェクトの省略形としても使用されます

As a verb: The action of storing a new snapshot of the project’s state in the Git history, by creating a new commit representing the current state of the index and advancing HEAD to point at the new commit.動詞として:インデックスの現在の状態を表す新しいコミットを作成し、その新しいコミットを指すようにHEADを進めて、Gitの履歴にプロジェクトの状態の新しいスナップショットを保存するアクション。

commit object コミットオブジェクト

An object which contains the information about a particular revision, such as parents, committer, author, date and the tree object which corresponds to the top directory of the stored revision.オブジェクト特定に関する情報が含まリビジョンなど、両親、コミッター、著者、日付、木オブジェクト上部に対応するディレクトリに格納された改正。

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 コアGit

Fundamental data structures and utilities of Git. Exposes only limited source code management tools.Gitの基本的なデータ構造と効用 限られたソースコード管理ツールのみを公開します。


Directed acyclic graph. The commit objects form a directed acyclic graph, because they have parents (directed), and the graph of commit objects is acyclic (there is no chain which begins and ends with the same object).有向非巡回グラフ オブジェクトがコミットそれらは親(有向)を有し、及びコミットオブジェクトのグラフは、(全く存在しない非環式であるため、非循環有向グラフを形成する開始し、同じで終わるオブジェクトが)。

dangling object ぶら下がっているオブジェクト

An unreachable object which is not reachable even from other unreachable objects; a dangling object has no references to it from any reference or object in the repository.到達不能なオブジェクトではない到達可能であっても、他の到達不能オブジェクトから。ダングリングオブジェクトは、リポジトリ内の参照またはオブジェクトから参照されていません。

detached HEAD 切り離された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".通常、HEADブランチの名前を格納し、履歴HEADを操作するコマンドは、HEADが指すブランチの先端に至るまでの履歴を操作します。しかし、Gitでは、必ずしも特定のブランチの先端ではない任意のコミットチェックアウトすることもできます。このような状態のHEADを「切り離し」と呼びます。

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.現在のブランチの履歴を操作するコマンド(例えば、その上にgit commit新しい履歴を作成する)は、HEADが切り離されている間も機能します。彼らは、ブランチに影響を与えずに更新された履歴の先端を指すようにHEADを更新します。その更新をコマンドまたは情報お問い合わせについて(例えば現在のブランチgit branch --set-upstream-to、この状態では約尋ねるなし(本当の)現在のブランチがないので、明らかに、動作しない現在のブランチは、と統合リモート追跡ブランチは何を設定します)。

directory ディレクトリ

The list you get with "ls" :-)あなたが "ls"で手に入れたリスト:-)

dirty 汚れた

A working tree is said to be "dirty" if it contains modifications which have not been committed to the current branch.作業中のツリーに現在のブランチにコミットされていない変更が含まれている場合、その作業ツリーは「ダーティ」であると言われます。

evil merge 邪悪な併合

An evil merge is a merge that introduces changes that do not appear in any parent.悪マージは、どのにも現れない変更を導入するマージです。

fast-forward 早送り

A fast-forward is a special type of merge where you have a revision and you are "merging" another branch's changes that happen to be a descendant of what you have. In such a case, you do not make a new merge commit but instead just update to his revision. This will happen frequently on a remote-tracking branch of a remote repository.早送りは、リビジョンを持っていて、自分の持っているものの子孫になっている別のブランチの変更を「マージ」している特別なタイプのマージです。そのような場合、あなたは新しいマージをコミットするのではなく、単に彼のリビジョンに更新します。これは、リモートリポジトリのリモート追跡ブランチで頻繁に発生します

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].ブランチを取得することは、ブランチのヘッドリファレンスをリモートリポジトリから取得すること、どのオブジェクトがローカルオブジェクトデータベースから欠けているかを見つけること、そしてそれらも取得することを意味します。git-fetch [1]もご覧ください。

file system ファイルシステム

Linus Torvalds originally designed Git to be a user space file system, i.e. the infrastructure to hold files and directories. That ensured the efficiency and speed of Git.Linus TorvaldsはもともとGitをユーザースペースファイルシステム、つまりファイルとディレクトリを保持するためのインフラストラクチャとして設計しました。それはGitの効率とスピードを保証しました。

Git archive Gitアーカイブ

Synonym for repository (for arch people).リポジトリの同義語(arch people用)。


A plain file .git at the root of a working tree that points at the directory that is the real repository..git実際のリポジトリであるディレクトリを指す作業ツリーのルートにあるプレーンファイル。

grafts グラフト

Grafts enables two otherwise different lines of development to be joined together by recording fake ancestry information for commits. This way you can make Git pretend the set of parents a commit has is different from what was recorded when the commit was created. Configured via the .git/info/grafts file.移植片は、コミットのために偽の祖先情報を記録することによって、2つの異なる開発ラインを結合することを可能にします。あなたはGitが一連のふりをすることができます。この方法で親を A コミットはコミットを作成したときに記録されたものと異なっています。.git/info/graftsファイルで設定します。

Note that the grafts mechanism is outdated and can lead to problems transferring objects between repositories; see git-replace[1] for a more flexible and robust system to do the same thing.移植機構は古くなっており、リポジトリ間でオブジェクトを転送する際に問題が発生する可能性があることに注意してください。同じことをするためのより柔軟で堅牢なシステムについてはgit-replace [1]を見てください。

hash ハッシュ

In Git’s context, synonym for object name.Gitの文脈では、オブジェクト名の同義語。


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].)名前付き参照コミットの先端に$GIT_DIR/refs/heads/パック参照を使用する場合を除き、ヘッドはディレクトリ内のファイルに格納されます。(git-pack-refs [1]を見てください。)


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によって参照されるツリーの状態から派生したものです。HEADは、デタッチされたHEADを使用する場合を除き、リポジトリ内のいずれかのヘッドへの参照です。その場合は、任意のコミットを直接参照します。

head ref ヘッドレフ

A synonym for head.の同義語。

hook フック

During the normal execution of several Git commands, call-outs are made to optional scripts that allow a developer to add functionality or checking. Typically, the hooks allow for a command to be pre-verified and potentially aborted, and allow for a post-notification after the operation is done. The hook scripts are found in the $GIT_DIR/hooks/ directory, and are enabled by simply removing the .sample suffix from the filename. In earlier versions of Git you had to make them executable.いくつかのGitコマンドの通常の実行中に、開発者が機能やチェックを追加することを可能にするオプションのスクリプトに対してコールアウトが行われます。通常、フックを使用すると、コマンドを事前に検証して中止することができ、操作が完了した後に通知を送信できます。フックスクリプトは$GIT_DIR/hooks/ディレクトリにあり.sample、ファイル名から接尾辞を削除するだけで有効になります。Gitの以前のバージョンでは、それらを実行可能にしなければなりませんでした。

index 索引

A collection of files with stat information, whose contents are stored as objects. The index is a stored version of your working tree. Truth be told, it can also contain a second, and even a third version of a working tree, which are used when merging.内容がオブジェクトとして保管されている、統計情報を持つファイルのコレクション。インデックスは作業ツリーの保存バージョンです。実は、マージ時に使用される作業ツリーの2番目のバージョン、さらには3番目のバージョンを含めることもできます。

index entry インデックスエントリ

The information regarding a particular file, stored in the index. An index entry can be unmerged, if a merge was started, but not yet finished (i.e. if the index contains multiple versions of that file).インデックスに格納されている特定のファイルに関する情報。マージが開始されたがまだ終了していない場合(つまり、インデックスにそのファイルの複数のバージョンが含まれている場合)、インデックスエントリはマージされないことがあります。

master マスター

The default development branch. Whenever you create a Git repository, a branch named "master" is created, and becomes the active branch. In most cases, this contains the local development, though that is purely by convention and is not required.デフォルトの開発ブランチ。Git リポジトリを作成すると必ず"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".名詞として:早送りでない限り、成功したマージはマージの結果表す新しいコミットの作成をもたらし、マージされたブランチのヒントをとして持ちます。このコミットは「マージコミット」または単に「マージ」と呼ばれます。


The unit of storage in Git. It is uniquely identified by the SHA-1 of its contents. Consequently, an object can not be changed.Gitのストレージの単位。内容のSHA-1によって一意に識別されます。したがって、オブジェクトを変更することはできません。

object database オブジェクトデータベース

Stores a set of "objects", and an individual object is identified by its object name. The objects usually live in $GIT_DIR/objects/.一連の「オブジェクト」を格納し、個々のオブジェクトはそのオブジェクト名によって識別されます。オブジェクトは通常住んでい$GIT_DIR/objects/ます。

object identifier オブジェクト識別子

Synonym for object name.同義語オブジェクト名

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.オブジェクトの一意の識別子。オブジェクト名は通常40文字の16進数ストリングで表されます。口語的にはSHA-1とも呼ばれます。

object type オブジェクトタイプ

One of the identifiers "commit", "tree", "tag" or "blob" describing the type of an object.オブジェクトのタイプを記述する識別子 " commit "、 " tree "、 " tag "、または " blob "の1つ。

octopus たこ

To merge more than two branches.するにマージつ以上の枝を

origin 原点

The default upstream repository. Most projects have at least one upstream project which they track. By default origin is used for that purpose. New upstream updates will be fetched into remote-tracking branches named origin/name-of-upstream-branch, which you can see using git branch -r.デフォルトの上流リポジトリ。ほとんどのプロジェクトには、追跡する上流プロジェクトが少なくとも1つあります。デフォルトでは原点がその目的のために使われます。新しいアップストリームアップデートはorigin / name-of-upstream-branchという名前のリモートトラッキングブランチに取り込まれますgit branch -r

pack パック

A set of objects which have been compressed into one file (to save space or to transmit them efficiently).1つのファイルに圧縮された一連のオブジェクト(スペースを節約するため、またはそれらを効率的に伝送するため)。

pack index パックインデックス

The list of identifiers, and other information, of the objects in a pack, to assist in efficiently accessing the contents of a pack.パックの内容への効率的なアクセスを支援するための、パック内のオブジェクトのIDのリスト、およびその他の情報。

pathspec パススペック

Pattern used to limit paths in Git commands.Gitコマンドでパスを制限するために使用されるパターン。

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 worktree. See the documentation of each command for whether paths are relative to the current directory or toplevel. The pathspec syntax is as follows:パス指定は "git ls-files"、 "git ls-tree"、 "git add"、 "git grep"、 "git diff"、 "git checkout"などのコマンドラインで使用され、範囲を制限します。ツリーまたはワークツリーの一部のサブセットに対する操作 パスが現在のディレクトリに対する相対パスかトップレベルに対する相対パスかについては、各コマンドのドキュメントを参照してください。pathspecの構文は次のとおりです。

  • any path matches itself任意のパスがそれ自体に一致

  • the pathspec up to the last slash represents a directory prefix. The scope of that pathspec is limited to that subtree.最後のスラッシュまでのpathspecはディレクトリプレフィックスを表します。そのpathspecの範囲はそのサブツリーに制限されます。

  • 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.pathspecの残りの部分は、残りのパス名のパターンです。ディレクトリプレフィックスに対する相対パスは、fnmatch(3)を使用してそのパターンと照合されます。特に、* できるディレクトリの区切りと一致します。

For example, Documentation/*.jpg will match all .jpg files in the Documentation subtree, including Documentation/chapter_1/figure_1.jpg.たとえば、Documentation / *。jpgは、Documentation / chapter_1 / figure_1.jpgを含む、Documentationサブツリー内のすべての.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個以上の「マジックシグネチャ」文字(オプションで別のコロンで終わる:)が続き、残りがパスと照合するためのパターンです。「マジックシグネチャ」は、英数字、グロブ、正規表現の特殊文字でもコロンでもないASCIIシンボルで構成されています。パターンが「マジックシグネチャ」シンボルセットに属さずコロンではない文字で始まる場合は、「マジックシグネチャ」を終了させるオプションのコロンを省略することができます。

In the long form, the leading colon : is followed by an open parenthesis (, a comma-separated list of zero or more "magic words", and a close parentheses ), and the remainder is the pattern to match against the path.長い形式では、先頭のコロンの:後に開き括弧(、0個以上の「マジックワード」のコンマ区切りリスト、および閉じ括弧が続き)、残りはパスと突き合わせるパターンです。

A pathspec with only a colon means "there is no pathspec". This form should not be combined with other pathspec.コロンだけのパス指定は、「パス指定がない」という意味です。この形式は他のパス指定と組み合わせるべきではありません。


The magic word top (magic signature: /) makes the pattern match from the root of the working tree, even when you are running the command from inside a subdirectory.マジックワードtop(magic signature /:)は、サブディレクトリの内側からコマンドを実行している場合でも、作業ツリーのルートからパターンを一致させます。

literal リテラル

Wildcards in the pattern such as * or ? are treated as literal characters.*またはのようなパターン内のワイルドカードは、?リテラル文字として扱われます。


Case insensitive match.大文字と小文字を区別しない

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".GitはパターンをFNM_PATHNAMEフラグ付きのfnmatch(3)による消費に適したシェルグロブとして扱います。パターン内のワイルドカードはパス名内の/と一致しません。たとえば、「Documentation / *。html」は「Documentation / git.html」と一致しますが、「Documentation / ppc / ppc.html」または「tools / perf / Documentation / perf.html」とは一致しません。

Two consecutive asterisks ("**") in patterns matched against full pathname may have special meaning:**フルパス名と一致するパターン内の2つの連続したアスタリスク( " ")は、特別な意味を持つことがあります。

  • A leading "**" followed by a slash means match in all directories. For example, "**/foo" matches file or directory "foo" anywhere, the same as pattern "foo". "**/foo/bar" matches file or directory "bar" anywhere that is directly under directory "foo".先頭に " **"とそれに続くスラッシュはすべてのディレクトリで一致することを意味します。例えば、 " **/foo" fooはパターン " foo" と同じようにどこでもファイルやディレクトリにマッチします。 " **/foo/barディレクトリ " bar"の直下にあるファイルやディレクトリ" "にマッチしますfoo

  • A trailing "/**" matches everything inside. For example, "abc/**" matches all files inside directory "abc", relative to the location of the .gitignore file, with infinite depth.末尾の " /**"は内部のすべてに一致します。たとえば、 " abc/**"は、.gitignoreファイルの場所を基準にして、ディレクトリ "abc"内のすべてのファイルに無限の深さで一致します。

  • A slash followed by two consecutive asterisks then a slash matches zero or more directories. For example, "a/**/b" matches "a/b", "a/x/b", "a/x/y/b" and so on.スラッシュの後に2つの連続したアスタリスクが続く場合、スラッシュはゼロ個以上のディレクトリに一致します。たとえば、 " a/**/b"は " a/b"、 " a/x/b"、 " a/x/y/b"などに一致します。

  • Other consecutive asterisks are considered invalid.他の連続するアスタリスクは無効と見なされます。

    Glob magic is incompatible with literal magic.グロブマジックはリテラルマジックと互換性がありません。


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:に、スペースで区切られた「属性要件」のリストが続きます。パスが一致と見なされるためには、すべてが満たされている必要があります。これは通常のマジックでないpathspecパターンマッチングに追加されています。gitattributes [5]を参照してください。

Each of the attribute requirements for the path takes one of these forms:パスの各属性要件は、次のいずれかの形式を取ります。

  • "ATTR" requires that the attribute ATTR be set." ATTR"は属性ATTRを設定することを要求します。

  • "-ATTR" requires that the attribute ATTR be unset." -ATTR"は属性ATTRを設定解除する必要があります。

  • "ATTR=VALUE" requires that the attribute ATTR be set to the string VALUE." ATTR=VALUE"では、属性をATTR文字列に設定する必要がありますVALUE

  • "!ATTR" requires that the attribute ATTR be unspecified." !ATTR"は属性ATTRを指定しないことを要求します。

    Note that when matching against a tree object, attributes are still obtained from working tree, not from the given tree object.ツリーオブジェクトと照合するとき、属性は与えられたツリーオブジェクトからではなく、作業ツリーから得られます。

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.パスが非除外パス指定と一致すると、そのパスはすべての除外パス指定(マジックシグニチャー:!またはその同義語^)を通過します。一致した場合、パスは無視されます。非除外パス指定がない場合は、パス指定なしで呼び出された場合と同様に、除外が結果セットに適用されます。


A commit object contains a (possibly empty) list of the logical predecessor(s) in the line of development, i.e. its parents.コミットオブジェクトは、その親、つまり、開発のラインで論理的な前任者(複数可)の(おそらく空の)リストが含まれています。

pickaxe つるはし

The term pickaxe refers to an option to the diffcore routines that help select changes that add or delete a given text string. With the --pickaxe-all option, it can be used to view the full changeset that introduced or removed, say, a particular line of text. See git-diff[1].つるはしという用語は、与えられたテキスト文字列を追加または削除する変更を選択するのを助けるdiffcoreルーチンへのオプションを指します。この--pickaxe-allオプションを使用すると、特定の行のテキストなど、導入または削除された完全なチェンジセットを表示するために使用できます。git-diff [1]を参照してください。

plumbing 配管工事

Cute name for core Git.コアGitのかわいい名前。

porcelain 磁器

Cute name for programs and program suites depending on core Git, presenting a high level access to core Git. Porcelains expose more of a SCM interface than the plumbing.コアGitに依存するプログラムやプログラムスイートのかわいい名前で、コアGitへの高レベルのアクセスを提供します。磁器は配管よりも多くの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.パーいる参考文献worktreeではなく、グローバルな。これは現在のところHEADとそれから始まるすべての参照ですがrefs/bisect/、後に他の異常な参照を含む可能性があります。

pseudoref 疑似

Pseudorefs are a class of files under $GIT_DIR which behave like refs for the purposes of rev-parse, but which are treated specially by git. Pseudorefs both have names that are all-caps, and always start with a line consisting of a SHA-1 followed by whitespace. So, HEAD is not a pseudoref, because it is sometimes a symbolic ref. They might optionally contain some additional data. MERGE_HEAD and CHERRY_PICK_HEAD are examples. Unlike per-worktree refs, these files cannot be symbolic refs, and never have reflogs. They also cannot be updated through the normal ref update machinery. Instead, they are updated by directly writing to the files. However, they can be read as if they were refs, so git rev-parse MERGE_HEAD will work.擬似参照は$GIT_DIRrev-parseの目的のためにrefのように振舞うファイルのクラスですが、gitによって特別に扱われます。疑似参照は両方ともオールキャップの名前を持ち、常にSHA-1とそれに続く空白からなる行で始まります。そのため、HEADは擬似参照ではありません。シンボリック参照であることがあるからです。それらはオプションでいくつかの追加データを含むかもしれません。MERGE_HEADCHERRY_PICK_HEADは例です。ワークツリーごとの参照とは異なり、これらのファイルはシンボリック参照にはできず、また参照ログを持つこともできません。それらはまた、通常のref更新機構を通して更新することはできません。代わりに、ファイルに直接書き込むことによって更新されます。しかし、それらはあたかもそれらがrefであったかのように読むことができますので、うまくいきgit rev-parse MERGE_HEADます。

pull 引く

Pulling a branch means to fetch it and merge it. See also git-pull[1].ブランチを引っ張ることはそれを取ってきてマージすることを意味します。git-pull [1]もご覧ください。

push 押す

Pushing a branch means to get the branch’s head ref from a remote repository, find out if it is an ancestor to the branch’s local head ref, and in that case, putting all objects, which are reachable from the local head ref, and which are missing from the remote repository, into the remote object database, and updating the remote head ref. If the remote head is not an ancestor to the local head, the push fails.ブランチをプッシュするとは、リモートリポジトリからブランチのヘッドリファレンスを取得し、それがブランチのローカルヘッドリファレンスの先祖であるかどうかを調べ、その場合、ローカルヘッドリファレンスから到達可能なすべてのオブジェクトを入れることです。リモートリポジトリからリモートオブジェクトデータベースに欠落しており、リモートヘッド参照を更新しています。リモートヘッドがローカルヘッドの先祖ではない場合、プッシュは失敗します。

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.特定のコミットのすべての先祖はそのコミットから「到達可能」であると言われます。より一般的には、1つのオブジェクトは、私たちがすることによって、他の1に達することができるならば、別のから到達可能であるチェーンは以下のタグを何でも彼らタグに、コミット両親や樹木、およびに木やにしみ彼らは含まれています。

rebase リベース

To reapply a series of changes from a branch to a different base, and reset the head of that branch to the result.ブランチから別のベースに一連の変更を再適用し、そのブランチの先頭を結果にリセットする。

ref 参照

A name that begins with refs/ (e.g. refs/heads/master) 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.オブジェクト名または別の参照を指す名前refs/(例:)で始まる名前(後者はシンボリック参照と呼ばれます)。便宜上、Gitコマンドの引数としてrefを使用した場合、refを省略することができます。詳細はgitrevisions [7]を見てください。参照はリポジトリに格納されていますrefs/heads/master

The ref namespace is hierarchical. Different subhierarchies are used for different purposes (e.g. the refs/heads/ hierarchy is used to represent local branches).ref名前空間は階層的です。さまざまなサブrefs/heads/階層がさまざまな目的に使用されます(たとえば、階層はローカルブランチを表すために使用されます)。

There are a few special-purpose refs that do not begin with refs/. The most notable example is HEAD.で始まらない特別な目的の参照がいくつかありますrefs/。最も注目すべき例はHEADです。

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.reflogはrefのローカルの "歴史"を示します。言い換えれば、それはあなたを伝えることができるもので3番目に最後のリビジョンこのリポジトリがあって、中に現在の状態何だったこの昨日21:14、リポジトリ。詳細はgit-reflog [1]を見てください。

refspec 参照仕様

A "refspec" is used by fetch and push to describe the mapping between remote ref and local ref."refspec"は、リモート参照とローカル参照の間のマッピングを記述するために、フェッチプッシュによって使用されます。

remote repository リモートリポジトリ

A repository which is used to track the same project but resides somewhere else. To communicate with remotes, see fetch or push.同じプロジェクトを追跡するために使用されますが、他の場所に存在するリポジトリ。リモートと通信するには、フェッチまたはプッシュを参照してください。

remote-tracking branch リモートトラッキングブランチ

A ref that is used to follow changes from another repository. It typically looks like refs/remotes/foo/bar (indicating that it tracks a branch named bar in a remote named foo), and matches the right-hand-side of a configured fetch refspec. A remote-tracking branch should not contain direct modifications or have local commits made to it.REF別からの変更に従うために使用されるリポジトリを。それは、典型的には、のように見えるレフリー/リモコン/ fooの/バー(これは名前のブランチを追跡ことを示すバーリモートという名前でFOOを)、およびフェッチ構成されたの右辺と一致するrefspecを。リモートトラッキングブランチは直接の修正を含んだり、ローカルコミットをしたりするべきではありません。

repository リポジトリ

A collection of refs together with an object database containing all objects which are reachable from the refs, possibly accompanied by meta data from one or more porcelains. A repository can share an object database with other repositories via alternates mechanism.参照から到達可能なすべてのオブジェクトを含むオブジェクトデータベースとともに参照のコレクション。おそらく1つ以上の磁器からのメタデータが付随します。リポジトリは代替メカニズムを介して他のリポジトリとオブジェクトデータベースを共有できます。

resolve 解決する

The action of fixing up manually what a failed automatic merge left behind.失敗した自動マージが残したものを手動で修正するアクション。

revision リビジョン

Synonym for commit (the noun).同義語コミット(名詞)。

rewind 巻き戻す

To throw away part of the development, i.e. to assign the head to an earlier revision.開発の一部を捨てること、すなわち、ヘッドを以前のリビジョンに割り当てること。


Source code management (tool).ソースコード管理(ツール)


"Secure Hash Algorithm 1"; a cryptographic hash function. In the context of Git used as a synonym for object name."セキュアハッシュアルゴリズム1"; 暗号化ハッシュ関数 Gitのコンテキストではオブジェクト名の同義語として使用されます

shallow clone 浅いクローン

Mostly a synonym to shallow repository but the phrase makes it more explicit that it was created by running git clone --depth=... command.ほとんど浅いリポジトリと同義語ですが、フレーズはそれがgit clone --depth=...command を実行することによって作成されたことをより明確にします。

shallow repository 浅いリポジトリ

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].浅いリポジトリには不完全な履歴があり、そのコミットのいくつかには親が焼灼されています(つまり、Gitはコミットオブジェクトに記録されていても、これらのコミットには親がいないように見せかけます)。これは、上流で記録された実際の履歴がはるかに大きい場合でも、最近のプロジェクトの履歴のみに関心がある場合に便利です。浅いリポジトリはgit-clone [1]--depthオプションを与えることで作成され、その歴史は後でgit-fetch [1]で深めることができます。

stash entry 隠しエントリ

An object used to temporarily store the contents of a dirty working directory and the index for future reuse.オブジェクトは、一時的の内容を格納するために使用汚い作業ディレクトリおよび将来の再利用のためのインデックスを。

submodule サブモジュール

A repository that holds the history of a separate project inside another repository (the latter of which is called superproject).リポジトリの他のリポジトリ(と呼ばれる後者の内部に別のプロジェクトの履歴を保持している親プロジェクト)。

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.シンボリックリファレンス:SHA-1 id自体を含める代わりに、フォーマットはref:refs / some / thingであり、参照されると、この参照を再帰的に参照します。HEADはsymrefの代表的な例です。シンボリック参照はgit-symbolic-ref [1]コマンドで操作します。

tag タグ

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.任意の型のオブジェクトを指す名前空間の下の参照refs/tags/(通常、タグはタグまたはコミットオブジェクトを指します)。ヘッドとは対照的に、タグはcommitコマンドによって更新されません。GitタグはLispタグとは何の関係もありません(これはGitのコンテキストではオブジェクト型と呼ばれます)。タグは、コミット先祖チェーン内の特定のポイントをマークするために最も一般的に使用されます。

tag object タグオブジェクト

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".オブジェクト含むREF同じようにメッセージを含めることができる別のオブジェクトを指して、コミットオブジェクトを。それはまた(PGP)署名を含むことができ、その場合それは「署名されたタグオブジェクト」と呼ばれます。

topic branch トピックブランチ

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.概念的な開発ラインを識別するために開発者によって使用される通常のGit ブランチ。ブランチは非常に簡単で安価なので、それぞれが非常に明確に定義された概念または小さな増分的でありながら関連する変更を含むいくつかの小さなブランチを持つことがしばしば望ましいです。


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).いずれかの作業ツリーまたはツリーオブジェクト依存と共にブロブとツリーオブジェクト(作業ツリーのすなわち格納された表現)。

tree object ツリーオブジェクト

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.オブジェクトに関連するブロブおよび/またはツリーオブジェクトへのREFと一緒にファイル名とモードの一覧を含みます。ツリーは同等ですディレクトリ

tree-ish (also treeish) 木っぽい

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.ツリーオブジェクトまたはオブジェクトを再帰的にツリーオブジェクトに逆参照することができます。コミットオブジェクトを間接参照すると、そのリビジョンのトップディレクトリに対応するツリーオブジェクトが得られます。以下はすべてツリーイッシュです:コミット風、ツリーオブジェクト、ツリーオブジェクトを指すタグオブジェクト、ツリーオブジェクトを指すタグオブジェクトを指すタグオブジェクトなど

unmerged index マージされていないインデックス

An index which contains unmerged index entries.インデックスマージされていない含まれているインデックスのエントリを

unreachable object 到達不能なオブジェクト

An object which is not reachable from a branch, tag, or any other reference.オブジェクトない到達から分岐タグ、または任意の他の参照。

upstream branch 上流支店

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".問題となっているブランチにマージされているデフォルトのブランチ(または問題となっているブランチがリベースされている)。それはbranch。<name> .remoteとbranch。<name> .mergeを介して設定されます。Aの上流のブランチがorigin / Bの場合、 " Aはtracking origin / Bを追跡している"と言うことがあります。

working tree ワーキングツリー

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.実際にチェックアウトされたファイルのツリー 作業ツリーは通常、HEADコミットのツリーの内容と、あなたが行ったがまだコミットしていないローカルな変更を含みます。


gittutorial[7], gittutorial-2[7], gitcvs-migration[7], giteveryday[7], The Git User’s Manualgittutorial [7]gittutorial-2 [7]gitcvs-migration [7]giteveryday [7]Gitユーザーマニュアル


Part of the git[1] suite一部のgit [1]スイート