$ git bisect reset <commit>+
$ git bisect reset <commit>
A working tree is said to be \"dirty\" if\nit contains modifications which have not been committed to the current\nbranch.
", "evil merge": "An evil merge is a merge that introduces changes that\ndo not appear in any parent.
", "fast-forward": "A fast-forward is a special type of merge where you have a\nrevision and you are \"merging\" another\nbranch's changes that happen to be a descendant of what\nyou have. In such a case, you do not make a new merge\ncommit but instead just update your branch to point at the same\nrevision as the branch you are merging. This will happen frequently on a\nremote-tracking branch of a remote\nrepository.
", - "fetch": "Fetching a branch means to get the\nbranch’s head ref from a remote\nrepository, to find out which objects are\nmissing from the local object database,\nand to get them, too. See also linkgit:git-fetch[1].
", + "fetch": "Fetching a branch means to get the\nbranch’s head ref from a remote\nrepository, to find out which objects are\nmissing from the local object database,\nand to get them, too. See also git-fetch[1].
", "file system": "Linus Torvalds originally designed Git to be a user space file system,\ni.e. the infrastructure to hold files and directories. That ensured the\nefficiency and speed of Git.
", "Git archive": "Synonym for repository (for arch people).
", - "gitfile": "A plain file .git at the root of a working tree that\npoints at the directory that is the real repository.\nFor proper use see linkgit:git-worktree[1] or linkgit:git-submodule[1].\nFor syntax see linkgit:gitrepository-layout[5].
Grafts enable two otherwise different lines of development to be joined\ntogether by recording fake ancestry information for commits. This way\nyou can make Git pretend the set of parents a commit has\nis different from what was recorded when the commit was\ncreated. Configured via the .git/info/grafts file.
Note that the grafts mechanism is outdated and can lead to problems\ntransferring objects between repositories; see linkgit:git-replace[1]\nfor a more flexible and robust system to do the same thing.
\nA plain file .git at the root of a working tree that\npoints at the directory that is the real repository.\nFor proper use see git-worktree[1] or git-submodule[1].\nFor syntax see gitrepository-layout[5].
Grafts enable two otherwise different lines of development to be joined\ntogether by recording fake ancestry information for commits. This way\nyou can make Git pretend the set of parents a commit has\nis different from what was recorded when the commit was\ncreated. Configured via the .git/info/grafts file.
Note that the grafts mechanism is outdated and can lead to problems\ntransferring objects between repositories; see git-replace[1]\nfor a more flexible and robust system to do the same thing.
\nIn Git’s context, synonym for object name.
", - "head": "A named reference to the commit at the tip of a\nbranch. Heads are stored in a file in\n$GIT_DIR/refs/heads/ directory, except when using packed refs. (See\nlinkgit:git-pack-refs[1].)
A named reference to the commit at the tip of a\nbranch. Heads are stored in a file in\n$GIT_DIR/refs/heads/ directory, except when using packed refs. (See\ngit-pack-refs[1].)
The current branch. In more detail: Your working tree is normally derived from the state of the tree\nreferred to by HEAD. HEAD is a reference to one of the\nheads in your repository, except when using a\ndetached HEAD, in which case it directly\nreferences an arbitrary commit.
", "head ref": "A synonym for head.
", "hook": "During the normal execution of several Git commands, call-outs are made\nto optional scripts that allow a developer to add functionality or\nchecking. Typically, the hooks allow for a command to be pre-verified\nand potentially aborted, and allow for a post-notification after the\noperation is done. The hook scripts are found in the\n$GIT_DIR/hooks/ directory, and are enabled by simply\nremoving the .sample suffix from the filename. In earlier versions\nof Git you had to make them executable.
Only update and add files to the working directory, but don’t\ndelete them, similar to how cp -R would update the contents\nin the destination directory. This is the default mode in a\ncheckout when checking out files from the\nindex or a tree-ish. In\ncontrast, no-overlay mode also deletes tracked files not\npresent in the source, similar to rsync --delete.
", "pack": "A set of objects which have been compressed into one file (to save space\nor to transmit them efficiently).
", "pack index": "The list of identifiers, and other information, of the objects in a\npack, to assist in efficiently accessing the contents of a\npack.
", - "pathspec": "Pattern used to limit paths in Git commands.
\nPathspecs are used on the command line of \"git ls-files\", \"git\nls-tree\", \"git add\", \"git grep\", \"git diff\", \"git checkout\",\nand many other commands to\nlimit the scope of operations to some subset of the tree or\nworking tree. See the documentation of each command for whether\npaths are relative to the current directory or toplevel. The\npathspec syntax is as follows:
\nany path matches itself
\nthe pathspec up to the last slash represents a\ndirectory prefix. The scope of that pathspec is\nlimited to that subtree.
\nthe rest of the pathspec is a pattern for the remainder\nof the pathname. Paths relative to the directory\nprefix will be matched against that pattern using fnmatch(3);\nin particular, * and ? can match directory separators.
\nFor example, Documentation/*.jpg will match all .jpg files\nin the Documentation subtree,\nincluding Documentation/chapter_1/figure_1.jpg.
\nA pathspec that begins with a colon : has special meaning. In the\nshort form, the leading colon : is followed by zero or more \"magic\nsignature\" letters (which optionally is terminated by another colon :),\nand the remainder is the pattern to match against the path.\nThe \"magic signature\" consists of ASCII symbols that are neither\nalphanumeric, glob, regex special characters nor colon.\nThe optional colon that terminates the \"magic signature\" can be\nomitted if the pattern begins with a character that does not belong to\n\"magic signature\" symbol set and is not a colon.
In the long form, the leading colon : is followed by an open\nparenthesis (, a comma-separated list of zero or more \"magic words\",\nand a close parentheses ), and the remainder is the pattern to match\nagainst the path.
A pathspec with only a colon means \"there is no pathspec\". This form\nshould not be combined with other pathspec.
\nThe magic word top (magic signature: /) makes the pattern\nmatch from the root of the working tree, even when you are\nrunning the command from inside a subdirectory.
Wildcards in the pattern such as * or ? are treated\nas literal characters.
Case insensitive match.
\nGit treats the pattern as a shell glob suitable for\nconsumption by fnmatch(3) with the FNM_PATHNAME flag:\nwildcards in the pattern will not match a / in the pathname.\nFor example, \"Documentation/*.html\" matches\n\"Documentation/git.html\" but not \"Documentation/ppc/ppc.html\"\nor \"tools/perf/Documentation/perf.html\".
\nTwo consecutive asterisks (\"**\") in patterns matched against\nfull pathname may have special meaning:
A leading \"**\" followed by a slash means match in all\ndirectories. For example, \"**/foo\" matches file or directory\n\"foo\" anywhere. \"**/foo/bar\" matches file or directory \"bar\"\nanywhere that is directly under directory \"foo\".
A trailing \"/**\" matches everything inside. For example,\n\"abc/**\" matches all files inside directory \"abc\", relative\nto the location of the .gitignore file, with infinite depth.
A slash followed by two consecutive asterisks then a slash\nmatches zero or more directories. For example, \"a/**/b\"\nmatches \"a/b\", \"a/x/b\", \"a/x/y/b\" and so on.
Other consecutive asterisks are considered invalid.
\nGlob magic is incompatible with literal magic.
\nAfter attr: comes a space separated list of \"attribute\nrequirements\", all of which must be met in order for the\npath to be considered a match; this is in addition to the\nusual non-magic pathspec pattern matching.\nSee linkgit:gitattributes[5].
Each of the attribute requirements for the path takes one of\nthese forms:
\n\"ATTR\" requires that the attribute ATTR be set.
\"-ATTR\" requires that the attribute ATTR be unset.
\"ATTR=VALUE\" requires that the attribute ATTR be\nset to the string VALUE.
\"!ATTR\" requires that the attribute ATTR be\nunspecified.
Note that when matching against a tree object, attributes are still\nobtained from working tree, not from the given tree object.
\nAfter a path matches any non-exclude pathspec, it will be run\nthrough all exclude pathspecs (magic signature: ! or its\nsynonym ^). If it matches, the path is ignored. When there\nis no non-exclude pathspec, the exclusion is applied to the\nresult set as if invoked without any pathspec.
Pattern used to limit paths in Git commands.
\nPathspecs are used on the command line of \"git ls-files\", \"git\nls-tree\", \"git add\", \"git grep\", \"git diff\", \"git checkout\",\nand many other commands to\nlimit the scope of operations to some subset of the tree or\nworking tree. See the documentation of each command for whether\npaths are relative to the current directory or toplevel. The\npathspec syntax is as follows:
\nany path matches itself
\nthe pathspec up to the last slash represents a\ndirectory prefix. The scope of that pathspec is\nlimited to that subtree.
\nthe rest of the pathspec is a pattern for the remainder\nof the pathname. Paths relative to the directory\nprefix will be matched against that pattern using fnmatch(3);\nin particular, * and ? can match directory separators.
\nFor example, Documentation/*.jpg will match all .jpg files\nin the Documentation subtree,\nincluding Documentation/chapter_1/figure_1.jpg.
\nA pathspec that begins with a colon : has special meaning. In the\nshort form, the leading colon : is followed by zero or more \"magic\nsignature\" letters (which optionally is terminated by another colon :),\nand the remainder is the pattern to match against the path.\nThe \"magic signature\" consists of ASCII symbols that are neither\nalphanumeric, glob, regex special characters nor colon.\nThe optional colon that terminates the \"magic signature\" can be\nomitted if the pattern begins with a character that does not belong to\n\"magic signature\" symbol set and is not a colon.
In the long form, the leading colon : is followed by an open\nparenthesis (, a comma-separated list of zero or more \"magic words\",\nand a close parentheses ), and the remainder is the pattern to match\nagainst the path.
A pathspec with only a colon means \"there is no pathspec\". This form\nshould not be combined with other pathspec.
\nThe magic word top (magic signature: /) makes the pattern\nmatch from the root of the working tree, even when you are\nrunning the command from inside a subdirectory.
Wildcards in the pattern such as * or ? are treated\nas literal characters.
Case insensitive match.
\nGit treats the pattern as a shell glob suitable for\nconsumption by fnmatch(3) with the FNM_PATHNAME flag:\nwildcards in the pattern will not match a / in the pathname.\nFor example, \"Documentation/*.html\" matches\n\"Documentation/git.html\" but not \"Documentation/ppc/ppc.html\"\nor \"tools/perf/Documentation/perf.html\".
\nTwo consecutive asterisks (\"**\") in patterns matched against\nfull pathname may have special meaning:
A leading \"**\" followed by a slash means match in all\ndirectories. For example, \"**/foo\" matches file or directory\n\"foo\" anywhere. \"**/foo/bar\" matches file or directory \"bar\"\nanywhere that is directly under directory \"foo\".
A trailing \"/**\" matches everything inside. For example,\n\"abc/**\" matches all files inside directory \"abc\", relative\nto the location of the .gitignore file, with infinite depth.
A slash followed by two consecutive asterisks then a slash\nmatches zero or more directories. For example, \"a/**/b\"\nmatches \"a/b\", \"a/x/b\", \"a/x/y/b\" and so on.
Other consecutive asterisks are considered invalid.
\nGlob magic is incompatible with literal magic.
\nAfter attr: comes a space separated list of \"attribute\nrequirements\", all of which must be met in order for the\npath to be considered a match; this is in addition to the\nusual non-magic pathspec pattern matching.\nSee gitattributes[5].
Each of the attribute requirements for the path takes one of\nthese forms:
\n\"ATTR\" requires that the attribute ATTR be set.
\"-ATTR\" requires that the attribute ATTR be unset.
\"ATTR=VALUE\" requires that the attribute ATTR be\nset to the string VALUE.
\"!ATTR\" requires that the attribute ATTR be\nunspecified.
Note that when matching against a tree object, attributes are still\nobtained from working tree, not from the given tree object.
\nAfter a path matches any non-exclude pathspec, it will be run\nthrough all exclude pathspecs (magic signature: ! or its\nsynonym ^). If it matches, the path is ignored. When there\nis no non-exclude pathspec, the exclusion is applied to the\nresult set as if invoked without any pathspec.
A commit object contains a (possibly empty) list\nof the logical predecessor(s) in the line of development, i.e. its\nparents.
", "peel": "The action of recursively dereferencing a\ntag object.
", - "pickaxe": "The term pickaxe refers to an option to the diffcore\nroutines that help select changes that add or delete a given text\nstring. With the --pickaxe-all option, it can be used to view the full\nchangeset that introduced or removed, say, a\nparticular line of text. See linkgit:git-diff[1].
The term pickaxe refers to an option to the diffcore\nroutines that help select changes that add or delete a given text\nstring. With the --pickaxe-all option, it can be used to view the full\nchangeset that introduced or removed, say, a\nparticular line of text. See git-diff[1].
Cute name for core Git.
", "porcelain": "Cute name for programs and program suites depending on\ncore Git, presenting a high level access to\ncore Git. Porcelains expose more of a SCM\ninterface than the plumbing.
", "per-worktree ref": "Refs that are per-worktree, rather than\nglobal. This is presently only HEAD and any refs\nthat start with refs/bisect/, but might later include other\nunusual refs.
A ref that has different semantics than normal refs. These refs can be\nread via normal Git commands, but cannot be written to by commands like\nlinkgit:git-update-ref[1].
\nThe following pseudorefs are known to Git:
\nFETCH_HEAD is written by linkgit:git-fetch[1] or linkgit:git-pull[1]. It\nmay refer to multiple object IDs. Each object ID is annotated with metadata\nindicating where it was fetched from and its fetch status.
MERGE_HEAD is written by linkgit:git-merge[1] when resolving merge\nconflicts. It contains all commit IDs which are being merged.
Pulling a branch means to fetch it and\nmerge it. See also linkgit:git-pull[1].
", + "pseudoref": "A ref that has different semantics than normal refs. These refs can be\nread via normal Git commands, but cannot be written to by commands like\ngit-update-ref[1].
\nThe following pseudorefs are known to Git:
\nFETCH_HEAD is written by git-fetch[1] or git-pull[1]. It\nmay refer to multiple object IDs. Each object ID is annotated with metadata\nindicating where it was fetched from and its fetch status.
MERGE_HEAD is written by git-merge[1] when resolving merge\nconflicts. It contains all commit IDs which are being merged.
Pulling a branch means to fetch it and\nmerge it. See also git-pull[1].
", "push": "Pushing a branch means to get the branch’s\nhead ref from a remote repository,\nfind out if it is an ancestor to the branch’s local\nhead ref, and in that case, putting all\nobjects, which are reachable from the local\nhead ref, and which are missing from the remote\nrepository, into the remote\nobject database, and updating the remote\nhead ref. If the remote head is not an\nancestor to the local head, the push fails.
", "reachable": "All of the ancestors of a given commit are said to be\n\"reachable\" from that commit. More\ngenerally, one object is reachable from\nanother if we can reach the one from the other by a chain\nthat follows tags to whatever they tag,\ncommits to their parents or trees, and\ntrees to the trees or blobs\nthat they contain.
", "reachability bitmaps": "Reachability bitmaps store information about the\nreachability of a selected set of commits in\na packfile, or a multi-pack index (MIDX), to speed up object search.\nThe bitmaps are stored in a \".bitmap\" file. A repository may have at\nmost one bitmap file in use. The bitmap file may belong to either one\npack, or the repository’s multi-pack index (if it exists).
", "rebase": "To reapply a series of changes from a branch to a\ndifferent base, and reset the head of that branch\nto the result.
", - "ref": "A name that points to an object name or\nanother ref (the latter is called a symbolic ref).\nFor convenience, a ref can sometimes be abbreviated when used\nas an argument to a Git command; see linkgit:gitrevisions[7]\nfor details.\nRefs are stored in the repository.
\nThe ref namespace is hierarchical.\nRef names must either start with refs/ or be located in the root of\nthe hierarchy. For the latter, their name must follow these rules:
The name consists of only upper-case characters or underscores.
\nThe name ends with \"_HEAD\" or is equal to \"HEAD\".
There are some irregular refs in the root of the hierarchy that do not\nmatch these rules. The following list is exhaustive and shall not be\nextended in the future:
\nAUTO_MERGE
BISECT_EXPECTED_REV
NOTES_MERGE_PARTIAL
NOTES_MERGE_REF
MERGE_AUTOSTASH
Different subhierarchies are used for different purposes. For example,\nthe refs/heads/ hierarchy is used to represent local branches whereas\nthe refs/tags/ hierarchy is used to represent local tags..
A reflog shows the local \"history\" of a ref. In other words,\nit can tell you what the 3rd last revision in this repository\nwas, and what was the current state in this repository,\nyesterday 9:14pm. See linkgit:git-reflog[1] for details.
", - "refspec": "A \"refspec\" is used by fetch and\npush to describe the mapping between remote\nref and local ref. See linkgit:git-fetch[1] or\nlinkgit:git-push[1] for details.
", + "ref": "A name that points to an object name or\nanother ref (the latter is called a symbolic ref).\nFor convenience, a ref can sometimes be abbreviated when used\nas an argument to a Git command; see gitrevisions[7]\nfor details.\nRefs are stored in the repository.
\nThe ref namespace is hierarchical.\nRef names must either start with refs/ or be located in the root of\nthe hierarchy. For the latter, their name must follow these rules:
The name consists of only upper-case characters or underscores.
\nThe name ends with \"_HEAD\" or is equal to \"HEAD\".
There are some irregular refs in the root of the hierarchy that do not\nmatch these rules. The following list is exhaustive and shall not be\nextended in the future:
\nAUTO_MERGE
BISECT_EXPECTED_REV
NOTES_MERGE_PARTIAL
NOTES_MERGE_REF
MERGE_AUTOSTASH
Different subhierarchies are used for different purposes. For example,\nthe refs/heads/ hierarchy is used to represent local branches whereas\nthe refs/tags/ hierarchy is used to represent local tags..
A reflog shows the local \"history\" of a ref. In other words,\nit can tell you what the 3rd last revision in this repository\nwas, and what was the current state in this repository,\nyesterday 9:14pm. See git-reflog[1] for details.
", + "refspec": "A \"refspec\" is used by fetch and\npush to describe the mapping between remote\nref and local ref. See git-fetch[1] or\ngit-push[1] for details.
", "remote repository": "A repository which is used to track the same\nproject but resides somewhere else. To communicate with remotes,\nsee fetch or push.
", "remote-tracking branch": "A ref that is used to follow changes from another\nrepository. It typically looks like\nrefs/remotes/foo/bar (indicating that it tracks a branch named\nbar in a remote named foo), and matches the right-hand-side of\na configured fetch refspec. A remote-tracking\nbranch should not contain direct modifications or have local\ncommits made to it.
", "repository": "A collection of refs together with an\nobject database containing all objects\nwhich are reachable from the refs, possibly\naccompanied by meta data from one or more porcelains. A\nrepository can share an object database with other repositories\nvia alternates mechanism.
", @@ -73,15 +73,15 @@ "SCM": "Source code management (tool).
", "SHA-1": "\"Secure Hash Algorithm 1\"; a cryptographic hash function.\nIn the context of Git used as a synonym for object name.
", "shallow clone": "Mostly a synonym to shallow repository\nbut the phrase makes it more explicit that it was created by\nrunning git clone --depth=... command.
A shallow repository has an incomplete\nhistory some of whose commits have parents cauterized away (in other\nwords, Git is told to pretend that these commits do not have the\nparents, even though they are recorded in the commit\nobject). This is sometimes useful when you are interested only in the\nrecent history of a project even though the real history recorded in the\nupstream is much larger. A shallow repository\nis created by giving the --depth option to linkgit:git-clone[1], and\nits history can be later deepened with linkgit:git-fetch[1].
A shallow repository has an incomplete\nhistory some of whose commits have parents cauterized away (in other\nwords, Git is told to pretend that these commits do not have the\nparents, even though they are recorded in the commit\nobject). This is sometimes useful when you are interested only in the\nrecent history of a project even though the real history recorded in the\nupstream is much larger. A shallow repository\nis created by giving the --depth option to git-clone[1], and\nits history can be later deepened with git-fetch[1].
An object used to temporarily store the contents of a\ndirty working directory and the index for future reuse.
", "submodule": "A repository that holds the history of a\nseparate project inside another repository (the latter of\nwhich is called superproject).
", "superproject": "A repository that references repositories\nof other projects in its working tree as submodules.\nThe superproject knows about the names of (but does not hold\ncopies of) commit objects of the contained submodules.
", - "symref": "Symbolic reference: instead of containing the SHA-1 id\nitself, it is of the format ref: refs/some/thing and when referenced,\nit recursively dereferences to this reference.\nHEAD is a prime example of a symref. Symbolic references\nare manipulated with the linkgit:git-symbolic-ref[1] command.
", + "symref": "Symbolic reference: instead of containing the SHA-1 id\nitself, it is of the format ref: refs/some/thing and when referenced,\nit recursively dereferences to this reference.\nHEAD is a prime example of a symref. Symbolic references\nare manipulated with the git-symbolic-ref[1] command.
", "tag": "A ref under refs/tags/ namespace that points to an\nobject of an arbitrary type (typically a tag points to either a\ntag or a commit object).\nIn contrast to a head, a tag is not updated by\nthe commit command. A Git tag has nothing to do with a Lisp\ntag (which would be called an object type\nin Git’s context). A tag is most typically used to mark a particular\npoint in the commit ancestry chain.
An object containing a ref pointing to\nanother object, which can contain a message just like a\ncommit object. It can also contain a (PGP)\nsignature, in which case it is called a \"signed tag object\".
", "topic branch": "A regular Git branch that is used by a developer to\nidentify a conceptual line of development. Since branches are very easy\nand inexpensive, it is often desirable to have several small branches\nthat each contain very well defined concepts or small incremental yet\nrelated changes.
", - "trailer": "Key-value metadata. Trailers are optionally found at the end of\na commit message. Might be called \"footers\" or \"tags\" in other\ncommunities. See linkgit:git-interpret-trailers[1].
", + "trailer": "Key-value metadata. Trailers are optionally found at the end of\na commit message. Might be called \"footers\" or \"tags\" in other\ncommunities. See git-interpret-trailers[1].
", "tree": "Either a working tree, or a tree\nobject together with the dependent blob and tree objects\n(i.e. a stored representation of a working tree).
", "tree object": "An object containing a list of file names and modes along\nwith refs to the associated blob and/or tree objects. A\ntree is equivalent to a directory.
", "tree-ish": "A tree object or an object that can\nbe recursively dereferenced to a tree object.\nDereferencing a commit object yields the tree\nobject corresponding to the revision's top\ndirectory.\nThe following are all tree-ishes:\na commit-ish,\na tree object,\na tag object that points to a tree object,\na tag object that points to a tag object that points to a tree\nobject,\netc.
", From 428f8fd43b21ec1ea66ab1590cc46feb3b141e86 Mon Sep 17 00:00:00 2001 From: pzhlkj6612$ git bisect reset <commit>+
$ git bisect reset <commit>
git branch [--color[=<когда>] | --no-color] [--show-current] [-v [--abbrev=<n> | --no-abbrev]] [--column[=<параметры>] | --no-column] [--sort=<ключ>] - [--merged [<коммит>]] [--no-merged [<коммит>]] - [--contains [<коммит>]] [--no-contains [<коммит>]] + [--merged [<коммит>]] [--no-merged [<коммит>]] + [--contains [<коммит>]] [--no-contains [<коммит>]] [--points-at <объект>] [--format=<формат>] [(-r | --remotes) | (-a | --all)] [--list] [<шаблон>…] @@ -74,7 +74,7 @@ОП
Обратите внимание, что при указании <шаблона> необходимо использовать
--list; в противном случае команда может быть интерпретирована как создание ветки.
С параметром --contains, отображаются только те ветки, которые содержат указанный коммит (иначе говоря, ветки, верхушки которых являются потомками указанного коммита); --no-contains делает обратное. При использовании --merged будут перечислены только ветки, слитые в указанный коммит (т.е. ветки, верхушки которых достижимы из указанного коммита). С параметром --no-merged, наоборот, будут перечислены только те ветки, которые не были слиты в указанный коммит. Если аргумент <коммит> отсутствует, то по умолчанию используется HEAD (т.е. верхушка текущей ветки).
С параметром --contains, отображаются только те ветки, которые содержат указанный коммит (иначе говоря, ветки, верхушки которых являются потомками указанного коммита); --no-contains делает обратное. При использовании --merged будут перечислены только ветки, слитые в указанный коммит (т.е. ветки, верхушки которых достижимы из указанного коммита). С параметром --no-merged, наоборот, будут перечислены только те ветки, которые не были слиты в указанный коммит. Если аргумент <коммит> отсутствует, то по умолчанию используется HEAD (т.е. верхушка текущей ветки).
В своей второй форме команда создаёт новую ветку с именем <имя-ветки>, которая указывает на текущий HEAD или на <начальную-точку>, если она задана. В качестве особого синтаксиса для <начальной-точки> вы можете использовать "А...Б", что будет означать «базовый коммит для слияния А и Б» (подразумевая, что таковой существует ровно один). Вы также можете опустить указание одной из ревизий А либо Б, тогда вместо неё будет использоваться HEAD.
Открыть редактор и отредактировать текст, объясняющий назначение ветки, который будет использоваться другими различными командами (как например, format-patch, request-pull и merge, если включено). Этот текст может быть многострочным.
Вывести список только тех веток, которые содержат указанный коммит (HEAD, если не указан). Подразумевает --list.
Вывести список только тех веток, которые не содержат указанного коммита (HEAD, если не указан). Подразумевает --list.
Вывести список только тех веток, чьи верхушки достижимы из указанного коммита (HEAD, если не указан). Подразумевает --list.
Вывести список только тех веток, чьи верхушки не достижимы из указанного коммита (HEAD, если не указан). Подразумевает --list.
--contains <коммит> используется для поиска всех веток, которым потребуется особое внимание, если этот <коммит> будет перемещён на другую основу (rebase) или изменён (amend), ибо эти ветки включают в себя указанный <коммит>.
--contains <коммит> используется для поиска всех веток, которым потребуется особое внимание, если этот <коммит> будет перемещён на другую основу (rebase) или изменён (amend), ибо эти ветки включают в себя указанный <коммит>.
--no-contains <коммит> является обратным к предыдущему параметре, т.е. перечисляет ветки, которые не содержат указанный <коммит>.
--no-contains <коммит> является обратным к предыдущему параметре, т.е. перечисляет ветки, которые не содержат указанный <коммит>.
--merged используется для поиска всех веток, которые можно безопасно удалить, поскольку эти ветки полностью включены в HEAD.
Le nom de l’objet à afficher. Pour une liste plus complète des façons d’épeler les noms d’objets, voir la section « SPÉCIFICATION DE RÉVISIONS" dans gitrevisions[7].
Au lieu du contenu, afficher le type d’objet identifié par <objet>.
+Au lieu du contenu, afficher le type d’objet identifié par <objet>.
Sortir avec un statut nul si <objet> existe et est un objet valide. Si <objet> est d’un format invalide, sortir avec un état non-zéro et émettre une erreur sur stderr.
+Sortir avec un statut nul si <objet> existe et est un objet valide. Si <objet> est d’un format invalide, sortir avec un état non-zéro et émettre une erreur sur stderr.
Formater l’affichage du contenu de <objet> en fonction de son type.
+Formater l’affichage du contenu de <objet> en fonction de son type.
Typiquement, cela correspond au type réel de <objet> mais la demande d’un type qui peut trivialement être déréférencé à partir du <objet> donné est également autorisée. Un exemple est de demander un "tree" avec <objet> étant un objet commit qui le contient, ou de demander un "blob" avec <objet> étant un objet tag qui le pointe.
+Typiquement, cela correspond au type réel de <objet> mais la demande d’un type qui peut trivialement être déréférencé à partir du <objet> donné est également autorisée. Un exemple est de demander un "tree" avec <objet> étant un objet commit qui le contient, ou de demander un "blob" avec <objet> étant un objet tag qui le pointe.
Afficher le contenu tel que transformé par un filtre textconv. Dans ce cas, <objet> doit être de la forme <arbre-esque>:<chemin>, ou :<chemin> afin d’appliquer le filtre au contenu enregistré dans l’index à <chemin>.
Afficher le contenu tel que transformé par un filtre textconv. Dans ce cas, <objet> doit être de la forme <arbre-esque>:<chemin>, ou :<chemin> afin d’appliquer le filtre au contenu enregistré dans l’index à <chemin>.
Afficher le contenu tel qu’il a été converti par les filtres configurés dans l’arbre de travail actuel pour le <chemin> donné (c’est-à-dire les filtres de maculage, la conversion de fin de ligne, etc). Dans ce cas, <objet> doit être de la forme <arbre-esque>:<chemin>, ou :<chemin>.
Afficher le contenu tel qu’il a été converti par les filtres configurés dans l’arbre de travail actuel pour le <chemin> donné (c’est-à-dire les filtres de maculage, la conversion de fin de ligne, etc). Dans ce cas, <objet> doit être de la forme <arbre-esque>:<chemin>, ou :<chemin>.
Print object contents for object reference <object>. This corresponds to the output of --batch.
Print object info for object reference <object>. This corresponds to the output of --batch-check.
Si -t est spécifié, un des <type>.
Si -s est spécifié, la taille de l'<objet> en octets.
Si -s est spécifié, la taille de l'<objet> en octets.
Si -e est spécifié, aucune sortie, à moins que le <objet> soit malformé.
Si -e est spécifié, aucune sortie, à moins que le <objet> soit malformé.
Si -p est spécifié, le contenu de <objet> est formatté à l’affichage.
Si -p est spécifié, le contenu de <objet> est formatté à l’affichage.
Si <type> est spécifié, le contenu brut (mais non compressé) de l'<objet> sera retourné.
+Si <type> est spécifié, le contenu brut (mais non compressé) de l'<objet> sera retourné.
<objet> SP missing LF+
<objet> SP missing LF
<objet> SP excluded LF+
<objet> SP excluded LF
<objet> SP ambiguous LF+
<objet> SP ambiguous LF
<objet> SP missing LF+
<objet> SP missing LF
dangling SP <taille> LF -<objet> LF+<objet> LF
loop SP <taille> LF -<objet> LF+<objet> LF
notdir SP <taille> LF -<objet> LF+<objet> LF
git check-attr [--source <arbre-esque>] [-a | --all | <attr>…] [--] <nom-de-chemin>… -git check-attr --stdin [-z] [--source <arbre-esque>] [-a | --all | <attr>…]+
git check-attr [--source <arbre-esque>] [-a | --all | <attr>…] [--] <nom-de-chemin>… +git check-attr --stdin [-z] [--source <arbre-esque>] [-a | --all | <attr>…]
Le format de sortie est modifié pour être analysable par la machine. Si --stdin est également donné, les chemins d’entrée sont séparés par un caractère NUL au lieu d’un caractère de saut de ligne.
Vérifier les attributs par rapport à l’arbre-esque spécifié. Il est courant de spécifier l’arbre source en nommant un commit, une branche ou une étiquette qui lui est associée.
gitcheckout[-q] [-f] [-m] [<branche>] -gitcheckout[-q] [-f] [-m]--detach[<branche>] -gitcheckout[-q] [-f] [-m] [--detach] <commit> ++gitcheckout[-q] [-f] [-m] [<branche>] +gitcheckout[-q] [-f] [-m]--detach[<branche>] +gitcheckout[-q] [-f] [-m] [--detach] <commit>gitcheckout[-q] [-f] [-m] [[-b|-B|--orphan] <nouvelle-branche>] [<point-de-départ>] -gitcheckout<arbre-esque> [--] <spec-de-chemin>… -gitcheckout<arbre-esque>--pathspec-from-file=<fichier> [--pathspec-file-nul] +gitcheckout<arbre-esque> [--] <spec-de-chemin>… +gitcheckout<arbre-esque>--pathspec-from-file=<fichier> [--pathspec-file-nul]gitcheckout[-f|--ours|--theirs|-m|--conflict=<style>] [--] <spec-de-chemin>…gitcheckout[-f|--ours|--theirs|-m|--conflict=<style>]--pathspec-from-file=<fichier> [--pathspec-file-nul] -gitcheckout(-p|--patch) [<arbre-esque>] [--] [<spec-de-chemin>…]gitcheckout(-p|--patch) [<arbre-esque>] [--] [<spec-de-chemin>…]
Basculer de branche, avec git checkout <branche>
Basculer de branche, avec git checkout <branche>
Restaurer une autre version d’un fichier, par exemple avec git checkout <commit> <nom-de-fichier> ou git checkout <nom-de-fichier>
Restaurer une autre version d’un fichier, par exemple avec git checkout <commit> <nom-de-fichier> ou git checkout <nom-de-fichier>
git checkout [<branche>] git checkout [<branche>] Passage à <branche>. Cela définit la branche actuelle à _ <branche>_ et met à jour les fichiers dans votre répertoire de travail. L’extraction échouera s’il n’y a des changements non validés dans les fichiers où < branche> et votre commit actuel ont un contenu différent. Les changements non validés seront conservés sinon.
+Passage à <branche>. Cela définit la branche actuelle à _ <branche>_ et met à jour les fichiers dans votre répertoire de travail. L’extraction échouera s’il n’y a des changements non validés dans les fichiers où < branche> et votre commit actuel ont un contenu différent. Les changements non validés seront conservés sinon.
Si la <branche> n’est pas trouvée mais qu’il existe une branche de suivi pour un dépôt distant unique (appelé <distant>) avec un nom correspondant et --no-guess n’est pas spécifié, le traiter comme équivalent à
Si la <branche> n’est pas trouvée mais qu’il existe une branche de suivi pour un dépôt distant unique (appelé <distant>) avec un nom correspondant et --no-guess n’est pas spécifié, le traiter comme équivalent à
$ git checkout -b <branche> --track <distant>/<branche>+
$ git checkout -b <branche> --track <distant>/<branche>
git checkout -B <nouvelle-branche> [<point-de-départ>] La même chose que -b, sauf que si la branche existe déjà, Git réinitialise <branche> au point de départ au lieu d’échouer.
La même chose que -b, sauf que si la branche existe déjà, Git réinitialise <branche> au point de départ au lieu d’échouer.
git checkout --detach [<branche>] git checkout [--detach] <commit> git checkout --detach [<branche>] git checkout [--detach] <commit> La même chose que git checkout <branche>, sauf que, au lieu de pointer HEAD sur la branche, pointe HEAD à l’ID de commit. Voir la section HEAD DÉTACHÉE ci-dessous pour plus de détails.
La même chose que git checkout <branche>, sauf que, au lieu de pointer HEAD sur la branche, pointe HEAD à l’ID de commit. Voir la section HEAD DÉTACHÉE ci-dessous pour plus de détails.
Omettre <branche> détache HEAD au sommet de la branche actuelle.
Omettre <branche> détache HEAD au sommet de la branche actuelle.
git checkout <arbre-esque> [--] <spéc-de-chemin>... git checkout <arbre-esque> --pathspec-from-file=<fichier> [--pathspec-file-nul] git checkout <arbre-esque> [--] <spéc-de-chemin>... git checkout <arbre-esque> --pathspec-from-file=<fichier> [--pathspec-file-nul] Remplacer les fichiers et/ou les répertoires spécifiés par la version du commit ou de l’arbre donné et les ajouter à l’index (également connu sous le nom de « zone de préparation »).
Par exemple, git checkout main fichier.txt remplacera fichier.txt par sa version dans main.
git checkout [-f | --ours | --theirs | -m | --conflict=<style>] [--] <spéc-de-chemin>... git checkout [-f | --ours | --theirs | -m | --conflict=<style>] [--] <spéc-de-chemin>... git checkout [-f|--ours|--theirs|-m|--conflict=<style>] --pathspec-from-file=<fichier> [--pathspec-file-nul] Remplacer les fichiers et/ou les répertoires spécifiés par la version de l’index.
@@ -131,7 +131,7 @@git add fichier.txt (ou quelque chose d’équivalent) pour le marquer comme résolu. Vous pouvez utiliser -f pour ignorer les fichiers non fusionnés au lieu d’échouer, utiliser --ours ou --theirs pour les remplacer par la version d’un côté spécifique de la fusion, ou utiliser -m pour les remplacer par le résultat original du conflit de fusion.
C’est similaire aux deux modes précédents, mais vous laisse utiliser l’interface interactive pour afficher la sortie « diff » et choisir quelles sections utiliser dans le résultat. Voir plus bas la description de l’option --patch.
-B <nouvelle-branche> La même chose que -b, sauf que si la branche existe déjà, Git réinitialise <branche> au point de départ au lieu d’échouer.
La même chose que -b, sauf que si la branche existe déjà, Git réinitialise <branche> au point de départ au lieu d’échouer.
-t --track[=(direct|inherit)] --guess --no-guess Si la <branche> n’est pas trouvée mais qu’il existe une branche de suivi pour un dépôt distant unique (appelé <distant>) avec un nom correspondant, le traiter comme équivalent à
+Si la <branche> n’est pas trouvée mais qu’il existe une branche de suivi pour un dépôt distant unique (appelé <distant>) avec un nom correspondant, le traiter comme équivalent à
$ git checkout -b <branche> --track <distant>/<branche>+
$ git checkout -b <branche> --track <distant>/<branche>
Si la branche existe dans plus d’un distant et que l’un d’entre eux est la valeur de la variable de configuration checkout.defaultRemote, celui-ci sera utilisé pour désambiguïser, même si la <branche> n’est pas unique parmi tous les distants. Réglez la variable checkout.defaultRemote=origin par exemple pour extraire toujours les branches distantes depuis celle-ci si <branche> est ambigüe mais existe sur le distant origin. Voir aussi checkout.defaultRemote dans git-config[1].
Si la branche existe dans plus d’un distant et que l’un d’entre eux est la valeur de la variable de configuration checkout.defaultRemote, celui-ci sera utilisé pour désambiguïser, même si la <branche> n’est pas unique parmi tous les distants. Réglez la variable checkout.defaultRemote=origin par exemple pour extraire toujours les branches distantes depuis celle-ci si <branche> est ambigüe mais existe sur le distant origin. Voir aussi checkout.defaultRemote dans git-config[1].
--guess est le comportement par défaut. Utilisez --no-guess pour le désactiver.
-d --detach Plutôt que d’extraire une branche pour travailler dessus, extraire un commit pour l’inspecter et faire des expériences jetables. C’est le comportement par défaut de git checkout <commit> quand <commit> n’est pas un nom de branche. Voir la section « HEAD DÉTACHÉE » plus bas pour plus de détails.
Plutôt que d’extraire une branche pour travailler dessus, extraire un commit pour l’inspecter et faire des expériences jetables. C’est le comportement par défaut de git checkout <commit> quand <commit> n’est pas un nom de branche. Voir la section « HEAD DÉTACHÉE » plus bas pour plus de détails.
--orphan <nouvelle-branche> -p --patch Sélectionner interactivement les sections dans la différence entre l'<arbre-esque> (ou l’index, si non spécifié) et l’arbre de travail. Les sections choisies sont ensuite appliquées en ordre inversé à l’arbre de travail (et si un <arbre-esque> a été spécifié, à l’index).
+Sélectionner interactivement les sections dans la différence entre l'<arbre-esque> (ou l’index, si non spécifié) et l’arbre de travail. Les sections choisies sont ensuite appliquées en ordre inversé à l’arbre de travail (et si un <arbre-esque> a été spécifié, à l’index).
Ceci signifie que vous pouvez utiliser git checkout -p pour supprimer sélectivement les éditions depuis votre arbre de travail actuel. Voir la section « Mode Interactif » de git-add[1] pour apprendre à utiliser le mode --patch.
--overlay --no-overlay Dans le mode de superposition par défaut, git checkout ne supprime jamais les fichiers de l’index ou de l’arbre de travail. Lorsque vous spécifiez --no-overlay, les fichiers qui apparaissent dans l’index et l’arbre de travail, mais pas dans <arbre-esque> sont supprimés, pour les faire correspondre à <arbre-esque> exactement.
Dans le mode de superposition par défaut, git checkout ne supprime jamais les fichiers de l’index ou de l’arbre de travail. Lorsque vous spécifiez --no-overlay, les fichiers qui apparaissent dans l’index et l’arbre de travail, mais pas dans <arbre-esque> sont supprimés, pour les faire correspondre à <arbre-esque> exactement.
--pathspec-from-file=<fichier> Uniquement significatif avec --pathspec-from-file. Les éléments du spécificateur de chemin sont séparés par le caractère NUL et tous les autres caractères sont utilisés littéralement (y compris les retours à la ligne et les guillemets).
Branche à extraire ; si c’est une référence à une branche (c’est-à-dire un nom qui, préfixé par « refs/heads/ » est une référence valide), alors cette branche est extraite. Sinon, si c’est une référence à un commit valide, votre HEAD devient « détachée » et vous n’êtes plus sur aucune branche (voir plus bas pour plus de détails).
Arbre depuis lequel extraire (quand des chemins sont indiqués). Si non spécifié, l’index est utilisé.
git difftool [<options>] [<commit> [<commit>]] [--] [<chemin>…]+
git difftool [<options>] [<commit> [<commit>]] [--] [<chemin>…]
git difftool [<opções>] [<commit> [<commit>]] [--] [<caminho>…]+
git difftool [<opções>] [<commit> [<commit>]] [--] [<caminho>…]
git difftool [<параметры>] [<коммит> [<коммит>]] [--] [<путь>…]+
git difftool [<параметры>] [<коммит> [<коммит>]] [--] [<путь>…]
gitfetch'[<options>] [<dépôt> [<spéc-de-réf>…]] +gitfetch'[<options>] [<dépôt> [<spéc-de-réf>…]]gitfetch'[<options>] <groupe> -gitfetch'--multiple[<options>] [(<dépôt>|<groupe>)…] +gitfetch'--multiple[<options>] [(<dépôt>|<groupe>)…]gitfetch'--all[<options>]
Approfondir ou raccourcir l’historique d’un dépôt superficiel pour inclure tous les commits accessibles après <date>.
--shallow-exclude=<révision> --shallow-exclude=<révision> Approfondir ou raccourcir l’historique d’un dépôt superficiel afin d’exclure les commits accessibles depuis une branche ou une étiquette distante spécifiée. Cette option peut être spécifiée plusieurs fois.
Par défaut, lors de la récupération d’un dépôt superficiel, git fetch refuse les références qui nécessitent une mise à jour de .git/shallow. Cette option met à jour le fichier .git/shallow et accepte de telles références.
--negotiation-tip=(<commit>|<glob>) --negotiation-tip=(<commit>|<glob>) Par défaut, Git signalera au serveur les commits accessibles à partir de toutes les références locales pour trouver les commits communs afin de réduire la taille du fichier de paquet à recevoir. Si ceci est spécifié, Git ne signalera que les commits accessibles à partir des sommets donnés. Ceci est utile pour accélérer les recherches lorsque l’utilisateur sait quelle réf locale est susceptible d’avoir des commits en commun avec la réf amont qui est recherchée.
-f --force Lorsque git fetch est utilisé avec la spécification de référence <src>:<dst>, il peut refuser de mettre à jour la branche locale comme cela a été discuté dans la partie <refspec> ci-dessous.
+
Lorsque git fetch est utilisé avec la spécification de référence <src>:<dst>, il peut refuser de mettre à jour la branche locale comme cela a été discuté dans la partie <refspec> ci-dessous.
Cette option permet de passer outre à ce contrôle.
-k --multiple Permettre de spécifier plusieurs arguments <dépôt> et <groupe>. Aucun <spécificateur-de-référence> ne peut être spécifié.
+Permettre de spécifier plusieurs arguments <dépôt> et <groupe>. Aucun <spécificateur-de-référence> ne peut être spécifié.
--auto-maintenance --no-auto-maintenance Le dépôt "distant" qui est la source d’une opération de récupération ou de tirage. Ce paramètre peut être soit une URL (voir la section URLS GIT ci-dessous) soit le nom d’un remote (voir la section DISTANTS ci-dessous).
Préciser les références à récupérer et les références locales à mettre à jour. Lorsqu’aucun <spéc-de-réf> n’apparaît sur la ligne de commande, les références à récupérer sont lues à partir des variables remote.<dépôt>.fetch à la place
+
Préciser les références à récupérer et les références locales à mettre à jour. Lorsqu’aucun <spéc-de-réf> n’apparaît sur la ligne de commande, les références à récupérer sont lues à partir des variables remote.<dépôt>.fetch à la place
(voir BRANCHES DE SUIVI À DISTANCE CONFIGURÉES ci-dessous).
Le format d’un paramètre <spéc-de-réf> est un plus + optionnel, suivi de la source <src>, suivi de deux points :, suivi de la destination <dst>. Les deux points peuvent être omis lorsque <dst> est vide. <src> est typiquement une réf, ou un motif glob avec un unique * qui est utilisé pour trouver un ensemble de réfs mais cela peut aussi être un nom d’objet hexadécimal complet.
Si un spécificateur de référence est préfixé par ^, il sera interprété comme un spécificateur de référence négatif. Plutôt que de spécifier les références à récupérer ou les références locales à mettre à jour, un tel spécificateur de référence spécifiera les références à exclure. Une référence sera considérée comme correspondante si elle correspond à au moins une référence positive, et ne correspond à aucune référence négative. Les spécificateurs de référence négatifs peuvent être utiles pour restreindre le champ d’application d’un spécificateur modèle de référence afin qu’il n’inclue pas de références spécifiques. Les spécificateurs de référence négatifs peuvent eux-mêmes être des spécificateurs modèles de référence . Cependant, ils ne peuvent contenir qu’un <src> et ne peuvent pas spécifier un <dst>. Les noms d’objets hexagonaux complets ne sont pas non plus pris en charge.
tag <étiquette> signifie la même chose que refs/tags/<tag>:refs/tags/<tag> ; cela demande de tout récupérer jusqu’à l’étiquette donnée.
tag <étiquette> signifie la même chose que refs/tags/<tag>:refs/tags/<tag> ; cela demande de tout récupérer jusqu’à l’étiquette donnée.
La référence distante qui correspond à <src> est récupérée, et si <dst> n’est pas une chaîne vide, une tentative est faite pour mettre à jour la référence locale qui lui correspond.
@@ -526,7 +526,7 @@Le nom de l’un des éléments suivants peut être utilisé à la place d’une URL en tant qu’argument <dépôt> :
+Le nom de l’un des éléments suivants peut être utilisé à la place d’une URL en tant qu’argument <dépôt> :
<URL>#<tête>+
<URL>#<tête>
<URL> est obligatoire ; #<tête> est facultatif.
<URL> est obligatoire ; #<tête> est facultatif.
En fonction de l’opération, git utilisera l’un des spécificateurs de référence suivants, si vous n’en fournissez pas un en ligne de commande. <branche> est le nom de ce fichier dans $GIT_DIR/branches et <tête> vaut par défaut master.
En fonction de l’opération, git utilisera l’un des spécificateurs de référence suivants, si vous n’en fournissez pas un en ligne de commande. <branche> est le nom de ce fichier dans $GIT_DIR/branches et <tête> vaut par défaut master.
git fetch utilise :
refs/heads/<tête>:refs/heads/<branche>+
refs/heads/<tête>:refs/heads/<branche>
HEAD:refs/heads/<tête>+
HEAD:refs/heads/<tête>
Si vous activez la configuration push.autoSetupRemote, git push va automatiquement configurer l’amont la première fois que vous poussez une branche.
Extraire une branche de suivi à distance avec git checkout <branche> créera automatiquement une branche locale avec ce nom et configurera l’amont vers la branche distante.
Extraire une branche de suivi à distance avec git checkout <branche> créera automatiquement une branche locale avec ce nom et configurera l’amont vers la branche distante.
Vous interagissez souvent avec le même dépôt distant en y allant régulièrement et de manière répétée. Afin de suivre la progression d’un tel dépôt distant, git fetch vous permet de configurer les variables de configuration remote.<dépôt>.fetch.
Vous interagissez souvent avec le même dépôt distant en y allant régulièrement et de manière répétée. Afin de suivre la progression d’un tel dépôt distant, git fetch vous permet de configurer les variables de configuration remote.<dépôt>.fetch.
En général, une telle variable peut ressembler à ceci :
@@ -693,15 +693,15 @@Lorsque git fetch est lancé sans spécifier les branches et/ou les étiquettes à récupérer en ligne de commande, par exemple git fetch origin ou git fetch, les valeurs remote.<dépôt>.fetch sont utilisées comme spéc-de-réf --elles spécifient quelles réfs à récupérer et quelles réfs locales à mettre à jour. L’exemple ci-dessus va chercher toutes les branches qui existent dans origin (c’est-à-dire toute réf qui correspond au côté gauche de la valeur, "refs/heads/*") et mettre à jour les branches de suivi à distance correspondantes dans la hiérarchie refs/remotes/origin/*.
Lorsque git fetch est lancé sans spécifier les branches et/ou les étiquettes à récupérer en ligne de commande, par exemple git fetch origin ou git fetch, les valeurs remote.<dépôt>.fetch sont utilisées comme spéc-de-réf --elles spécifient quelles réfs à récupérer et quelles réfs locales à mettre à jour. L’exemple ci-dessus va chercher toutes les branches qui existent dans origin (c’est-à-dire toute réf qui correspond au côté gauche de la valeur, "refs/heads/*") et mettre à jour les branches de suivi à distance correspondantes dans la hiérarchie refs/remotes/origin/*.
Lorsque git fetch est lancé avec des branches et/ou des étiquettes explicites à récupérer en ligne de commande, par exemple git fetch origin master, les <spéc-de-réf>s données en ligne de commande déterminent ce qui doit être récupéré (par exemple master dans l’exemple, qui est un raccourci pour master:, ce qui signifie "chercher la branche master mais je ne dis pas explicitement quelle branche de suivi à distance mettre à jour avec elle depuis la ligne de commande"), et la commande de l’exemple ne cherchera que la branche master. Les valeurs de remote.<dépôt>.fetch déterminent quelle branche de suivi à distance, s’il y en a une, est mise à jour. Lorsqu’elles sont utilisées de cette façon, les valeurs de remote.<dépôt>.fetch n’ont aucun effet sur la décision de ce qui est récupéré (c’est-à-dire que les valeurs ne sont pas utilisées comme spéc-de-réf lorsque la ligne de commande liste les spéc-de-réfs) ; elles ne sont utilisées que pour décider de l’endroit où les réfs qui sont récupérées sont stockées en agissant comme une table de correspondance.
Lorsque git fetch est lancé avec des branches et/ou des étiquettes explicites à récupérer en ligne de commande, par exemple git fetch origin master, les <spéc-de-réf>s données en ligne de commande déterminent ce qui doit être récupéré (par exemple master dans l’exemple, qui est un raccourci pour master:, ce qui signifie "chercher la branche master mais je ne dis pas explicitement quelle branche de suivi à distance mettre à jour avec elle depuis la ligne de commande"), et la commande de l’exemple ne cherchera que la branche master. Les valeurs de remote.<dépôt>.fetch déterminent quelle branche de suivi à distance, s’il y en a une, est mise à jour. Lorsqu’elles sont utilisées de cette façon, les valeurs de remote.<dépôt>.fetch n’ont aucun effet sur la décision de ce qui est récupéré (c’est-à-dire que les valeurs ne sont pas utilisées comme spéc-de-réf lorsque la ligne de commande liste les spéc-de-réfs) ; elles ne sont utilisées que pour décider de l’endroit où les réfs qui sont récupérées sont stockées en agissant comme une table de correspondance.
Cette dernière utilisation des valeurs de remote.<dépôt>.fetch peut être écrasée en donnant le(s) paramètre(s) --refmap=<spéc-de-réf> sur la ligne de commande.
Cette dernière utilisation des valeurs de remote.<dépôt>.fetch peut être écrasée en donnant le(s) paramètre(s) --refmap=<spéc-de-réf> sur la ligne de commande.
Par défaut, Git conserve les données à moins qu’elles ne soient explicitement jetées ; cela s’étend à la conservation des références locales aux branches des distants qui ont eux-mêmes supprimé ces branches.
Si on les laisse s’accumuler, ces références périmées pourraient rendre les performances mauvaises sur les gros dépôt qui ont beaucoup de branches, et par exemple rendre la sortie de commandes comme git branch -a --contains <commit> inutilement verbeuse, ainsi qu’avoir un impact sur tout ce qui travaillera avec l’ensemble des références connues.
Si on les laisse s’accumuler, ces références périmées pourraient rendre les performances mauvaises sur les gros dépôt qui ont beaucoup de branches, et par exemple rendre la sortie de commandes comme git branch -a --contains <commit> inutilement verbeuse, ainsi qu’avoir un impact sur tout ce qui travaillera avec l’ensemble des références connues.
La commande ci-dessus copie toutes les branches de l’espace de nom distant refs/heads/ et les stocke dans l’espace de noms local refs/remotes/origin/, sauf si l’option remote. <dépôt> .fetch est utilisée pour spécifier un spécificateur de référence autre que celui par défaut.
La commande ci-dessus copie toutes les branches de l’espace de nom distant refs/heads/ et les stocke dans l’espace de noms local refs/remotes/origin/, sauf si l’option remote. <dépôt> .fetch est utilisée pour spécifier un spécificateur de référence autre que celui par défaut.
gitfetch[<options>] [<repository> [<refspec>…]] +@@ -62,7 +62,7 @@gitfetch[<options>] [<repository> [<refspec>…]]gitfetch[<options>] <group>gitfetch--multiple[<options>] [(<repository>|<group>)…]gitfetch--all[<options>]RESUMO
DESCRIÇÃO
-Fetch branches and/or tags (collectively, "refs") from one or more other repositories, along with the objects necessary to complete their histories. Remote-tracking branches are updated (see the description of <refspec> below for ways to control this behavior).
+Fetch branches and/or tags (collectively, "refs") from one or more other repositories, along with the objects necessary to complete their histories. Remote-tracking branches are updated (see the description of <refspec> below for ways to control this behavior).
By default, any tag that points into the histories being fetched is also fetched; the effect is to fetch tags that point at branches that you are interested in. This default behavior can be changed by using the
@@ -162,7 +162,7 @@--tagsor--no-tagsoptions or by configuringremote.<name>.tagOpt. By using a refspec that fetches tags explicitly, you can fetch tags that do not point into branches you are interested in as well.OPÇÕES
- --force
Quando git fetch é utilizado com <src>
:<dst> "refspec", ele pode se recusar a atualizar o ramo local como discutido -na parte <refspec> abaixo. +na parte <refspec> abaixo. Esta opção sobrescreve esta verificação.- -k
@@ -172,7 +172,7 @@OPÇÕES
- --multiple
- -
Permita que vários argumentos <repositório> e <grupo> sejam utilizados. Nenhum <refspec> pode ser utilizado.
+Permita que vários argumentos <repositório> e <grupo> sejam utilizados. Nenhum <refspec> pode ser utilizado.
- --[no-]auto-maintenance
- --[no-]auto-gc
@@ -212,9 +212,9 @@OPÇÕES
- -
Em vez de negociar com o servidor para evitar a transferência dos commits e dos objetos associados que já estão presentes no local, esta opção faz a busca de todos os objetos da mesma maneira que seria feito com um novo clone. Use isso para reaplicar um filtro de clone parcial da configuração ou usando
--filter=quando a definição do filtro for alterada. A manutenção automática pós-busca realizará a consolidação do pacote no banco de dados dos objetos para seja removido quaisquer objetos duplicados.- --refmap=<refspec>
+- --refmap=<refspec>
- -
Ao obter as refs listadas na linha de comando, use o refspec especificado (pode ser usado mais de uma vez) para mapear as refs nas ramificações de rastreamento remoto, em vez dos valores das variáveis de configuração
+remote.*.fetchdo repositório remoto. Fornecer um <refspec> vazio para a opção--refmapfaz com que o Git ignore os refspecs configurados e confie inteiramente nos refspecs fornecidos como argumentos da linha de comando. Consulte a seção "Configurações dos Ramos Monitorados Remotamente" para obter detalhes.Ao obter as refs listadas na linha de comando, use o refspec especificado (pode ser usado mais de uma vez) para mapear as refs nas ramificações de rastreamento remoto, em vez dos valores das variáveis de configuração
remote.*.fetchdo repositório remoto. Fornecer um <refspec> vazio para a opção--refmapfaz com que o Git ignore os refspecs configurados e confie inteiramente nos refspecs fornecidos como argumentos da linha de comando. Consulte a seção "Configurações dos Ramos Monitorados Remotamente" para obter detalhes.- -t
- --tags
@@ -316,15 +316,15 @@OPÇÕES
- -
Um nome referente a uma lista de repositórios remotos como o valor de
remotes.<grupo> no arquivo de configuração. (consulte git-config[1]).- <refspec>
+- <refspec>
- -
Especifica quais as refs que devem ser obtidas via fetch e quais as refs locais devem ser atualizadas. Quando não houver um <refspec> na linha de comando, as refs que serão obtidas com fetch serão lidas a partir das variáveis
remote.<repositório>.fetch+Especifica quais as refs que devem ser obtidas via fetch e quais as refs locais devem ser atualizadas. Quando não houver um <refspec> na linha de comando, as refs que serão obtidas com fetch serão lidas a partir das variáveis
remote.<repositório>.fetch(consulte CONFIGURAÇÕES DOS RAMOS MONITORADOS REMOTAMENTE below).-The format of a <refspec> parameter is an optional plus
++, followed by the source <src>, followed by a colon:, followed by the destination <dst>. The colon can be omitted when <dst> is empty. <src> is typically a ref, or a glob pattern with a single*that is used to match a set of refs, but it can also be a fully spelled hex object name.The format of a <refspec> parameter is an optional plus
+, followed by the source <src>, followed by a colon:, followed by the destination <dst>. The colon can be omitted when <dst> is empty. <src> is typically a ref, or a glob pattern with a single*that is used to match a set of refs, but it can also be a fully spelled hex object name.-A <refspec> may contain a
+*in its <src> to indicate a simple pattern match. Such a refspec functions like a glob that matches any ref with the pattern. A pattern <refspec> must have one and only one*in both the <src> and <dst>. It will map refs to the destination by replacing the*with the contents matched from the source.A <refspec> may contain a
*in its <src> to indicate a simple pattern match. Such a refspec functions like a glob that matches any ref with the pattern. A pattern <refspec> must have one and only one*in both the <src> and <dst>. It will map refs to the destination by replacing the*with the contents matched from the source.Se um refspec for prefixado por
@@ -336,7 +336,7 @@^, ele será interpretado como um refspec negativo. Em vez de especificar quais as refs devem ser obtidas com fetch ou quais as refs locais devem ser atualizadas, esta refspec especificará as refs que serão excluídas. Uma ref será considerada compatível se corresponder a pelo menos uma refspec positiva e não corresponder a nenhuma refspec negativa. As refspecs negativas podem ser úteis para restringir o escopo de um padrão refspec para que não inclua refs específicas. As refspecs negativas podem ser refspecs de padrão. No entanto, eles podem conter apenas um <src> e não especificar um <dst>. Também não há suporte para nomes de objetos hexadecimais totalmente mencionados.OPÇÕES
A "ref" remota que coincida com <src> é buscada e se <dst> não seja uma sequência vazia, é feita uma tentativa de atualizar a referência local que coincida com ela.
-Caso a atualização seja permitida sem a opção
+--forcedepende do espaço de nomes da ref onde está sendo buscada, do tipo do objeto que está sendo buscado e se a atualização é considerada um avanço rápido. Geralmente, as mesmas regras se aplicam à busca e ao impulsionar, consulte a seção <refspec>... do git-push[1] para saber o que são. As exceções para estas regras específicas para o comando git fetch são anotadas abaixo.Caso a atualização seja permitida sem a opção
--forcedepende do espaço de nomes da ref onde está sendo buscada, do tipo do objeto que está sendo buscado e se a atualização é considerada um avanço rápido. Geralmente, as mesmas regras se aplicam à busca e ao impulsionar, consulte a seção <refspec>... do git-push[1] para saber o que são. As exceções para estas regras específicas para o comando git fetch são anotadas abaixo.Até a versão 2.20 do Git, e ao contrário do que ocorre quando se faz um push com git-push[1], quaisquer atualizações para
@@ -424,8 +424,8 @@refs/tags/*seriam aceitas sem+no refspec (ou a opção--force). Ao fazer a obtenção com fetch, consideramos promiscuamente todas as atualizações das etiquetas de um ramo remoto como sendo um fetch forçado. Desde a versão 2.20 do Git, a busca para atualizarrefs/tags/*funciona da mesma forma que o push. Ou seja, todas as atualizações serão rejeitadas sem+no refspec (ou--force).[remote "<nome>"] url = <URL> pushurl = <pushurl> - push = <refspec> - fetch = <refspec> + push = <refspec> + fetch = <refspec>
@@ -440,8 +440,8 @@
URL: um dos formatos da URL acima - Push: <refspec> - Pull: <refspec>+ Push: <refspec> + Pull: <refspec>@@ -507,12 +507,12 @@CONFIGURED REMOTE-TRACKING BRAN
Quando o comando
gitfetché executado sem especificar quais ramificações e/ou tags devem ser buscadas na linha de comando, por exemplo, o comandogitfetchoriginougitfetch, os valoresremote.<repositório>.fetchsão usados como refspecs - eles especificam quais referências devem ser obtidas e quais referências locais devem ser atualizadas. O exemplo acima obterá todas as ramificações que existem emorigin(ou seja, qualquer referência que corresponda ao lado esquerdo do valor,refs/heads/*) e atualizará as ramificações de rastreamento remoto correspondentes na hierarquiarefs/remotes/origin/*.- -
When
+gitfetchis run with explicit branches and/or tags to fetch on the command line, e.g.gitfetchoriginmaster, the <refspec>s given on the command line determine what are to be fetched (e.g.masterin the example, which is a short-hand formaster:, which in turn means "fetch themasterbranch but I do not explicitly say what remote-tracking branch to update with it from the command line"), and the example command will fetch only themasterbranch. Theremote.<repository>.fetchvalues determine which remote-tracking branch, if any, is updated. When used in this way, theremote.<repository>.fetchvalues do not have any effect in deciding what gets fetched (i.e. the values are not used as refspecs when the command-line lists refspecs); they are only used to decide where the refs that are fetched are stored by acting as a mapping.When
gitfetchis run with explicit branches and/or tags to fetch on the command line, e.g.gitfetchoriginmaster, the <refspec>s given on the command line determine what are to be fetched (e.g.masterin the example, which is a short-hand formaster:, which in turn means "fetch themasterbranch but I do not explicitly say what remote-tracking branch to update with it from the command line"), and the example command will fetch only themasterbranch. Theremote.<repository>.fetchvalues determine which remote-tracking branch, if any, is updated. When used in this way, theremote.<repository>.fetchvalues do not have any effect in deciding what gets fetched (i.e. the values are not used as refspecs when the command-line lists refspecs); they are only used to decide where the refs that are fetched are stored by acting as a mapping.-O último valores do
+remote.<repositório>.fetchpodem ser substituídos, ao usar os parâmetros--refmap=<refspec> na linha de comando.O último valores do
remote.<repositório>.fetchpodem ser substituídos, ao usar os parâmetros--refmap=<refspec> na linha de comando.
A disposição predefinida do Git se organiza de forma a manter os dados a menos que sejam descartados de forma explicita; isso se estende a manter referências locais nas ramificações remotas que elas mesmas excluíram.
Se desassistidas, essas referências obsoletas podem piorar o desempenho em repositórios grandes e ocupados aonde apresentam muita rotatividade e por exemplo, façam uso de comandos como git branch -a --contains <commit> cuja saída é desnecessariamente detalhada, cautilizando impacto de desempenho em qualquer outra referência de trabalho conhecida.
Se desassistidas, essas referências obsoletas podem piorar o desempenho em repositórios grandes e ocupados aonde apresentam muita rotatividade e por exemplo, façam uso de comandos como git branch -a --contains <commit> cuja saída é desnecessariamente detalhada, cautilizando impacto de desempenho em qualquer outra referência de trabalho conhecida.
Estas referências de rastreamento remoto podem ser excluídas com um único:
@@ -541,7 +541,7 @@Para remover as referências como parte do seu fluxo de trabalho normal sem precisar se lembrar de executá-lo, defina fetch.prune globalmente ou com a configuração ` remote.<nome>.prune` por ramo remoto. Consulte git-config[1].
Aqui é onde as coisas ficam complicadas e mais específicas. O recurso de poda não se preocupa de fato com as ramificações; em vez disso, ele poda as referências remotas ←→ locais como uma função no refspec remoto (consulte <refspec> e CONFIGURAÇÕES DOS RAMOS MONITORADOS REMOTAMENTE acima).
+Aqui é onde as coisas ficam complicadas e mais específicas. O recurso de poda não se preocupa de fato com as ramificações; em vez disso, ele poda as referências remotas ←→ locais como uma função no refspec remoto (consulte <refspec> e CONFIGURAÇÕES DOS RAMOS MONITORADOS REMOTAMENTE acima).
Portanto, caso o refspec remoto inclua refs/tags/*:refs/tags/* por exemplo ou caso execute manualmente git fetch --prune <nome> "refs/tags/*:refs/tags/*" por exemplo. As ramificações remotas rastreadas que forem excluídas não expirarão, a não ser qualquer outra tag local que não exista remotamente.
Um breve cabeçalho de metadados que começa com From <commit> com um registro de data e hora fixo, como Seg Set 17 00:00:00 2001 para auxiliar programas como "arquivo(1)" a reconhecer que o arquivo foi gerado deste comando, campos que registrem a identidade do autor, a data da autoria e o título da alteração (retirado do primeiro parágrafo da mensagem do log do commit).
Um breve cabeçalho de metadados que começa com From <commit> com um registro de data e hora fixo, como Seg Set 17 00:00:00 2001 para auxiliar programas como "arquivo(1)" a reconhecer que o arquivo foi gerado deste comando, campos que registrem a identidade do autor, a data da autoria e o título da alteração (retirado do primeiro parágrafo da mensagem do log do commit).
O segundo ou o parágrafo subsequente da mensagem do registro do commit.
@@ -112,7 +112,7 @@A primeira regra tem precedência no caso de um único <commit>. Para aplicar a segunda regra, ou seja, formatar tudo desde o início do histórico até <commit>, use a opção --root: git format-patch --root <commit>. Se quiser formatar apenas o <commit>, você pode fazer isso com git format-patch -1 <commit>.
A primeira regra tem precedência no caso de um único <commit>. Para aplicar a segunda regra, ou seja, formatar tudo desde o início do histórico até <commit>, use a opção --root: git format-patch --root <commit>. Se quiser formatar apenas o <commit>, você pode fazer isso com git format-patch -1 <commit>.
É predefinido que cada arquivo gerado seja numerado de maneira sequencial a partir de 1 e usa a primeira linha da mensagem de confirmação (ajustada para segurança do nome do caminho) como o nome do arquivo. Com a opção --numbered-files, os nomes dos arquivos de saída serão apenas números, sem a primeira linha do commit anexada. Os nomes dos arquivos gerados são impressos na saída predefinida, a menos que a opção --stdout seja especificada.
Gere um hash zerado no cabeçalho "From" de cada patch em vez do hash do commit.
Registre as informações da árvore base para identificar o estado ao qual a série de correções se aplica. Para mais detalhes consulte a seção INFORMAÇÕES SOBRE A ÁRVORE BASE abaixo. Se o <commit> for "auto", um commit básico será escolhido automaticamente. A opção --no-base substitui uma configuração format.useAutoBase.
Registre as informações da árvore base para identificar o estado ao qual a série de correções se aplica. Para mais detalhes consulte a seção INFORMAÇÕES SOBRE A ÁRVORE BASE abaixo. Se o <commit> for "auto", um commit básico será escolhido automaticamente. A opção --no-base substitui uma configuração format.useAutoBase.
git fsck [--tags] [--root] [--unreachable] [--cache] [--no-reflogs] [--[no-]full] [--strict] [--verbose] [--lost-found] [--[no-]dangling] [--[no-]progress] [--connectivity-only] - [--[no-]name-objects] [--[no-]references] [<objet>…]+ [--[no-]name-objects] [--[no-]references] [<objet>…]
Un objet à traiter comme la tête d’une trace d’inaccessibilité.
L’objet<objet> de type <type> n’est pas réellement référencé directement ou indirectement dans aucun des arbres ou commits vus. Cela peut signifier qu’il y a un autre nœud racine que vous ne spécifiez pas ou que l’arbre est corrompu. Si vous n’avez pas manqué un nœud racine, alors vous pourriez aussi bien supprimer les nœuds inaccessibles puisqu’ils ne peuvent pas être utilisés.
+L’objet<objet> de type <type> n’est pas réellement référencé directement ou indirectement dans aucun des arbres ou commits vus. Cela peut signifier qu’il y a un autre nœud racine que vous ne spécifiez pas ou que l’arbre est corrompu. Si vous n’avez pas manqué un nœud racine, alors vous pourriez aussi bien supprimer les nœuds inaccessibles puisqu’ils ne peuvent pas être utilisés.
L’objet <type> <object> est référencé mais n’est pas présent dans la base de données.
L’objet <type> <objet>, est présent dans la base de données mais n’est jamais utilisé directement. Un commit en suspens peut être un nœud racine.
+L’objet <type> <objet>, est présent dans la base de données mais n’est jamais utilisé directement. Un commit en suspens peut être un nœud racine.
La base de données possède un objet dont le hachage ne correspond pas à la valeur de la base de données d’objets. Cela indique un grave problème d’intégrité des données.
git http-fetch [-c] [-t] [-a] [-d] [-v] [-w <fichier>] [--recover] [--stdin | --packfile=<empreinte> | <commit>] <URL>+
git http-fetch [-c] [-t] [-a] [-d] [-v] [-w <fichier>] [--recover] [--stdin | --packfile=<empreinte> | <commit>] <URL>
git http-fetch [-c] [-t] [-a] [-d] [-v] [-w <nome-do-arquivo>] [--recover] [--stdin | --packfile=<hash> | <commit>] <URL>+
git http-fetch [-c] [-t] [-a] [-d] [-v] [-w <nome-do-arquivo>] [--recover] [--stdin | --packfile=<hash> | <commit>] <URL>
Apenas para uso interno. Em vez de um ID do commit na linha de comando (o que não é esperado nesse caso), o git http-fetch busca o arquivo do pacote diretamente na URL informada e usa o index-pack para gerar os arquivos .idx e .keep correspondentes. O hash é usado para determinar o nome do arquivo temporário sendo arbitrário. A saída do index-pack é impressa no stdout. Requer a opção --index-pack-args.
git imap-send [-v] [-q] [--[no-]curl] [(--folder|-f) <répertoire>]
+git imap-send [-v] [-q] [--[no-]curl] [(--folder|-f) <répertoire>]
git imap-send --list
Être silencieux.
Spécifier le dossier dans lequel les courriels doivent être sauvegardés. For example : --folder=[Gmail]/Drafts or -f INBOX/Drafts.
Finja como se todos os refs em refs/ junto com HEAD estejam listados na linha de comando como <commit>.
Finja como se todos os refs em refs/ junto com HEAD estejam listados na linha de comando como <commit>.
Finja como se todas as refs no refs/heads estejam listadas na linha de comando como <commit>. Caso <padrão> seja utilizado, limite os ramos para aqueles que coincidam com a "shell blob" informada. Caso o padrão não tenha ?, *, ou '[, /* no final é implícito.
Finja como se todas as refs no refs/heads estejam listadas na linha de comando como <commit>. Caso <padrão> seja utilizado, limite os ramos para aqueles que coincidam com a "shell blob" informada. Caso o padrão não tenha ?, *, ou '[, /* no final é implícito.
Finja como se todas as refs no refs/remotes estejam listados na linha de comando como <commit>. Caso <padrão> seja utilizado, limite os ramos para aqueles que coincidam com a "shell blob" informada. Caso o padrão não tenha ?, *, ou [, /* no final é implícito.
Finja como se todas as refs no refs/remotes estejam listados na linha de comando como <commit>. Caso <padrão> seja utilizado, limite os ramos para aqueles que coincidam com a "shell blob" informada. Caso o padrão não tenha ?, *, ou [, /* no final é implícito.
Finja que todas as refs em refs/remotes estão listadas na linha de comando como <commit>. Se o <padrão> for fornecido, limita o rastreamento das ramificações remotas àquelas que correspondam ao glob do shell informado. Se o padrão não tiver ?, * ou [, /* no final, então ficará implícito.
Finja que todas as refs em refs/remotes estão listadas na linha de comando como <commit>. Se o <padrão> for fornecido, limita o rastreamento das ramificações remotas àquelas que correspondam ao glob do shell informado. Se o padrão não tiver ?, * ou [, /* no final, então ficará implícito.
Finja como se todos as refs coincidentes com "shell glob" <glob-pattern> estejam listados na linha de comando como <commit>. A refs/ principal é anexada automaticamente caso esteja ausente. Caso o padrão não tenha ?, *, ou [, /* no final é implícito.
+Finja como se todos as refs coincidentes com "shell glob" <glob-pattern> estejam listados na linha de comando como <commit>. A refs/ principal é anexada automaticamente caso esteja ausente. Caso o padrão não tenha ?, *, ou [, /* no final é implícito.
Finja que todos os objetos mencionados pelos reflogs estejam listados na linha de comando como <commit>.
Finja que todos os objetos mencionados pelos reflogs estejam listados na linha de comando como <commit>.
When given a range of commits to display (e.g. commit1..commit2 or commit2 ^commit1), and a commit <commit> in that range, only display commits in that range that are ancestors of <commit>, descendants of <commit>, or <commit> itself. If no commit is specified, use commit1 (the excluded part of the range) as <commit>. Can be passed multiple times; if so, a commit is included if it is any of the commits given or if it is an ancestor or descendant of one of them.
+When given a range of commits to display (e.g. commit1..commit2 or commit2 ^commit1), and a commit <commit> in that range, only display commits in that range that are ancestors of <commit>, descendants of <commit>, or <commit> itself. If no commit is specified, use commit1 (the excluded part of the range) as <commit>. Can be passed multiple times; if so, a commit is included if it is any of the commits given or if it is an ancestor or descendant of one of them.
Limite os commits exibidos àqueles que sejam ancestrais do <commit>, ou que sejam descendentes do <commit>, ou são o <commit> em si.
+Limite os commits exibidos àqueles que sejam ancestrais do <commit>, ou que sejam descendentes do <commit>, ou são o <commit> em si.
Como um exemplo de caso, considere o seguinte histórico do commit:
oneline
<hash> <linha-do-título>+
<hash> <linha-do-título>
short
commit <hash>
+commit <hash>
Author: <autor>
medium
commit <hash>
+commit <hash>
Author: <autor>
Date: <data-do-autor>
full
commit <hash>
+commit <hash>
Author: <autor>
Commit: <quem fez o commit>
fuller
commit <hash> +commit <hash> Author: <autor> AuthorDate: <data-do-autor> Commit: <quem-fez-o-commit> @@ -1211,7 +1211,7 @@FORMA
-From <hash> <data> +From <hash> <data> From: <autor> Date: <data-do-autor> Subject: [PATCH] <linha-do-título>@@ -1776,7 +1776,7 @@<hash>..<hash> <modo>
File modes <mode> are printed as 6-digit octal numbers including the file type and file permission bits.
@@ -1875,7 +1875,7 @@-
index<hash>,<hash>..<hash> +diff --git a/external/docs/content/docs/git-merge-tree/fr.html b/external/docs/content/docs/git-merge-tree/fr.html index 34d94542a1..13d4d9e35e 100644 --- a/external/docs/content/docs/git-merge-tree/fr.html +++ b/external/docs/content/docs/git-merge-tree/fr.html @@ -118,7 +118,7 @@index<hash>,<hash>..<hash>mode<mode>,<mode>..<mode>newfilemode<mode>deletedfilemode<mode>,<mode>OPTIONS
- -
merge-tree sera en erreur par défaut si les deux branches spécifiées ne partagent aucune histoire commune. Ce drapeau peut être donné pour annuler cette vérification et faire poursuivre tout de même la fusion.
- --merge-base=<arbre-esque>
+- --merge-base=<arbre-esque>
- -
Au lieu de trouver les bases de fustion pour la <branche1> et <branche2>, spécifier une base de fusion pour la fusion. Cette option est incompatible avec
--stdin.-<mode> <objet> <étape> <nom-de-fichier>+<mode> <objet> <étape> <nom-de-fichier>@@ -263,7 +263,7 @@Messages d’information
"CONFLIT (renommage/suppression) :<ancienfichier> renommé… mais supprimé dans …"
- -
"Échec de la fusion du sous-module <sous-module> (pas de base de fusion)"
+"Échec de la fusion du sous-module <sous-module> (pas de base de fusion)"
"Attention : ne peut pas fusionner des fichiers binaires : <nom-de-fichier>"
diff --git a/external/docs/content/docs/git-merge-tree/uk.html b/external/docs/content/docs/git-merge-tree/uk.html index 26de356b4e..c25f4582c6 100644 --- a/external/docs/content/docs/git-merge-tree/uk.html +++ b/external/docs/content/docs/git-merge-tree/uk.html @@ -261,7 +261,7 @@Інформаційні повід
"CONFLICT (rename/delete): <oldfile> renamed…but deleted in…"
- -
"Не вдалося об’єднати підмодуль <підмодуль> (немає бази злиття)
+"Не вдалося об’єднати підмодуль <підмодуль> (немає бази злиття)
"Попередження: неможливо об’єднати бінарні файли: <ім’я файлу>
diff --git a/external/docs/content/docs/git-notes/es.html b/external/docs/content/docs/git-notes/es.html index 4fc744f0d2..cf94333caf 100644 --- a/external/docs/content/docs/git-notes/es.html +++ b/external/docs/content/docs/git-notes/es.html @@ -45,16 +45,16 @@NOMBRE
SINOPSIS
-@@ -172,13 +172,13 @@gitnotes[list[<objeto>]] -gitnotesadd[-f] [--allow-empty] [--[no-]separator|--separator=<separador-de-párrafo>] [--[no-]stripspace] [-F<fichero> |-m<mensaje> | (-c|-C) <objeto>] [-e] [<objeto>] +gitnotes[list[<objeto>]] +gitnotesadd[-f] [--allow-empty] [--[no-]separator|--separator=<separador-de-párrafo>] [--[no-]stripspace] [-F<fichero> |-m<mensaje> | (-c|-C) <objeto>] [-e] [<objeto>]gitnotescopy[-f] (--stdin| <objeto-desde> [<objeto-hasta>] ) -gitnotesappend[--allow-empty] [--[no-]separator|--separator=<separador-de-párrafo>] [--[no-]stripspace] [-F<fichero> |-m<mensaje> | (-c|-C) <objeto>] [-e] [<objeto>] -gitnotesedit[--allow-empty] [<objeto>] [--[no-]stripspace] -gitnotesshow[<objeto>] +gitnotesappend[--allow-empty] [--[no-]separator|--separator=<separador-de-párrafo>] [--[no-]stripspace] [-F<fichero> |-m<mensaje> | (-c|-C) <objeto>] [-e] [<objeto>] +gitnotesedit[--allow-empty] [<objeto>] [--[no-]stripspace] +gitnotesshow[<objeto>]gitnotesmerge[-v|-q] [-s<estrategia> ] <referencia-notas>gitnotesmerge--commit[-v|-q]gitnotesmerge--abort[-v|-q] -gitnotesremove[--ignore-missing] [--stdin] [<objeto>…] +gitnotesremove[--ignore-missing] [--stdin] [<objeto>…]gitnotesprune[-n] [-v]gitnotesget-refOPCIONES
- -
Toma el mensaje de nota del fichero dado. Usa - para leer el mensaje de nota desde la entrada estándar.
- -
-C<objeto>- +
--reuse-message=<objeto>- +
-C<objeto>--reuse-message=<objeto>- -
-Toma el objeto blob dado (por ejemplo, otra nota) como el mensaje de nota. (Para copiar notas entre objetos, usa en cambio
+gitnotescopy<objeto>.) Implica--no-stripspaceya que el comportamiento predeterminado es copiar el mensaje verbosamente.Toma el objeto blob dado (por ejemplo, otra nota) como el mensaje de nota. (Para copiar notas entre objetos, usa en cambio
gitnotescopy<objeto>.) Implica--no-stripspaceya que el comportamiento predeterminado es copiar el mensaje verbosamente.- -
-c<objeto>- +
--reedit-message=<objeto>- +
-c<objeto>--reedit-message=<objeto>- @@ -217,12 +217,12 @@
Como
-C, pero con-cse invoca al editor, de tal manera que el usuario pueda editar posteriormente el mensaje de la nota.OPCIONES
-+
--stripspacees el predeterminado, exceptuando-C/--reuse-message. Sin embargo, ten en mente que esto depende del orden de opciones similares. Por ejemplo, para-C<objeto>-m<mensaje>, se usará--stripspaceporque el predeterminado para-manula el-Cprevio. Esta es una limitación conocida que puede corregirse a futuro.
--stripspacees el predeterminado, exceptuando-C/--reuse-message. Sin embargo, ten en mente que esto depende del orden de opciones similares. Por ejemplo, para-C<objeto>-m<mensaje>, se usará--stripspaceporque el predeterminado para-manula el-Cprevio. Esta es una limitación conocida que puede corregirse a futuro.- +
--ref=<referencia>--ref=<referencia>- -
Manipula el árbol de notas en <referencia>. Esto anula
+GIT_NOTES_REFy la configuracióncore.notesRef. La referencia especifica el nombre de referencia completo cuando comienza conrefs/notes/; cuando comienza connotes/,refs/u otros, se prefijarefs/notes/para formar un nombre completo de la referencia.Manipula el árbol de notas en <referencia>. Esto anula
GIT_NOTES_REFy la configuracióncore.notesRef. La referencia especifica el nombre de referencia completo cuando comienza conrefs/notes/; cuando comienza connotes/,refs/u otros, se prefijarefs/notes/para formar un nombre completo de la referencia.--ignore-missing- diff --git a/external/docs/content/docs/git-p4/pt_BR.html b/external/docs/content/docs/git-p4/pt_BR.html index 59bd4584b3..8cc43c3c20 100644 --- a/external/docs/content/docs/git-p4/pt_BR.html +++ b/external/docs/content/docs/git-p4/pt_BR.html @@ -388,7 +388,7 @@
Op
diff --git a/external/docs/content/docs/git-push/pt_BR.html b/external/docs/content/docs/git-push/pt_BR.html index cfd7addb64..83fed96f9b 100644 --- a/external/docs/content/docs/git-push/pt_BR.html +++ b/external/docs/content/docs/git-push/pt_BR.html @@ -52,7 +52,7 @@-
- --origin <commit>
+- --origin <commit>
- diff --git a/external/docs/content/docs/git-pack-objects/fr.html b/external/docs/content/docs/git-pack-objects/fr.html index 5cc160f2ad..7f5615d8bd 100644 --- a/external/docs/content/docs/git-pack-objects/fr.html +++ b/external/docs/content/docs/git-pack-objects/fr.html @@ -79,7 +79,7 @@
O local upstream a partir de onde os commits são identificados para envio ao p4. É predefinido que este é o commit p4 mais recente acessível a partir do
HEAD.OPTIONS
- nom-de-base
- -
Écrire dans des paires de fichiers (.pack et .idx), en utilisant <nom-de-base> pour déterminer le nom du fichier créé. Lorsque cette option est utilisée, les deux fichiers d’une paire sont écrits dans les fichiers <nom-de-base>-<SHA1>.{pack,idx}. <SHA-1> est une empreinte basée sur le contenu du paquet est écrit à la sortie standard de la commande.
+Écrire dans des paires de fichiers (.pack et .idx), en utilisant <nom-de-base> pour déterminer le nom du fichier créé. Lorsque cette option est utilisée, les deux fichiers d’une paire sont écrits dans les fichiers <nom-de-base>-<SHA1>.{pack,idx}. <SHA-1> est une empreinte basée sur le contenu du paquet est écrit à la sortie standard de la commande.
- --stdout
- @@ -87,7 +87,7 @@
OPTIONS
- --revs
- -
Lire les arguments de révision de l’entrée standard, au lieu des noms d’objets individuels. Les arguments de révision sont traités de la même manière que git rev-list avec le drapeau
+--objectsutilise ses argumentscommitpour construire la liste des objets qu’il produit. Les objets de la liste résultante sont empaquetés. En plus des révisions, les lignes--notou--shallow<SHA-1> sont également acceptées.Lire les arguments de révision de l’entrée standard, au lieu des noms d’objets individuels. Les arguments de révision sont traités de la même manière que git rev-list avec le drapeau
--objectsutilise ses argumentscommitpour construire la liste des objets qu’il produit. Les objets de la liste résultante sont empaquetés. En plus des révisions, les lignes--notou--shallow<SHA-1> sont également acceptées.- --unpacked
- diff --git a/external/docs/content/docs/git-pack-objects/pt_BR.html b/external/docs/content/docs/git-pack-objects/pt_BR.html index a90eaca4e8..a5331ed8a6 100644 --- a/external/docs/content/docs/git-pack-objects/pt_BR.html +++ b/external/docs/content/docs/git-pack-objects/pt_BR.html @@ -77,7 +77,7 @@
OPÇÕES
- base-name
- -
Escreva em pares de arquivos (.pack e .idx), usando <nome-base> para determinar o nome do arquivo criado. Quando essa opção é usada, os dois arquivos num par são gravados em arquivos <nome-base>-<SHA-1>.{pack,idx}. <SHA-1> é um hash baseado no conteúdo do pacote sendo gravado na saída predefinida do comando.
+Escreva em pares de arquivos (.pack e .idx), usando <nome-base> para determinar o nome do arquivo criado. Quando essa opção é usada, os dois arquivos num par são gravados em arquivos <nome-base>-<SHA-1>.{pack,idx}. <SHA-1> é um hash baseado no conteúdo do pacote sendo gravado na saída predefinida do comando.
- --stdout
- @@ -85,7 +85,7 @@
OPÇÕES
- --revs
- -
Ler os argumentos de revisão da entrada predefinida, em vez dos nomes dos objetos individuais. Os argumentos de revisão são processados da mesma forma que o comando git rev-list com a opção
+--objectsusa seus argumentoscommitpara criar a lista de objetos que produz. Os objetos da lista resultante são empacotados. Além das revisões, as opções--notou--shallow<SHA-1> também são aceitas.Ler os argumentos de revisão da entrada predefinida, em vez dos nomes dos objetos individuais. Os argumentos de revisão são processados da mesma forma que o comando git rev-list com a opção
--objectsusa seus argumentoscommitpara criar a lista de objetos que produz. Os objetos da lista resultante são empacotados. Além das revisões, as opções--notou--shallow<SHA-1> também são aceitas.- --unpacked
- diff --git a/external/docs/content/docs/git-pack-objects/uk.html b/external/docs/content/docs/git-pack-objects/uk.html index 44c09e1a31..86f428fa72 100644 --- a/external/docs/content/docs/git-pack-objects/uk.html +++ b/external/docs/content/docs/git-pack-objects/uk.html @@ -77,7 +77,7 @@
ОПЦІЇ
- base-name
- -
Записувати у пари файлів (.pack та .idx), використовуючи <базове-назва> для визначення імені створеного файлу. Коли використовується ця опція, два файли в парі записуються у файли <базове-назва>-<SHA-1>.{pack,idx}. <SHA-1> – це хеш на основі вмісту пакета, який записується у стандартний вивід команди.
+Записувати у пари файлів (.pack та .idx), використовуючи <базове-назва> для визначення імені створеного файлу. Коли використовується ця опція, два файли в парі записуються у файли <базове-назва>-<SHA-1>.{pack,idx}. <SHA-1> – це хеш на основі вмісту пакета, який записується у стандартний вивід команди.
- --stdout
- @@ -85,7 +85,7 @@
ОПЦІЇ
- --revs
- -
Зчитувати аргументи ревізій зі стандартного вводу, а не назви окремих об’єктів. Аргументи ревізій обробляються так само, як і git rev-list з прапорцем
+--objects, який використовує свої аргументиcommitдля побудови списку об’єктів, які він виводить. Об’єкти у результуючому списку упаковуються. Окрім ревізій, також приймаються рядки--notабо--shallow<SHA-1>.Зчитувати аргументи ревізій зі стандартного вводу, а не назви окремих об’єктів. Аргументи ревізій обробляються так само, як і git rev-list з прапорцем
--objects, який використовує свої аргументиcommitдля побудови списку об’єктів, які він виводить. Об’єкти у результуючому списку упаковуються. Окрім ревізій, також приймаються рядки--notабо--shallow<SHA-1>.- --unpacked
- diff --git a/external/docs/content/docs/git-pack-refs/fr.html b/external/docs/content/docs/git-pack-refs/fr.html index f73fc18691..3247c0d423 100644 --- a/external/docs/content/docs/git-pack-refs/fr.html +++ b/external/docs/content/docs/git-pack-refs/fr.html @@ -84,7 +84,7 @@
OPTIONS
BOGUES
-Des documents plus anciens écrits avant l’introduction du mécanisme de références empaquetées peuvent encore dire des choses comme "le fichier .git/refs/heads/<branche> doit exister" alors que cela doit signifier "la branche <branche> existe".
+Des documents plus anciens écrits avant l’introduction du mécanisme de références empaquetées peuvent encore dire des choses comme "le fichier .git/refs/heads/<branche> doit exister" alors que cela doit signifier "la branche <branche> existe".
RESUMO
[-u | --set-upstream] [-o <texto> | --push-option=<texto>] [--[no-]signed|--signed=(true|false|if-asked)] [--force-with-lease[=<refname>[:<expect>]] [--force-if-includes]] - [--no-verify] [<repositório> [<refspec>…]] + [--no-verify] [<repositório> [<refspec>…]]
The <refspec> argument(s) (for example main in git push origin main) or the --all, --mirror, or --tags options
The <refspec> argument(s) (for example main in git push origin main) or the --all, --mirror, or --tags options
The remote.*.push configuration for the repository being pushed to
Specify what destination ref to update with what source object.
impulsione todos os ramos (ou seja, refs em refs/heads/); não pode ser utilizado com outro <refspec>.
impulsione todos os ramos (ou seja, refs em refs/heads/); não pode ser utilizado com outro <refspec>.
Observe que a opção --force se aplica a todas as refs que forem enviadas, portanto, usá-lo com push.default definido como matching ou com vários destinos de envio configurados com remote.*.push pode substituir diferentes refs do ramo atual (incluindo as refs locais que estão estritamente atrás de sua contraparte remota). Para forçar um envio para apenas um ramo, use um + na frente do refspec que será enviado (git push origin +master para forçar um envio para o ramo master por exemplo). Para mais detalhes consulte a seção <refspec>... acima.
Observe que a opção --force se aplica a todas as refs que forem enviadas, portanto, usá-lo com push.default definido como matching ou com vários destinos de envio configurados com remote.*.push pode substituir diferentes refs do ramo atual (incluindo as refs locais que estão estritamente atrás de sua contraparte remota). Para forçar um envio para apenas um ramo, use um + na frente do refspec que será enviado (git push origin +master para forçar um envio para o ramo master por exemplo). Para mais detalhes consulte a seção <refspec>... acima.
URL: um dos formatos da URL acima - Push: <refspec> - Pull: <refspec>+ Push: <refspec> + Pull: <refspec>
Sem uma configuração adicional, envia a ramificação atual para a upstream configurada (a variável de configuração branch.<name>.merge) caso ela tenha o mesmo nome que o ramo atual e os erros ocorrerem sem qualquer outro impulsionamento.
O comportamento predefinido deste comando quando nenhum <refspec> for informado, pode ser configurado definindo a opção push do ramo remoto ou a variável de configuração push.default.
O comportamento predefinido deste comando quando nenhum <refspec> for informado, pode ser configurado definindo a opção push do ramo remoto ou a variável de configuração push.default.
Por exemplo, para fazer o envio predefinido apenas do ramo atual para origin, use o comando git config remote.origin.push HEAD. Qualquer <refspec> válido (como os dos exemplos abaixo) pode ser configurado como o predefinido para o comando git push origin.
Por exemplo, para fazer o envio predefinido apenas do ramo atual para origin, use o comando git config remote.origin.push HEAD. Qualquer <refspec> válido (como os dos exemplos abaixo) pode ser configurado como o predefinido para o comando git push origin.
git push origin : Impulsiona (push) as ramificações "que coincidam" para origin. Consulte o <refspec> na seção OPTIONS acima para obter uma descrição dos ramos "coincidentes".
Impulsiona (push) as ramificações "que coincidam" para origin. Consulte o <refspec> na seção OPTIONS acima para obter uma descrição dos ramos "coincidentes".
git push origin master Use a referência da origem que corresponde ao master (refs/heads/master por exemplo) para atualizar a referência que corresponde ao satellite/master (provavelmente refs/remotes/satellite/master) no repositório mothership; faça o mesmo para dev e também para satellite/dev.
Consulte a seção que descreve <refspec> ... acima para uma discussão sobre a combinação semântica.
+Consulte a seção que descreve <refspec> ... acima para uma discussão sobre a combinação semântica.
Isto serve para emular o comando git fetch executado na mothership utilizando o git push que é executado na direção oposta para integrar o trabalho realizado no satellite e geralmente é necessário quando só é possível fazer a conexão num sentido (ou seja, o satélite pode fazer uma conexão ssh com a nave mãe "mothership" mas a nave mãe não pode iniciar a conexão com o satélite porque este está atrás de um firewall ou não está executando o sshd (servidor ssh)).
git checkout --detach <upstream>.
Replay the commits, one by one, in order. This is similar to running git cherry-pick <commit> for each commit. See REBASING MERGES for how merges are handled.
Replay the commits, one by one, in order. This is similar to running git cherry-pick <commit> for each commit. See REBASING MERGES for how merges are handled.
Update your branch to point to the final commit with the equivalent of git checkout -B <branch>.
Inicie um rebase interativo com git rebase -i <commit>^, onde <commit> é o commit que você deseja dividir. Na verdade, qualquer intervalo do commit serve, desde que contenha este commit.
Inicie um rebase interativo com git rebase -i <commit>^, onde <commit> é o commit que você deseja dividir. Na verdade, qualquer intervalo do commit serve, desde que contenha este commit.
Marque o commit que deseja dividir com a ação "edit".
diff --git a/external/docs/content/docs/git-rerere/fr.html b/external/docs/content/docs/git-rerere/fr.html index a218553b3f..156d715049 100644 --- a/external/docs/content/docs/git-rerere/fr.html +++ b/external/docs/content/docs/git-rerere/fr.html @@ -76,9 +76,9 @@Réinitialiser les meta-données utilisées par rerere si une résolution de fusion doit être annulée. Appeler git am [--skip|--abort] ou git rebase [--skip|--abort] invoque automatiquement cette commande.
Réinitialiser les résolutions de conflit que rerere a enregistrées pour le conflit actuel dans <spéc-de-chemin>.
+Réinitialiser les résolutions de conflit que rerere a enregistrées pour le conflit actuel dans <spéc-de-chemin>.
git reset [-q] [<árbol-ismo>] [--] <ruta>... git reset [-q] [--pathspec-from-file=<fichero> [--pathspec-file-nul]] [<árbol>] git reset [-q] [--pathspec-from-file=<fichero> [--pathspec-file-nul]] [<árbol>] Estas formas restablecen las entradas del índice para todas las rutas que coincidan la <especificación-de-ruta> al su estado en <árbol-ismo>. (No afecta el árbol de trabajo o la rama actual.)
+gitreset[-q] [<arbre-esque>] [--] <spec-de-chemin>… -gitreset[-q] [--pathspec-from-file=<fichier> [--pathspec-file-nul]] [<arbre-esque>] -gitreset(--patch|-p) [<arbre-esque>] [--] [<spec-de-chemin>…] -gitreset[--soft|--mixed[-N] |--hard|--merge|--keep] [-q] [<commit>]
gitreset[-q] [<arbre-esque>] [--] <spec-de-chemin>… +gitreset[-q] [--pathspec-from-file=<fichier> [--pathspec-file-nul]] [<arbre-esque>] +gitreset(--patch|-p) [<arbre-esque>] [--] [<spec-de-chemin>…] +gitreset[--soft|--mixed[-N] |--hard|--merge|--keep] [-q] [<commit>]
Dans la première et la troisième forme, cette commande copie les entrées depuis <arbre-esque> vers l’index. Dans la dernière forme, elle amène le sommet de la branche actuelle (HEAD) à <commit>, optionnellement en modifiant l’index et l’arbre de travail en correspondance. L'<arbre-esque>/<commit> vaut par défaut HEAD dans toutes les formes.
Dans la première et la troisième forme, cette commande copie les entrées depuis <arbre-esque> vers l’index. Dans la dernière forme, elle amène le sommet de la branche actuelle (HEAD) à <commit>, optionnellement en modifiant l’index et l’arbre de travail en correspondance. L'<arbre-esque>/<commit> vaut par défaut HEAD dans toutes les formes.
git reset [-q] [<arbre-esque>] [--] <spec-de-chemin>... git reset [-q] [--pathspec-from-file=<fichier> [--pathspec-file-nul]] [<arbre-esque>] git reset [-q] [<arbre-esque>] [--] <spec-de-chemin>... git reset [-q] [--pathspec-from-file=<fichier> [--pathspec-file-nul]] [<arbre-esque>] Ces formes réinitialisent les entrées d’index pour tous fichiers correspondant à <spec-de-chemin> à leur état de <arbre-esque> (ceci n’affecte pas l’arbre de travail ou la branche actuelle.)
+Ces formes réinitialisent les entrées d’index pour tous fichiers correspondant à <spec-de-chemin> à leur état de <arbre-esque> (ceci n’affecte pas l’arbre de travail ou la branche actuelle.)
Cela signifie que git reset <spec-de-chemin> est l’opposé de git add <spec-de-chemin>. Cette commande est équivalent à git restore [--source=<arbre-esque>] --staged <spec-de-chemin>....
Cela signifie que git reset <spec-de-chemin> est l’opposé de git add <spec-de-chemin>. Cette commande est équivalent à git restore [--source=<arbre-esque>] --staged <spec-de-chemin>....
Après avoir lancé git reset <spec-de-chemin> pour mettre à jour l’entrée d’index, vous pouvez git-restore[1] pour extraire le contenu de l’index dans l’arbre de travail. Alternativement, en utilisant git-restore[1] et en spécifiant un commit avec --source, vous pouvez copier le contenu d’un chemin d’un commit vers l’index et l’arbre de travail d’une seule traite.
git reset' (--patch | -p) [<arbre-esque>] [--] [<spec-de-chemin>...] git reset' (--patch | -p) [<arbre-esque>] [--] [<spec-de-chemin>...] Sélectionner interactivement les sections dans la différence entre l’index et l'<arbre-esque> (par défaut HEAD). Les sections choisies sont ensuite appliquées en ordre inversé à l’index.
Sélectionner interactivement les sections dans la différence entre l’index et l'<arbre-esque> (par défaut HEAD). Les sections choisies sont ensuite appliquées en ordre inversé à l’index.
Ceci signifie que git reset -p est l’opposé de git add -p, autrement dit, vous pouvez l’utiliser pour réinitialiser sélectivement les sections. Voir la section « Mode interactif » de git-add[1] pour apprendre comment utiliser le mode --patch.
git reset' [<mode>] [<commit>] git reset' [<mode>] [<commit>] Cette forme réinitialise le sommet de la branche actuelle à <commit> et met à jour l’index éventuellement (en le réinitialisant à l’arbre de <commit>) et l’arbre de travail en fonction de <mode>. Avant l’opération, ORIG_HEAD est définie sur le sommet de la branche actuelle. Si <mode> est omis, l’option par défaut est --mixed. Le <mode> est une valeur parmi :
Cette forme réinitialise le sommet de la branche actuelle à <commit> et met à jour l’index éventuellement (en le réinitialisant à l’arbre de <commit>) et l’arbre de travail en fonction de <mode>. Avant l’opération, ORIG_HEAD est définie sur le sommet de la branche actuelle. Si <mode> est omis, l’option par défaut est --mixed. Le <mode> est une valeur parmi :
--soft Ne pas toucher du tout le fichier d’index ou l’arbre de travail (mais réinitialise le sommet à <commit>, juste comme le font tous les modes). Cela laisse tous vos fichiers modifiés « Modifications qui seront validées », comme l’indiquerait git status.
Ne pas toucher du tout le fichier d’index ou l’arbre de travail (mais réinitialise le sommet à <commit>, juste comme le font tous les modes). Cela laisse tous vos fichiers modifiés « Modifications qui seront validées », comme l’indiquerait git status.
--mixed --hard Réinitialiser l’index et l’arbre de travail. Toute modification sur les fichiers suivis dans l’arbre de travail depuis <commit> est supprimée. Tous les fichiers ou répertoires non suivis qui empêchent l’écriture des fichiers suivis sont simplement supprimés.
+Réinitialiser l’index et l’arbre de travail. Toute modification sur les fichiers suivis dans l’arbre de travail depuis <commit> est supprimée. Tous les fichiers ou répertoires non suivis qui empêchent l’écriture des fichiers suivis sont simplement supprimés.
--merge Réinitialiser l’index et mettre à jour les fichiers de l’arbre de travail qui sont différents entre <commit> et HEAD, mais conserver ceux qui sont différents entre l’index et l’arbre de travail (c-à-d qui ont des modifications qui n’ont pas été indexés). Si un fichier qui est différent entre <commit> et l’index a des modifications non indexées, la réinitialisation est annulée.
Réinitialiser l’index et mettre à jour les fichiers de l’arbre de travail qui sont différents entre <commit> et HEAD, mais conserver ceux qui sont différents entre l’index et l’arbre de travail (c-à-d qui ont des modifications qui n’ont pas été indexés). Si un fichier qui est différent entre <commit> et l’index a des modifications non indexées, la réinitialisation est annulée.
En d’autres termes, --merge fait quelque chose comme git read-tree -u -m <commit>, mais transfère les entrées d’index non indexées.
En d’autres termes, --merge fait quelque chose comme git read-tree -u -m <commit>, mais transfère les entrées d’index non indexées.
--keep Réinitialiser les entrées d’index et mettre à jour les fichiers dans l’arbre de travail qui sont différents entre <commit> et HEAD. Si un fichier qui est différent entre <commit> et HEAD a des modifications locales, la réinitialisation est annulée.
Réinitialiser les entrées d’index et mettre à jour les fichiers dans l’arbre de travail qui sont différents entre <commit> et HEAD. Si un fichier qui est différent entre <commit> et HEAD a des modifications locales, la réinitialisation est annulée.
--recurse-submodules --no-recurse-submodules +gitreset[-q] [<tree-ish>] [--] <pathspec>…gitreset[-q] [--pathspec-from-file=<file> [--pathspec-file-nul]] [<tree-ish>]gitreset(--patch|-p) [<tree-ish>] [--] [<pathspec>…] -gitreset[--soft|--mixed[-N] |--hard|--merge|--keep] [-q] [<commit>]
git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] [<commit>]
In the first three forms, copy entries from <tree-ish> to the index. In the last form, set the current branch head (HEAD) to <commit>, optionally modifying index and working tree to match. The <tree-ish>/<commit> defaults to HEAD in all forms.
In the first three forms, copy entries from <tree-ish> to the index. In the last form, set the current branch head (HEAD) to <commit>, optionally modifying index and working tree to match. The <tree-ish>/<commit> defaults to HEAD in all forms.
git reset -p is the opposite of git add -p, i.e. you can use it to selectively reset hunks. See the "Interactive Mode" section of git-add[1] to learn how to operate the --patch mode.
git reset [<mode>] [<commit>] git reset [<mode>] [<commit>] This form resets the current branch head to <commit> and possibly updates the index (resetting it to the tree of <commit>) and the working tree depending on <mode>. Before the operation, ORIG_HEAD is set to the tip of the current branch. If <mode> is omitted, defaults to --mixed. The <mode> must be one of the following:
This form resets the current branch head to <commit> and possibly updates the index (resetting it to the tree of <commit>) and the working tree depending on <mode>. Before the operation, ORIG_HEAD is set to the tip of the current branch. If <mode> is omitted, defaults to --mixed. The <mode> must be one of the following:
--soft Does not touch the index file or the working tree at all (but resets the head to <commit>, just like all modes do). This leaves all your changed files "Changes to be committed", as git status would put it.
Does not touch the index file or the working tree at all (but resets the head to <commit>, just like all modes do). This leaves all your changed files "Changes to be committed", as git status would put it.
--mixed --hard Resets the index and working tree. Any changes to tracked files in the working tree since <commit> are discarded. Any untracked files or directories in the way of writing any tracked files are simply deleted.
+Resets the index and working tree. Any changes to tracked files in the working tree since <commit> are discarded. Any untracked files or directories in the way of writing any tracked files are simply deleted.
--merge Resets the index and updates the files in the working tree that are different between <commit> and HEAD, but keeps those which are different between the index and working tree (i.e. which have changes which have not been added). If a file that is different between <commit> and the index has unstaged changes, reset is aborted.
Resets the index and updates the files in the working tree that are different between <commit> and HEAD, but keeps those which are different between the index and working tree (i.e. which have changes which have not been added). If a file that is different between <commit> and the index has unstaged changes, reset is aborted.
Em outras palavras, --merge faz algo como um git read-tree -u -m <commit>, mas carrega as entradas do índice não mescladas adiante.
Em outras palavras, --merge faz algo como um git read-tree -u -m <commit>, mas carrega as entradas do índice não mescladas adiante.
--keep Resets index entries and updates files in the working tree that are different between <commit> and HEAD. If a file that is different between <commit> and HEAD has local changes, reset is aborted.
Resets index entries and updates files in the working tree that are different between <commit> and HEAD. If a file that is different between <commit> and HEAD has local changes, reset is aborted.
--recurse-submodules --no-recurse-submodules +gitrestore[<opciones>] [--source=<árbol>] [--staged] [--worktree] [--] <especificación-de-ruta>… -gitrestore[<opciones>] [--source=<árbol>] [--staged] [--worktree]--pathspec-from-file=<fichero> [--pathspec-file-nul] -gitrestore(-p|--patch) [<opciones>] [--source=<árbol>] [--staged] [--worktree] [--] [<especificación-de-ruta>…]
gitrestore[<opciones>] [--source=<árbol>] [--staged] [--worktree] [--] <especificación-de-ruta>… +gitrestore[<opciones>] [--source=<árbol>] [--staged] [--worktree]--pathspec-from-file=<fichero> [--pathspec-file-nul] +gitrestore(-p|--patch) [<opciones>] [--source=<árbol>] [--staged] [--worktree] [--] [<especificación-de-ruta>…]
-s <árbol> -s <árbol> --source=<árbol-ismo> Restaura los ficheros del árbol de trabajo con el contenido de un árbol dado. Es normal especificar el árbol fuente por su nombre de confirmación, rama o etiqueta asociada.
@@ -144,7 +144,7 @@--overlay --no-overlay En modo overlay, nunca elimina ficheros al restaurar. En modo no-overlay, elimina ficheros rastreados que no aparezcan en el <árbol> de --source=<árbol>, para hacerlos coincidir exactamente con <árbol>. El predeterminado es modo no-overlay.
En modo overlay, nunca elimina ficheros al restaurar. En modo no-overlay, elimina ficheros rastreados que no aparezcan en el <árbol> de --source=<árbol>, para hacerlos coincidir exactamente con <árbol>. El predeterminado es modo no-overlay.
--pathspec-from-file=<fichero> A notação <rev>^-[<n>] incluí <rev> porém excluí o <n>ésimo pai (ou seja, é uma abreviação para <rev>^<n>..<rev>), com <n> = 1 caso não seja informado. Geralmente é útil para a mesclagem dos commits onde é possível passar <commit>^- para obter todos os commits do ramoq que foi mesclado na mesclagem do commit <commit> (incluindo o próprio <commit>).
+A notação <rev>^-[<n>] incluí <rev> porém excluí o <n>ésimo pai (ou seja, é uma abreviação para <rev>^<n>..<rev>), com <n> = 1 caso não seja informado. Geralmente é útil para a mesclagem dos commits onde é possível passar <commit>^- para obter todos os commits do ramoq que foi mesclado na mesclagem do commit <commit> (incluindo o próprio <commit>).
Embora <rev>^<n> fosse sobre a especificação do pai de um único commit, estas três notações também consideram os seus pais. Como por exemplo, você pode dizer HEAD^2^@, contudo não poderá dizer HEAD^@^2.
diff --git a/external/docs/content/docs/git-send-email/fr.html b/external/docs/content/docs/git-send-email/fr.html index 710328d2d9..9ae4dd6320 100644 --- a/external/docs/content/docs/git-send-email/fr.html +++ b/external/docs/content/docs/git-send-email/fr.html @@ -43,7 +43,7 @@git send-email [<options>] (<fichier>|<répertoire>)… +git send-email [<options>] (<fichier>|<répertoire>)… git send-email [<options>] <options-de-format-patch> git send-email --dump-aliases git send-email --translate-aliases@@ -158,7 +158,7 @@Composer
Sans cette option spécifiée, la correction est effectuée par défaut lors des échanges avec smtp.office365.com ou smtp-mail.outlook.com. Utilisez
--no-outlook-id-fixpour désactiver même lors de communication avec ces deux serveurs.
Spécifier le sujet initial du fil de courriel. Seulement nécessaire si --compose est également défini. Si --compose n’est pas réglé, cela sera demandé.
Active (1) or désactive (0) les messages de débugage. S’ils sont activés, les commandes SMTP et réponses seront affichées. Utile pour débuguer les problèmes de connexion TLS et d’authentification.
Certains fournisseurs de courriel (par exemple iCloud) n’envoient pas une copie des courriels envoyés en utilisant SMTP dans le dossier Sent ou similaire dans votre boîte aux lettres. Utilisez cette option pour utiliser git imap-send pour envoyer une copie des courriels dans le dossier spécifié en utilisant cette option. Vous pouvez exécuter git imap-send --list pour obtenir une liste de noms de dossiers valides, y compris le nom correct du dossier Sent dans votre boîte aux lettres. Vous pouvez également utiliser cette option pour envoyer des courriels dans un dossier IMAP dédié de votre choix.
Finja como se todos os refs em refs/ junto com HEAD estejam listados na linha de comando como <commit>.
Finja como se todos os refs em refs/ junto com HEAD estejam listados na linha de comando como <commit>.
Finja como se todas as refs no refs/heads estejam listadas na linha de comando como <commit>. Caso <padrão> seja utilizado, limite os ramos para aqueles que coincidam com a "shell blob" informada. Caso o padrão não tenha ?, *, ou '[, /* no final é implícito.
Finja como se todas as refs no refs/heads estejam listadas na linha de comando como <commit>. Caso <padrão> seja utilizado, limite os ramos para aqueles que coincidam com a "shell blob" informada. Caso o padrão não tenha ?, *, ou '[, /* no final é implícito.
Finja como se todas as refs no refs/remotes estejam listados na linha de comando como <commit>. Caso <padrão> seja utilizado, limite os ramos para aqueles que coincidam com a "shell blob" informada. Caso o padrão não tenha ?, *, ou [, /* no final é implícito.
Finja como se todas as refs no refs/remotes estejam listados na linha de comando como <commit>. Caso <padrão> seja utilizado, limite os ramos para aqueles que coincidam com a "shell blob" informada. Caso o padrão não tenha ?, *, ou [, /* no final é implícito.
Finja que todas as refs em refs/remotes estão listadas na linha de comando como <commit>. Se o <padrão> for fornecido, limita o rastreamento das ramificações remotas àquelas que correspondam ao glob do shell informado. Se o padrão não tiver ?, * ou [, /* no final, então ficará implícito.
Finja que todas as refs em refs/remotes estão listadas na linha de comando como <commit>. Se o <padrão> for fornecido, limita o rastreamento das ramificações remotas àquelas que correspondam ao glob do shell informado. Se o padrão não tiver ?, * ou [, /* no final, então ficará implícito.
Finja como se todos as refs coincidentes com "shell glob" <glob-pattern> estejam listados na linha de comando como <commit>. A refs/ principal é anexada automaticamente caso esteja ausente. Caso o padrão não tenha ?, *, ou [, /* no final é implícito.
+Finja como se todos as refs coincidentes com "shell glob" <glob-pattern> estejam listados na linha de comando como <commit>. A refs/ principal é anexada automaticamente caso esteja ausente. Caso o padrão não tenha ?, *, ou [, /* no final é implícito.
Finja que todos os objetos mencionados pelos reflogs estejam listados na linha de comando como <commit>.
Finja que todos os objetos mencionados pelos reflogs estejam listados na linha de comando como <commit>.
When given a range of commits to display (e.g. commit1..commit2 or commit2 ^commit1), and a commit <commit> in that range, only display commits in that range that are ancestors of <commit>, descendants of <commit>, or <commit> itself. If no commit is specified, use commit1 (the excluded part of the range) as <commit>. Can be passed multiple times; if so, a commit is included if it is any of the commits given or if it is an ancestor or descendant of one of them.
+When given a range of commits to display (e.g. commit1..commit2 or commit2 ^commit1), and a commit <commit> in that range, only display commits in that range that are ancestors of <commit>, descendants of <commit>, or <commit> itself. If no commit is specified, use commit1 (the excluded part of the range) as <commit>. Can be passed multiple times; if so, a commit is included if it is any of the commits given or if it is an ancestor or descendant of one of them.
Limite os commits exibidos àqueles que sejam ancestrais do <commit>, ou que sejam descendentes do <commit>, ou são o <commit> em si.
+Limite os commits exibidos àqueles que sejam ancestrais do <commit>, ou que sejam descendentes do <commit>, ou são o <commit> em si.
Como um exemplo de caso, considere o seguinte histórico do commit:
oneline
<hash> <linha-do-título>+
<hash> <linha-do-título>
short
commit <hash>
+commit <hash>
Author: <autor>
medium
commit <hash>
+commit <hash>
Author: <autor>
Date: <data-do-autor>
full
commit <hash>
+commit <hash>
Author: <autor>
Commit: <quem fez o commit>
fuller
commit <hash> +commit <hash> Author: <autor> AuthorDate: <data-do-autor> Commit: <quem-fez-o-commit> @@ -270,7 +270,7 @@FORMA
-From <hash> <data> +From <hash> <data> From: <autor> Date: <data-do-autor> Subject: [PATCH] <linha-do-título>@@ -832,7 +832,7 @@<hash>..<hash> <modo>
File modes <mode> are printed as 6-digit octal numbers including the file type and file permission bits.
@@ -931,7 +931,7 @@-
+index<hash>,<hash>..<hash> +diff --git a/external/docs/content/docs/git-stash/fr.html b/external/docs/content/docs/git-stash/fr.html index 34e7725be5..bd0f9bd063 100644 --- a/external/docs/content/docs/git-stash/fr.html +++ b/external/docs/content/docs/git-stash/fr.html @@ -54,14 +54,14 @@index<hash>,<hash>..<hash>mode<mode>,<mode>..<mode>newfilemode<mode>deletedfilemode<mode>,<mode>SYNOPSIS
gitstash[push[-p|--patch] [-S|--staged] [-k|--[no-]keep-index] [-q|--quiet] [-u|--include-untracked] [-a|--all] [(-m|--message) <message>] [--pathspec-from-file=<fichier> [--pathspec-file-nul]] - [--] [<spéc-de-chemin>…]] + [--] [<spéc-de-chemin>…]]gitstashsave[-p|--patch] [-S|--staged] [-k|--[no-]keep-index] [-q|--quiet] [-u|--include-untracked] [-a|--all] [<message>]gitstashcleargitstashcreate[<message>] -gitstashstore[(-m|--message) <message>] [-q|--quiet] <commit> +gitstashstore[(-m|--message) <message>] [-q|--quiet] <commit>gitstashexport(--to-ref<réf>) [<remisage>…] -gitstashimport<commit>gitstashimport<commit>
push [-p | --patch] [-S | --staged] [-k | --[no-]keep-index] [-u | --include-untracked] [-a | --all] [-q | --quiet] [(-m | --message) <message>] [--pathspec-from-file=<fichier> [--pathspec-file-nul]] [--] [<spéc-de-chemin>...] push [-p | --patch] [-S | --staged] [-k | --[no-]keep-index] [-u | --include-untracked] [-a | --all] [-q | --quiet] [(-m | --message) <message>] [--pathspec-from-file=<fichier> [--pathspec-file-nul]] [--] [<spéc-de-chemin>...] Enregistre vos modifications locales dans une nouvelle "entrée de remisage" et les ramène dans HEAD (dans l’arbre de travail et dans l’index). La partie <message> est facultative et donne la description ainsi que l’état du remisage.
branch <nom-de-branche> [<remisage>] Créer et extraire une nouvelle branche nommée <nom-de-branche> à partir du commit où le <remisage> a été créé à l’origine, appliquer les modifications enregistrées dans le <remisage> au nouvel arbre de travail et à l’index. Si cela réussit, et que le <remisage> est une référence de la forme stash@{<révision>}, abandonner alors le <remisage>.
Créer et extraire une nouvelle branche nommée <nom-de-branche> à partir du commit où le <remisage> a été créé à l’origine, appliquer les modifications enregistrées dans le <remisage> au nouvel arbre de travail et à l’index. Si cela réussit, et que le <remisage> est une référence de la forme stash@{<révision>}, abandonner alors le <remisage>.
Ceci est utile si la branche sur laquelle vous avez lancé git stash push a suffisamment changé pour que git stash apply échoue à cause de conflits. Puisque l’entrée de remisage est appliquée sur le commit qui était HEAD au moment où git stash a été lancé, elle restaure l’état d’origine remisé sans conflit.
Exporte les remisages spécifiés, ou tous, si aucun n’est spécifié, à une chaîne de commits qui peuvent être transférés à l’aide des mécanismes de tirage et de poussée normaux, puis importés à l’aide de la sous-commande import.
import <commit> import <commit> Importe les remisages spécifiés du commit spécifié, qui doit avoir été créé par export, et les ajoute à la liste des remisages. Pour remplacer les remisages existants, utilisez clear en premier.
Cette option n’est valable que pour les commandes apply, branch, drop, pop, show et export.
Une référence de la forme stash@{<révision>}. Lorsqu’aucun <remisage> n’est donné, c’est le dernier remisage par défaut (c’est-à-dire, stash@{0}).
Une référence de la forme stash@{<révision>}. Lorsqu’aucun <remisage> n’est donné, c’est le dernier remisage par défaut (c’est-à-dire, stash@{0}).
git submodule [--quiet] [--cached] -git submodule [--quiet] add [<options>] [--] <dépôt> [<chemin>] +git submodule [--quiet] add [<options>] [--] <dépôt> [<chemin>] git submodule [--quiet] status [--cached] [--recursive] [--] [<chemin>…] git submodule [--quiet] init [--] [<chemin>…] git submodule [--quiet] deinit [-f|--force] (--all|[--] <chemin>…) @@ -75,11 +75,11 @@COMMANDES
Ajouter le dépôt donné comme sous-module au chemin donné vers les modifications à valider à côté du projet en cours : le projet en cours est appelé « superprojet ».
<dépôt> est l’URL du dépôt d’origine du nouveau sous-module. Il peut s’agir soit d’une URL absolue, soit (si elle commence par ./ ou ../) de l’emplacement par rapport au dépôt distant par défaut du superprojet (veuillez noter que pour spécifier un dépôt foo.git, voisin d’un superprojet bar.git, vous devrez utiliser ../foo.git au lieu de ./foo.git - comme on pourrait s’y attendre en suivant les règles pour les URL relatives - car l’évaluation des URL relatives dans Git est identique à celle des répertoires relatifs).
<dépôt> est l’URL du dépôt d’origine du nouveau sous-module. Il peut s’agir soit d’une URL absolue, soit (si elle commence par ./ ou ../) de l’emplacement par rapport au dépôt distant par défaut du superprojet (veuillez noter que pour spécifier un dépôt foo.git, voisin d’un superprojet bar.git, vous devrez utiliser ../foo.git au lieu de ./foo.git - comme on pourrait s’y attendre en suivant les règles pour les URL relatives - car l’évaluation des URL relatives dans Git est identique à celle des répertoires relatifs).
Le distant par défaut est le distant de la branche de suivi à distance de la branche actuelle. Si une telle branche de suivi à distance n’existe pas ou si HEAD est détachée, "origin" est supposé être le distant par défaut. Si le superprojet n’a pas de distant par défaut configuré, le superprojet est l’amont d’autorité et le répertoire de travail actuel est utilisé à la place.
@@ -136,7 +136,7 @@Si vous voulez vraiment supprimer un sous-module du dépôt et valider le résultat, utilisez plutôt git-rm[1]. Voir gitsubmodules[7] pour les options de suppression.
Définir la branche distante par défaut pour le sous-module. L’option --branch permet de spécifier la branche distante. L’option --default supprime la clé de configuration submodule.<nom>.branch, ce qui fait que la branche de suivi par défaut est la branche HEAD distante .
Cette option n’est valide que pour la commande deinit. Désenregistrer tous les sous-modules dans l’arbre de travail.
Branche du dépôt à ajouter comme sous-module. Le nom de la branche est enregistré comme submodule.<nom>.branch dans .gitmodules pour update--remote. Une valeur spéciale de . est utilisée pour indiquer que le nom de la branche dans le sous-module doit être le même que celui de la branche active dans le dépôt actuel. Si l’option n’est pas spécifiée, la valeur par défaut est HEAD distant.
Cette option n’est valable que pour la commande add. Elle fixe le nom du sous-module à la chaîne de caractères donnée au lieu de choisir par défaut son chemin d’accès. Le nom doit être valide en tant que nom de répertoire et ne peut pas se terminer par un "/".
Cette option n’est valable que pour les commandes add et update. Ces commandes ont parfois besoin de cloner un dépôt distant. Dans ce cas, cette option sera passée à la commande git-clone[1].
gitswitch[<options>] [--no-guess] <branche> +@@ -67,7 +67,7 @@gitswitch[<options>] [--no-guess] <branche>gitswitch[<options>]--detach[<point-de-départ>]gitswitch[<options>] (-c|-C) <nouvelle-branche> [<point-de-départ>]gitswitch[<options>]--orphan<nouvelle-branche>OPTIONS
-
- <branche>
+- <branche>
- @@ -118,14 +118,14 @@
Branche sur laquelle commuter.
OPTIONS
--guess--no-guess- -
-Si la <branche> n’est pas trouvée mais qu’il existe une branche de suivi pour un dépôt distant unique (appelé <distant>) avec un nom correspondant, le traiter comme équivalent à
+Si la <branche> n’est pas trouvée mais qu’il existe une branche de suivi pour un dépôt distant unique (appelé <distant>) avec un nom correspondant, le traiter comme équivalent à
-$ git switch -c <branche> --track <distant>/<branche>+$ git switch -c <branche> --track <distant>/<branche>-Si la branche existe dans plus d’un distant et que l’un d’entre eux est la valeur de la variable de configuration
+checkout.defaultRemote, celui-ci sera utilisé pour désambiguïser, même si la <branche> n’est pas unique parmi tous les distants. Réglez la variablecheckout.defaultRemote=originpar exemple pour extraire toujours les branches distantes depuis celle-ci si <branche> est ambigüe mais existe sur le distant origin. Voir aussicheckout.defaultRemotedans git-config[1].Si la branche existe dans plus d’un distant et que l’un d’entre eux est la valeur de la variable de configuration
checkout.defaultRemote, celui-ci sera utilisé pour désambiguïser, même si la <branche> n’est pas unique parmi tous les distants. Réglez la variablecheckout.defaultRemote=originpar exemple pour extraire toujours les branches distantes depuis celle-ci si <branche> est ambigüe mais existe sur le distant origin. Voir aussicheckout.defaultRemotedans git-config[1].diff --git a/external/docs/content/docs/git-tag/uk.html b/external/docs/content/docs/git-tag/uk.html index 36be3bc193..f7628e5b4e 100644 --- a/external/docs/content/docs/git-tag/uk.html +++ b/external/docs/content/docs/git-tag/uk.html @@ -170,19 +170,19 @@
--guessest le comportement par défaut. Utilisez--no-guesspour le désactiver.ОПЦІЇ
Цей параметр застосовується лише під час перерахування тегів без рядків анотацій.
- +
--contains[<коміт>]--contains[<коміт>]- -
Перераховувати лише теги, що містять <commit> (
HEAD, якщо не вказано). Має на увазі--list.- +
--no-contains[<коміт>]--no-contains[<коміт>]- -
Перераховувати лише теги, що не містять <commit> (
HEAD, якщо не вказано). Має на увазі--list.- +
--merged[<коміт>]--merged[<коміт>]- -
Перелічувати лише теги, коміти яких доступні з <commit> (
HEAD, якщо не вказано).- +
--no-merged[<коміт>]--no-merged[<коміт>]- diff --git a/external/docs/content/docs/git-update-index/pt_BR.html b/external/docs/content/docs/git-update-index/pt_BR.html index 163e29cc5b..cf6191b7c9 100644 --- a/external/docs/content/docs/git-update-index/pt_BR.html +++ b/external/docs/content/docs/git-update-index/pt_BR.html @@ -459,7 +459,7 @@
Перелічувати лише теги, коміти яких недоступні з <commit> (
HEAD, якщо не вказано).ÍNDI
Este modo é projetado para repositórios com índices muito grandes e visa reduzir o tempo necessário para gravar repetidamente tais índices.
-Nesse modo, o índice é dividido em dois arquivos,
+$GIT_DIR/indexe$GIT_DIR/sharedindex.<SHA-1>. As alterações são acumuladas no$GIT_DIR/index, o índice dividido, enquanto o arquivo do índice compartilhado contém todas os lançamentos no índice e permanece inalterado.Nesse modo, o índice é dividido em dois arquivos,
$GIT_DIR/indexe$GIT_DIR/sharedindex.<SHA-1>. As alterações são acumuladas no$GIT_DIR/index, o índice dividido, enquanto o arquivo do índice compartilhado contém todas os lançamentos no índice e permanece inalterado.Todas as alterações feitas índice que foi dividido são retornadas ao arquivo do índice compartilhado quando a quantidade de entradas no índice atinge um nível especificado através da variável de configuração
diff --git a/external/docs/content/docs/git-update-index/uk.html b/external/docs/content/docs/git-update-index/uk.html index 5e8c2d283d..409b8edb49 100644 --- a/external/docs/content/docs/git-update-index/uk.html +++ b/external/docs/content/docs/git-update-index/uk.html @@ -459,7 +459,7 @@splitIndex.maxPercentChange(consulte git-config[1]).-
У цьому режимі індекс розділяється на два файли: $GIT_DIR/index та $GIT_DIR/sharedindex.<SHA-1>. Зміни накопичуються в $GIT_DIR/index, розділеному індексі, тоді як спільний файл індексу містить усі записи індексу та залишається незмінним.
+У цьому режимі індекс розділяється на два файли: $GIT_DIR/index та $GIT_DIR/sharedindex.<SHA-1>. Зміни накопичуються в $GIT_DIR/index, розділеному індексі, тоді як спільний файл індексу містить усі записи індексу та залишається незмінним.
Усі зміни в розділеному індексі переносяться назад до спільного файлу індексу, коли кількість записів у розділеному індексі досягає рівня, визначеного змінною конфігурації splitIndex.maxPercentChange (див. git-config[1]).
diff --git a/external/docs/content/docs/git-worktree/pt_BR.html b/external/docs/content/docs/git-worktree/pt_BR.html index 51794f67cf..c8d833e7e1 100644 --- a/external/docs/content/docs/git-worktree/pt_BR.html +++ b/external/docs/content/docs/git-worktree/pt_BR.html @@ -248,7 +248,7 @@OPÇÕES
- -
Com
lockou comadd--lock, uma explicação é dada do por que a árvore está "locked" (travada).- <worktree>
+- <worktree>
A árvore de trabalho pode ser identificada através do seu caminho, seja ele relativo ou absoluto.
diff --git a/external/docs/content/docs/git/es.html b/external/docs/content/docs/git/es.html index 4ae90b32b5..b73d3423cb 100644 --- a/external/docs/content/docs/git/es.html +++ b/external/docs/content/docs/git/es.html @@ -200,7 +200,7 @@OPCIONES
- --no-lazy-fetch
- -
No trae objetos faltantes desde el remoto prometente bajo demanda. Útil junto con
+gitcat-file-e<objeto> para ver si el objeto esta localmente disponible. Esto es equivalente a asignar1a la variable de ambienteGIT_NO_LAZY_FETCH.No trae objetos faltantes desde el remoto prometente bajo demanda. Útil junto con
gitcat-file-e<objeto> para ver si el objeto esta localmente disponible. Esto es equivalente a asignar1a la variable de ambienteGIT_NO_LAZY_FETCH.- --no-optional-locks
- @@ -590,7 +590,7 @@
-
- <objeto>
+- <objeto>
- @@ -598,7 +598,7 @@
Indica el nombre del objeto para cualquier tipo de objeto.
<árbol> +
- <árbol>
- @@ -608,7 +608,7 @@
Indica un nombre de objeto árbol.
<árbol-ismo>
- -
Indica un nombre de objeto árbol, commit o etiqueta. Un comando que toma un argumento <arbol-ismo> quiere operar en última instancia sobre un objeto <árbol> pero automáticamente desreferencia objetos <commit> y <etiqueta> que apuntan a un <árbol>.
+Indica un nombre de objeto árbol, commit o etiqueta. Un comando que toma un argumento <arbol-ismo> quiere operar en última instancia sobre un objeto <árbol> pero automáticamente desreferencia objetos <commit> y <etiqueta> que apuntan a un <árbol>.
- <confirmacion-ismo>
- @@ -630,7 +630,7 @@
Identificadores Simbólicos
@@ -592,7 +592,7 @@-Cualquier comando Git que acepte cualquier <objeto> también puede usar la notación simbólica siguiente:
+Cualquier comando Git que acepte cualquier <objeto> también puede usar la notación simbólica siguiente:
diff --git a/external/docs/content/docs/git/fr.html b/external/docs/content/docs/git/fr.html index 6afae40db4..6acebe48ec 100644 --- a/external/docs/content/docs/git/fr.html +++ b/external/docs/content/docs/git/fr.html @@ -232,9 +232,9 @@OPTIONS
- -
Liste les commandes par groupe. Il s’agit d’une option interne/expérimentale et peut changer ou être retirée à l’avenir. Les groupes pris en charge sont les suivants : builtins, parseopt (commandes intégrées qui utilisent parse-options), deprecated (commandes intégrées obsolètes), main (toutes commandes dans le répertoire libexec), autres (toutes autres commandes dans
$PATHqui ont un préfixe git), list-<catégorie> (voir les catégories dans command-list.txt), nohelpers (exclure les commandes assistantes), alias et config (récupère la liste de commandes depuis la variable de configuration completion.commands)- --attr-source=<arbre-esque>
+- --attr-source=<arbre-esque>
- -
Lire les gitattributs depuis <arbre-esque> au lieu de l’arbre-de-travail. Voir gitattributes[5]. C’est équivalent à régler la variable d’environnement
+GIT_ATTR_SOURCE.Lire les gitattributs depuis <arbre-esque> au lieu de l’arbre-de-travail. Voir gitattributes[5]. C’est équivalent à régler la variable d’environnement
GIT_ATTR_SOURCE.
-
- <objet>
+- <objet>
- @@ -600,21 +600,21 @@
Indique le nom de l’objet pour tout type d’objet.
<arbre> +
- <arbre>
- -
Indique un nom d’objet d’arbre.
- <commit>
+- <commit>
- -
Indique un nom d’objet commit.
- <arbre-esque>
+- <arbre-esque>
- -
Indique un nom d’objet arbre, commit ou étiquette. Une commande qui prend un argument <arbre-esque> veut finalement opérer sur un objet <arbre> mais déréférences automatiquement les objets <commit> et <étiquette> qui pointent sur un <arbre>.
+Indique un nom d’objet arbre, commit ou étiquette. Une commande qui prend un argument <arbre-esque> veut finalement opérer sur un objet <arbre> mais déréférences automatiquement les objets <commit> et <étiquette> qui pointent sur un <arbre>.
- <commit-esque>
- -
Indique un nom d’objet commit ou étiquette. Une commande qui prend un argument <commit-esque> veut ultimement opérer sur un objet <commit>, mais déréférence automatiquement des objets <étiquette> qui pointent sur un <commit>.
+Indique un nom d’objet commit ou étiquette. Une commande qui prend un argument <commit-esque> veut ultimement opérer sur un objet <commit>, mais déréférence automatiquement des objets <étiquette> qui pointent sur un <commit>.
- <type>
- @@ -632,7 +632,7 @@
Identificateurs symboliques
-Toute commande Git acceptant n’importe quel <objet> peut également utiliser la notation symbolique suivante :
+Toute commande Git acceptant n’importe quel <objet> peut également utiliser la notation symbolique suivante :
diff --git a/external/docs/content/docs/git/pt_BR.html b/external/docs/content/docs/git/pt_BR.html index 542f29e25c..ac918e9f3c 100644 --- a/external/docs/content/docs/git/pt_BR.html +++ b/external/docs/content/docs/git/pt_BR.html @@ -602,17 +602,17 @@@@ -640,13 +640,13 @@
<étiquette> +
- <étiquette>
- -
-un nom valide d’étiquette (c.-à-d. une référence
+refs/tags/<étiquette>).un nom valide d’étiquette (c.-à-d. une référence
refs/tags/<étiquette>).- <tête>
+- <tête>
- -
un nom valide de tête (c.-à-d. une référence
+refs/heads/<tête>).un nom valide de tête (c.-à-d. une référence
refs/heads/<tête>).<commit> +
- <commit>
Indica um nome de um objeto commit.
- <tree-ish>
- -
Indica um nome do objeto da árvore, commit ou as etiquetas. Um comando que recebe um argumento <tree-ish> deseja operar num objeto <´árvore>, mas remove a referência automaticamente nos objetos <commit> e <etiqueta> que apontam para uma <árvore>.
+Indica um nome do objeto da árvore, commit ou as etiquetas. Um comando que recebe um argumento <tree-ish> deseja operar num objeto <´árvore>, mas remove a referência automaticamente nos objetos <commit> e <etiqueta> que apontam para uma <árvore>.
- <commit-ish>
- -
Indica um nome da etiqueta do objeto ou do commit. Um comando que recebe um argumento <commit-ish> deseja operar num objeto <commit>, mas remove a referência automaticamente nos objetos <etiqueta> que apontam para um <commit>.
+Indica um nome da etiqueta do objeto ou do commit. Um comando que recebe um argumento <commit-ish> deseja operar num objeto <commit>, mas remove a referência automaticamente nos objetos <etiqueta> que apontam para um <commit>.
- <tipo>
- diff --git a/external/docs/data/glossary/es.json b/external/docs/data/glossary/es.json index f58eb1b533..4329618d43 100644 --- a/external/docs/data/glossary/es.json +++ b/external/docs/data/glossary/es.json @@ -23,13 +23,13 @@ "sucio": "
Se dice que un árbol de trabajo está \"sucio\" si contiene modificaciones que no se le han hecho commit en la rama actual.
", "fusión malvada": "Una fusión malvada es una fusión que introduce cambios que no aparecen en ningún antecesor.
", "avance-rápido": "Un avance-rápido es un tipo especial de fusión donde tienes una revisión y estás \"fusionando\" los cambios de otra rama que resulta ser descendiente de lo que tienes. En tal caso, no haces una nueva fusión confirmación sino que sólamente actualizas tu rama para apuntar a la misma revisión de la rama que estás fusionando. Esto ocurrirá frecuentemente en una rama de seguimiento-remoto de un repositorio remoto.
", - "fetch (extraer)": "Hacer fetch a una rama significa obtener la referencia a head de dicha rama desde un repositorio remoto, para encontrar los objetos faltantes en la base de datos de objetos local. Ver también linkgit:git-fetch[1].
", + "fetch (extraer)": "Hacer fetch a una rama significa obtener la referencia a head de dicha rama desde un repositorio remoto, para encontrar los objetos faltantes en la base de datos de objetos local. Ver también git-fetch[1].
", "sistema de ficheros": "Linus Torvalds originalmente diseñó Git para ser un sistema de ficheros de espacio de usuario, ej. la infraestructura para contener ficheros y directorios. Eso aseguró la eficiencia y velocidad de Git.
", "Archivo Git": "Sinónimo de repository (para gente familiarizada con arch).
", - "fichero git": "Un simple fichero
", - "injertos": ".giten la raíz de un árbol de trabajo que apunta al directorio que es el repositorio real. Para su uso apropiado ver linkgit:git-worktree[1] o linkgit:git-submodule[1]. Para sintaxis ver linkgit:gitrepository-layout[5].Injertos permiten juntar dos lineas distintas de desarrollo al guardar información falsa de antecesor para confirmaciones. De esta manera se puede hacer que Git asuma que el conjunto de padres de una confirmación sea diferente de lo que realmente fue guardado cuando la confirmación fue creada. Configurar mediante el fichero
\n.git/info/grafts.\n", + "fichero git": "Notar que el mecanismo de injertos es obsoleto y puede provocar problemas al transferir objetos entre repositorios; ver linkgit:git-replace[1] para un sistema más flexible y robusto que hace lo mismo.
\nUn simple fichero
", + "injertos": ".giten la raíz de un árbol de trabajo que apunta al directorio que es el repositorio real. Para su uso apropiado ver git-worktree[1] o git-submodule[1]. Para sintaxis ver gitrepository-layout[5].Injertos permiten juntar dos lineas distintas de desarrollo al guardar información falsa de antecesor para confirmaciones. De esta manera se puede hacer que Git asuma que el conjunto de padres de una confirmación sea diferente de lo que realmente fue guardado cuando la confirmación fue creada. Configurar mediante el fichero
\n.git/info/grafts.\n", "hash": "Notar que el mecanismo de injertos es obsoleto y puede provocar problemas al transferir objetos entre repositorios; ver git-replace[1] para un sistema más flexible y robusto que hace lo mismo.
\nEn el contexto de Git, sinónimo de nombre de objeto.
", - "cabeza": "Una referencia nombrada a la confirmación en la punta de una rama. Los head se almacenan en un fichero en el directorio
", + "cabeza": "$GIT_DIR/refs/heads/, excepto cuando se usan referencias empaquetadas (Ver linkgit:git-pack-refs[1].)Una referencia nombrada a la confirmación en la punta de una rama. Los head se almacenan en un fichero en el directorio
", "HEAD (angl.)": "$GIT_DIR/refs/heads/, excepto cuando se usan referencias empaquetadas (Ver git-pack-refs[1].)La rama actual. En mas detalle: Tu árbol de trabajo se deriva normalmente del estado del árbol referido por HEAD. HEAD es una referencia a una de las heads en tu repositorio, excepto cuando se usa una HEAD separada, en cuyo caso hace referencia directa a un commit cualquiera.
", "referencia a head": "Sinónimo de head.
", "hook (angl.)": "Durante la ejecución normal de varios comandos Git se realizan llamadas a scripts opcionales que permiten al desarrollador agregar funcionalidad o verificaciones. Típicamente, los hooks permiten pre-verificar un comando y potencialmente abortarlo, así como una pos-notificación después de terminar la operación. Los scripts de hooks se encuentran en directorio
", @@ -48,22 +48,22 @@ "sobreponer": "$GIT_DIR/hooks/y se habilitan simplemente al quitar del nombre del fichero el sufijo.sample; en las primeras versiones de Git se tenían que hacer ejecutables.Sólo actualizar y añadir ficheros al directorio de trabajo, pero no eliminarlos, similar a como cp -R actualizaría el contenido en el directorio destino. Este es el modo predeterminado en un checkout cuando se hace checkout a ficheros de un índice o un árbol-ismo. En contraste, el modo sin-sobreponer también elimina ficheros rastreados no presentes en el origen, similar a rsync --delete.
", "paquete": "Un conjunto de objetos que han sido comprimidos en un fichero (para ahorrar espacio o para transmitirlos eficientemente).
", "índice de paquete": "La lista de identificadores -y otra información- de los objetos en un paquete, para ayudar a acceder eficientemente el contenido de un paquete.
", - "especificación de ruta": "Patrón usado para limitar rutas en comandos Git.
\n\n\nLas especificaciones de ruta son usadas en la línea de comandos de \"git ls-files\", \"git ls-tree\", \"git add\", \"git grep\", \"git diff\", \"git checkout\", y muchos otros comandos para limitar el alcance de operaciones a un subconjunto del árbol o árbol de trabajo. Ver la documentación de cada comando para saber si las rutas son relativas al directorio actual o al toplevel. La sintaxis de las especificaciones de ruta es la siguiente:
\n\n\n\n\n\n\n\n
\n- \n
\ncualquier ruta coincide consigo misma
\n- \n
\nla especificación de ruta hasta la última diagonal representa un prefijo de directorio. El alcance de esa especificación de ruta se limita a ese sub-árbol.
\n- \n
\nel resto de la especificación de ruta es un patrón para el resto de el nombre de la ruta. Rutas relativas a el prefijo de directorio serán comparadas con ese patrón usando fnmatch(3); en particular, * y ? pueden coincidir con separadores de directorio.
\n\n\nPor ejemplo, Documentación/*.jpg coincidirá con todos los ficheros .jpg en el sub-árbol Documentación, incluyendo Documentación/capitulo_1/figura_1.jpg.
\n\n\nUna especificación de ruta que comienza con dos puntos
\n:tiene un significado especial. En la forma corta, a los dos puntos iniciales le siguen cero o mas letras de \"marca mágica\" (las cuales terminan opcionalmente con otros dos puntos:), y el resto es el patrón a comparar con la ruta. La \"marca mágica\" consiste de símbolos ASCII que no son ni alfanuméricos, ni glob, ni caracteres especiales de expresiones regulares, ni dos puntos. Los dos puntos opcionales con los que termina una \"marca mágica\" pueden ser omitidos si el patrón comienza con un caracter que no pertenece al conjunto de símbolos de \"marca mágica\" y no es dos puntos.\n\nEn la forma larga, a los dos puntos iniciales
\n:le sigue una apertura de paréntesis (, una lista separada por comas de cero o mas \"palabras mágicas\", y un cierre de paréntesis ), el resto es el patrón de comparación con la ruta.\n\nUna especificación de ruta con sólo dos puntos significa \"no hay especificación de ruta\". Esta forma no debe combinarse con otras especificaciones de ruta.
\n\n", + "especificación de ruta": "\n\n\n\n\n
\n- top
\n- \n
\nLa palabra mágica
\ntop(marca mágica:/) hace la comparación del patrón desde la raíz el árbol de trabajo, incluso cuando el comando se ejecuta desde el interior de un subdirectorio.- literal
\n- \n
\nComodines en patrones como
\n*o ? son tratados como caracteres literales.- icase
\n- \n
\nBúsqueda insensible a mayúsculas.
\n- glob
\n- \n
\nGit trata el patrón como un glob adecuado para consumo por fnmatch(3) con la bandera FNM_PATHNAME: comodines en el patrón no coincidirán con / en el nombre de la ruta. Por ejemplo, \"Documentación/*.html\" coincidirá con \"Documentación/git.html\" pero no con \"Documentación/ppc/ppc.html\" o \"herramientas/perf/Documentación/perf.html\".
\n\n\nDos asteriscos consecutivos (\"
\n**\") en patrones comparados con nombre de ruta completo puede tener un significado especial:\n\n\n
\n- \n
\nUn \"
\n**\" inicial seguido por una diagonal significa coincidir en todos los directorios. Por ejemplo, \"**/foo\" coincidirá con el fichero o directorio \"foo\" donde sea. \"**/foo/bar\" coincidirá con el fichero o directoriobardonde sea que esté directamente debajo del directorio \"foo\".- \n
\nUn \"
\n/**\" final coincidirá con todo lo que este dentro. Por ejemplo, \"abc/**\" coincidirá con todos los ficheros dentro del directorio \"abc\", relativos a la ubicación del fichero.gitignore, con profundidad infinita.- \n
\nUna diagonal seguida por dos asteriscos consecutivos y luego otra diagonal coincide con cero o mas directorios. Por ejemplo, \"
\na/**/b\" coincidirá con \"a/b\", \"a/x/b\", \"a/x/y/b\" y así sucesivamente.- \n
\nOtros asteriscos consecutivos son considerados inválidos.
\n\n\nGlob mágico es incompatible con literal mágica.
\n- attr
\n- \n
\nDespués de
\nattr:viene una lista separada por espacios de \"requerimientos de atributo\", todos los cuales deben estar en orden para que la ruta sea considerada una coincidencia; esto en adición a la usual comparación de patrones de especificaciones de ruta no-mágicas. Ver linkgit:gitattributes[5].\n\nCada atributo requerido para la ruta toma una de estas formas:
\n\n\n\n
\n- \n
\n\"
\nATTR\" requiere que el atributoATTRse encuentre.- \n
\n\"
\n-ATTR\" requiere que el atributoATTRno se encuentre.- \n
\n\"
\nATTR=VALUE\" requiere que el atributoATTRse encuentre asignado con la cadenaVALUE.- \n
\n\"
\n!ATTR\" requiere que el atributoATTRno este especificado.\n\nNote que cuando se compara con un objeto árbol, los atributos aún se obtienen del árbol de trabajo, no del objeto árbol proporcionado.
\n- exclude
\n- \n
\nDespués que una ruta coincide con cualquiera de las especificaciones de ruta no-excluyentes, será corrida por todas las especificaciones de ruta excluyentes (marca mágica:
\n!o su sinónimo^). Si coincide, la ruta es ignorada. Cuando no hay especificación de ruta no-excluyente, la exclusión se aplica al conjunto resultante como si se hubiera invocado sin una especificación de ruta.Patrón usado para limitar rutas en comandos Git.
\n\n\nLas especificaciones de ruta son usadas en la línea de comandos de \"git ls-files\", \"git ls-tree\", \"git add\", \"git grep\", \"git diff\", \"git checkout\", y muchos otros comandos para limitar el alcance de operaciones a un subconjunto del árbol o árbol de trabajo. Ver la documentación de cada comando para saber si las rutas son relativas al directorio actual o al toplevel. La sintaxis de las especificaciones de ruta es la siguiente:
\n\n\n\n\n\n\n\n
\n- \n
\ncualquier ruta coincide consigo misma
\n- \n
\nla especificación de ruta hasta la última diagonal representa un prefijo de directorio. El alcance de esa especificación de ruta se limita a ese sub-árbol.
\n- \n
\nel resto de la especificación de ruta es un patrón para el resto de el nombre de la ruta. Rutas relativas a el prefijo de directorio serán comparadas con ese patrón usando fnmatch(3); en particular, * y ? pueden coincidir con separadores de directorio.
\n\n\nPor ejemplo, Documentación/*.jpg coincidirá con todos los ficheros .jpg en el sub-árbol Documentación, incluyendo Documentación/capitulo_1/figura_1.jpg.
\n\n\nUna especificación de ruta que comienza con dos puntos
\n:tiene un significado especial. En la forma corta, a los dos puntos iniciales le siguen cero o mas letras de \"marca mágica\" (las cuales terminan opcionalmente con otros dos puntos:), y el resto es el patrón a comparar con la ruta. La \"marca mágica\" consiste de símbolos ASCII que no son ni alfanuméricos, ni glob, ni caracteres especiales de expresiones regulares, ni dos puntos. Los dos puntos opcionales con los que termina una \"marca mágica\" pueden ser omitidos si el patrón comienza con un caracter que no pertenece al conjunto de símbolos de \"marca mágica\" y no es dos puntos.\n\nEn la forma larga, a los dos puntos iniciales
\n:le sigue una apertura de paréntesis (, una lista separada por comas de cero o mas \"palabras mágicas\", y un cierre de paréntesis ), el resto es el patrón de comparación con la ruta.\n\nUna especificación de ruta con sólo dos puntos significa \"no hay especificación de ruta\". Esta forma no debe combinarse con otras especificaciones de ruta.
\n\n", "antecesor": "\n\n\n\n\n
\n- top
\n- \n
\nLa palabra mágica
\ntop(marca mágica:/) hace la comparación del patrón desde la raíz el árbol de trabajo, incluso cuando el comando se ejecuta desde el interior de un subdirectorio.- literal
\n- \n
\nComodines en patrones como
\n*o ? son tratados como caracteres literales.- icase
\n- \n
\nBúsqueda insensible a mayúsculas.
\n- glob
\n- \n
\nGit trata el patrón como un glob adecuado para consumo por fnmatch(3) con la bandera FNM_PATHNAME: comodines en el patrón no coincidirán con / en el nombre de la ruta. Por ejemplo, \"Documentación/*.html\" coincidirá con \"Documentación/git.html\" pero no con \"Documentación/ppc/ppc.html\" o \"herramientas/perf/Documentación/perf.html\".
\n\n\nDos asteriscos consecutivos (\"
\n**\") en patrones comparados con nombre de ruta completo puede tener un significado especial:\n\n\n
\n- \n
\nUn \"
\n**\" inicial seguido por una diagonal significa coincidir en todos los directorios. Por ejemplo, \"**/foo\" coincidirá con el fichero o directorio \"foo\" donde sea. \"**/foo/bar\" coincidirá con el fichero o directoriobardonde sea que esté directamente debajo del directorio \"foo\".- \n
\nUn \"
\n/**\" final coincidirá con todo lo que este dentro. Por ejemplo, \"abc/**\" coincidirá con todos los ficheros dentro del directorio \"abc\", relativos a la ubicación del fichero.gitignore, con profundidad infinita.- \n
\nUna diagonal seguida por dos asteriscos consecutivos y luego otra diagonal coincide con cero o mas directorios. Por ejemplo, \"
\na/**/b\" coincidirá con \"a/b\", \"a/x/b\", \"a/x/y/b\" y así sucesivamente.- \n
\nOtros asteriscos consecutivos son considerados inválidos.
\n\n\nGlob mágico es incompatible con literal mágica.
\n- attr
\n- \n
\nDespués de
\nattr:viene una lista separada por espacios de \"requerimientos de atributo\", todos los cuales deben estar en orden para que la ruta sea considerada una coincidencia; esto en adición a la usual comparación de patrones de especificaciones de ruta no-mágicas. Ver gitattributes[5].\n\nCada atributo requerido para la ruta toma una de estas formas:
\n\n\n\n
\n- \n
\n\"
\nATTR\" requiere que el atributoATTRse encuentre.- \n
\n\"
\n-ATTR\" requiere que el atributoATTRno se encuentre.- \n
\n\"
\nATTR=VALUE\" requiere que el atributoATTRse encuentre asignado con la cadenaVALUE.- \n
\n\"
\n!ATTR\" requiere que el atributoATTRno este especificado.\n\nNote que cuando se compara con un objeto árbol, los atributos aún se obtienen del árbol de trabajo, no del objeto árbol proporcionado.
\n- exclude
\n- \n
\nDespués que una ruta coincide con cualquiera de las especificaciones de ruta no-excluyentes, será corrida por todas las especificaciones de ruta excluyentes (marca mágica:
\n!o su sinónimo^). Si coincide, la ruta es ignorada. Cuando no hay especificación de ruta no-excluyente, la exclusión se aplica al conjunto resultante como si se hubiera invocado sin una especificación de ruta.Un objeto commit contiene una lista -posiblemente vacía- de predecesor(es) en la línea de desarrollo, ej. sus padres.
", "pelar": "La acción de desreferenciar recursivamente un objeto etiqueta.
", - "pickaxe": "El término pickaxe se refiere a una opción para las rutinas de diffcore que ayudan a seleccionar los cambios que agregan o eliminan cierta cadena de texto. La opción
", + "pickaxe": "--pickaxe-allpuede usarse para ver el conjunto de cambios completo que introdujo o removió, digamos, a línea de texto en particular. Ver linkgit:git-diff[1].El término pickaxe se refiere a una opción para las rutinas de diffcore que ayudan a seleccionar los cambios que agregan o eliminan cierta cadena de texto. La opción
", "plomería": "--pickaxe-allpuede usarse para ver el conjunto de cambios completo que introdujo o removió, digamos, a línea de texto en particular. Ver git-diff[1].Un lindo nombre para núcleo de Git.
", "porcelana": "Un nombre bonito para programas y suites de programas que dependen del núcleo Git, presentando un acceso de alto nivel al núcleo de Git. Porcelanas exponen mas una interfase de un SCM que la plomería.
", "referencia por-árbol-de-trabajo": "Referencia que es por-árbol de trabajo, en lugar de global. Esto es presentemente sólo HEAD y cualquier referencia que comienza con
", - "pseudoreferencia": "refs/bisect/, pero posteriormente puede incluir otras referencias inusuales.Una referencia que tiene semánticas diferentes a la referencias normales. Esas referencias pueden leerse mediante comandos normales de Git, pero no pueden ser escritas por comandos como linkgit:git-update-ref[1].
\n\n\nLas siguientes pseudo-referencias son reconocidas por Git:
\n\n", - "incorporar": "\n
\n- \n
\n\n
FETCH_HEADes escrito por linkgit:git-fetch[1] o linkgit:git-pull[1]. Se puede referir a múltiples identificadores de objeto. Cada identificador de objeto es anotado con metadatos indicando de dónde se obtuvo y el estado del fetch.- \n
\n\n
MERGE_HEADes escrito por linkgit:git-merge[1] cuando se resuelven conflictos de fusión. Contiene todos los identificadores de las confirmaciones que se están fusionando.Incorporar una rama significa traerla y fusionarla. Ver también linkgit:git-pull[1].
", + "pseudoreferencia": "Una referencia que tiene semánticas diferentes a la referencias normales. Esas referencias pueden leerse mediante comandos normales de Git, pero no pueden ser escritas por comandos como git-update-ref[1].
\n\n\nLas siguientes pseudo-referencias son reconocidas por Git:
\n\n", + "incorporar": "\n
\n- \n
\n\n
FETCH_HEADes escrito por git-fetch[1] o git-pull[1]. Se puede referir a múltiples identificadores de objeto. Cada identificador de objeto es anotado con metadatos indicando de dónde se obtuvo y el estado del fetch.- \n
\n\n
MERGE_HEADes escrito por git-merge[1] cuando se resuelven conflictos de fusión. Contiene todos los identificadores de las confirmaciones que se están fusionando.Incorporar una rama significa traerla y fusionarla. Ver también git-pull[1].
", "enviar": "Enviar una rama significa obtener la referencia a head de la rama de un repositorio remoto, determinar si es un ancestro de la referencia a head de la rama local, y en tal caso, poner todos los objetos que son alcanzables desde la referencia a head local y que son faltantes en el repositorio remoto en la base de datos de objetos remota actualizando la referencia a head remota. Si la head remota no es ancestro del head local, el envío falla.
", "alcanzable": "Todos los ancestros de una confirmación> dada se dice que son \"alcanzables\" desde esa confirmación. Mas en general, un <<def_object,objeto es alcanzable por otro si podemos alcanzar uno desde otro por una cadena que siga etiquetas a lo que sea que etiqueten, confirmaciones a sus antecesores o árboles, y árboles a los árboles o blobs que los contengan.
", "mapas de bits de alcance": "Los mapas de bits de alcance almacenan información acerca del alcance de un conjunto seleccionado de confirmaciones en un fichero de paquete, o un índice multi-paquete (MIDX), para acelerar la búsqueda de objetos. Los mapas de bits se almacenan en un fichero \".bitmap\". Un repositorio puede tener a lo mucho un fichero de mapa de bits en uso. El fichero de mapa de bits puede pertenecer ya sea a un paquete, o al índice multi-paquete de un repositorio (si existe).
", "rebase": "Re-aplicar una serie de cambios de una rama de una base diferente, y reasignar la head de esa rama al resultado.
", - "referencia": "Un nombre que apunta a un nombre de objeto o a otra referencia (a éste último se le llama referencia simbólica). Por conveniencia, una referencia puede a veces ser abreviada cuando se usa como argumento de un comando Git; ver linkgit:gitrevisions[7] para detalles. Las referencias se almacenan en el repositorio.
\n\n\nEl espacio de nombres de referencias es jerárquico. Los nombres de referencias deben comenzar con
\nrefs/o estar ubicados en la raíz de la jerarquía. Para éste último, su nombre debe cumplir las reglas siguientes:\n", - "bitácora de referencia": "\n
\n- \n
\nEl nombre consiste sólo en caracteres en mayúsculas y guiones bajos.
\n- \n
\nEl nombre termina con \"
\n_HEAD\" o es igual a \"HEAD\".\n\nHay algunas referencias irregulares en la raíz de la jerarquía que no cumplen con esas reglas. La lista siguiente es exhaustiva y no deberá extenderse en el futuro:
\n- \n
\n\n
AUTO_MERGE- \n
\n\n
BISECT_EXPECTED_REV- \n
\n\n
NOTES_MERGE_PARTIAL- \n
\n\n
NOTES_MERGE_REF- \n
\n\n
MERGE_AUTOSTASH\n\nDiferentes sub-jerarquías se usan para fines distintos. Por ejemplo, la jerarquía
\nrefs/heads/se usa para representar ramas locales, y la jerarquíarefs/tags/se usa para representar etiquetas locales.Una bitácora de referencia muestra el historial local de una referencia. En otras palabras, te puede decir cuál fue la 3era última revisión en este repositorio, y cuál era el estado actual en este repositorio ayer a las 9:14pm. Ver linkgit:git-reflog[1] para detalles.
", - "especificación de referencia": "Una \"especificación de referencia\" es usada por traer y por enviar para describir el mapeo entre referencia remota y referencia local. Ver linkgit:git-fetch[1] o linkgit:git-push[1] para detalles.
", + "referencia": "Un nombre que apunta a un nombre de objeto o a otra referencia (a éste último se le llama referencia simbólica). Por conveniencia, una referencia puede a veces ser abreviada cuando se usa como argumento de un comando Git; ver gitrevisions[7] para detalles. Las referencias se almacenan en el repositorio.
\n\n\nEl espacio de nombres de referencias es jerárquico. Los nombres de referencias deben comenzar con
\nrefs/o estar ubicados en la raíz de la jerarquía. Para éste último, su nombre debe cumplir las reglas siguientes:\n", + "bitácora de referencia": "\n
\n- \n
\nEl nombre consiste sólo en caracteres en mayúsculas y guiones bajos.
\n- \n
\nEl nombre termina con \"
\n_HEAD\" o es igual a \"HEAD\".\n\nHay algunas referencias irregulares en la raíz de la jerarquía que no cumplen con esas reglas. La lista siguiente es exhaustiva y no deberá extenderse en el futuro:
\n- \n
\n\n
AUTO_MERGE- \n
\n\n
BISECT_EXPECTED_REV- \n
\n\n
NOTES_MERGE_PARTIAL- \n
\n\n
NOTES_MERGE_REF- \n
\n\n
MERGE_AUTOSTASH\n\nDiferentes sub-jerarquías se usan para fines distintos. Por ejemplo, la jerarquía
\nrefs/heads/se usa para representar ramas locales, y la jerarquíarefs/tags/se usa para representar etiquetas locales.Una bitácora de referencia muestra el historial local de una referencia. En otras palabras, te puede decir cuál fue la 3era última revisión en este repositorio, y cuál era el estado actual en este repositorio ayer a las 9:14pm. Ver git-reflog[1] para detalles.
", + "especificación de referencia": "Una \"especificación de referencia\" es usada por traer y por enviar para describir el mapeo entre referencia remota y referencia local. Ver git-fetch[1] o git-push[1] para detalles.
", "repositorio remoto": "Un repositorio el cual es usado para rastrear el mismo proyecto pero que reside en otro lugar. Para comunicarse con remotos, ver traer o enviar.
", "rama de seguimiento-remoto": "Una referencia que es usada para seguir cambios desde otro repositorio. Típicamente se ve como refs/remotes/foo/bar (indicando que da seguimiento una rama llamada bar en un remoto llamado foo), y coincide el lado derecho de una especificación de referencia de envío configurada. Una rama de seguimiento remoto no debería contener modificaciones directas ni tener confirmaciones locales hechas a ella.
", "repositorio": "Una colección de referencias junto con una base de datos de objetos conteniendo todos los objetos que son alcanzables desde referencias, posiblemente acompañada por metadatos de uno o mas porcelains. Un repositorio puede compartir una base de datos de objetos con otros repositorios vía mecanismos alternos.
", @@ -73,15 +73,15 @@ "GCF": "Administración de código fuente (herramienta).
", "SHA-1": "\"Algoritmo de Hash Seguro 1\"; una función hash criptográfica. En el contexto de Git se usa como sinónimo de nombre de objeto.
", "clon superficial": "Comúnmente un sinónimo de repositorio superficial pero la frase hace mas explícito que fue creado por la ejecución del comando
", - "repositorio superficial": "gitclone--depth=....Un repositorio superficial tienen un historial incompleto, donde algunos de los padres de sus confirmaciones han sido cauterizados (en otras palabras, se le ha instruido a Git a pretender que esas confirmaciones no tienen padres, aunque estén registrados en el objeto confirmación). En ocasiones esto es útil cuando sólo se esta interesado en el historial reciente de un proyecto, aunque el historial real almacenado en el upstream es mucho mayor. Un repositorio superficial es creado al proporcionar la opción
", + "repositorio superficial": "--deptha linkgit:git-clone[1], y su historial puede ser profundizado posteriormente con linkgit:git-fetch[1].Un repositorio superficial tienen un historial incompleto, donde algunos de los padres de sus confirmaciones han sido cauterizados (en otras palabras, se le ha instruido a Git a pretender que esas confirmaciones no tienen padres, aunque estén registrados en el objeto confirmación). En ocasiones esto es útil cuando sólo se esta interesado en el historial reciente de un proyecto, aunque el historial real almacenado en el upstream es mucho mayor. Un repositorio superficial es creado al proporcionar la opción
", "entrada de reserva": "--deptha git-clone[1], y su historial puede ser profundizado posteriormente con git-fetch[1].Un objeto usado para almacenar temporalmente el contenido de un directorio de trabajo sucio así como el índice para reuso futuro.
", "submódulo": "Un repositorio que mantiene el historial de un proyecto separado dentro de otro repositorio; a este último se le llama superproyecto.
", "superproyecto": "Un repositorio que referencía repositorios de otros proyectos en su árbol de trabajo como submódulos. El superproyecto sabe de los nombres -mas no mantiene copias- de objetos commit de los submódulos contenidos.
", - "referencia simbólica": "Referencia simbólica; en lugar de contener el identificador SHA-1 por sí mismo, está en el formato: ref: referencia/a/algo y cuando es referenciado, se desreferencía recursivamente de ésta referencia. HEAD es el principal ejemplo de una referencia simbólica. Las referencias simbólicas son manipuladas con el comando linkgit:git-symbolic-ref[1].
", + "referencia simbólica": "Referencia simbólica; en lugar de contener el identificador SHA-1 por sí mismo, está en el formato: ref: referencia/a/algo y cuando es referenciado, se desreferencía recursivamente de ésta referencia. HEAD es el principal ejemplo de una referencia simbólica. Las referencias simbólicas son manipuladas con el comando git-symbolic-ref[1].
", "tag (etiqueta)": "Una referencia bajo el espacio de nombres refs/tags/`que apunta a un objeto de tipo arbitrario (típicamente una etiqueta que apunta ya sea a una <<def_tag_object,etiqueta>> o a un <<def_commit_object,commit>>). En contraste a <<def_head,head>>, una etiqueta no es actualizada por el comando `commit. Una etiqueta Git no tiene nada que ver con una etiqueta Lisp (la cual sería llamada tipo de objeto en contexto Git). Una etiqueta es más típicamente usada para marcar un punto en particular en la cadena de ascendencia.
", "objeto etiqueta": "Un objeto que contiene una referencia apuntando a otro objeto, el cual puede contener una mensaje tal como un objeto commit. También puede contener una firma (PGP), en cuyo caso se le llama un \"objeto etiqueta firmado\".
", "rama tópica": "Una rama Git regular que es usada por un desarrollador para identificar una linea de desarrollo conceptual. Dado que las ramas son fáciles y baratas, a menudo es deseable tener varias ramas pequeñas que contengan conceptos bien definidos o pequeños cambios incrementales relacionados.
", - "remolque": "Metadatos clave-valor. Los remolques se encuentran opcionalmente al final del mensaje de confirmación. También se les conoce como \"pies de página\" o \"etiquetas\" en otras comunidades. Ver linkgit:git-interpret-trailers[1].
", + "remolque": "Metadatos clave-valor. Los remolques se encuentran opcionalmente al final del mensaje de confirmación. También se les conoce como \"pies de página\" o \"etiquetas\" en otras comunidades. Ver git-interpret-trailers[1].
", "árbol": "Ya sea un árbol de trabajo o un objeto árbol junto con el blob dependiente y objetos árbol (ej. una representación almacenada de un árbol de trabajo).
", "objeto árbol": "Un objeto conteniendo una lista de nombres de fichero y modos junto con referencias al blob asociado y/o objetos árbol. Un árbol es equivalente a un directorio.
", "árbol-ismo (también arbolismo)": "Un objeto árbol o un objeto que puede ser recursivamente desreferenciado a un objeto árbol. Desreferenciar un objeto commit resulta en el objeto árbol correspondiente al directorio raíz de la revisión. Los siguientes son todos árbol-ismos: un confirmacion-ismo, un objeto árbol, un objeto etiqueta que apunta a un objeto árbol, un objeto etiqueta que apunta a un objeto etiqueta que apunta a un objeto árbol, etc..
", diff --git a/external/docs/data/glossary/fr.json b/external/docs/data/glossary/fr.json index 9df57cb5a8..414607f8ac 100644 --- a/external/docs/data/glossary/fr.json +++ b/external/docs/data/glossary/fr.json @@ -23,13 +23,13 @@ "sale": "Un arbre de travail est dit \"sale\" s’il contient des modifications qui n’ont pas été validées dans la branche actuelle.
", "fusion maléfique": "Une fusion maléfique est une fusion qui introduit des modifications qui n’apparaissent dans aucun des parents.
", "avance rapide": "Une avance rapide est un type spécial de fusion où vous avez une révision et vous \"fusionnez\" les modifications d’une autre branche qui se trouvent être descendantes de ce que vous avez. Dans ce cas, vous ne faites pas un nouveau commit de fusion mais vous mettez simplement à jour votre branche pour qu’elle pointe vers la même révision que la branche que vous fusionnez. Cela se produit fréquemment sur une branche de suivis à distance d’un dépôt distant.
", - "récupérer": "Récupérer une branche signifie obtenir la référence head de la branche à partir d’un dépôt distant, pour trouver quels objets manquent dans la base de données d’objets locale, et les obtenir également. Voir aussi linkgit:git-fetch[1].
", + "récupérer": "Récupérer une branche signifie obtenir la référence head de la branche à partir d’un dépôt distant, pour trouver quels objets manquent dans la base de données d’objets locale, et les obtenir également. Voir aussi git-fetch[1].
", "système de fichiers": "Linus Torvalds a conçu à l’origine Git pour être un système de fichiers en espace utilisateur, c’est-à-dire l’infrastructure pour contenir les fichiers et les répertoires. Cela garantissait l’efficacité et la rapidité de Git.
", "Archives Git": "Synonyme de dépôt (pour les utilisateurs d’Arch).
", - "fichier-git": "Un simple fichier
", - "greffes": ".gità la racine d’un arbre de travail qui pointe vers le répertoire qui est le vrai dépôt. Pour une utilisation appropriée voir linkgit:git-worktree[1] ou linkgit:git-submodule[1]. Pour la syntaxe voir linkgit:gitrepository-layout[5].Les greffes permettent de relier deux lignes de développement différentes en enregistrant de fausses informations d’ascendance pour les commits. De cette façon, vous pouvez faire croire à Git que l’ensemble des parents d’un commit est différent de ce qui a été enregistré lors de la création du commit. Configuré via le fichier
\n.git/info/grafts.\n", + "fichier-git": "Notez que le mécanisme de greffes est dépassé et peut conduire à des problèmes de transfert d’objets entre dépôts ; voir linkgit:git-replace[1] pour un système plus flexible et plus robuste pour faire la même chose.
\nUn simple fichier
", + "greffes": ".gità la racine d’un arbre de travail qui pointe vers le répertoire qui est le vrai dépôt. Pour une utilisation appropriée voir git-worktree[1] ou git-submodule[1]. Pour la syntaxe voir gitrepository-layout[5].Les greffes permettent de relier deux lignes de développement différentes en enregistrant de fausses informations d’ascendance pour les commits. De cette façon, vous pouvez faire croire à Git que l’ensemble des parents d’un commit est différent de ce qui a été enregistré lors de la création du commit. Configuré via le fichier
\n.git/info/grafts.\n", "hachage": "Notez que le mécanisme de greffes est dépassé et peut conduire à des problèmes de transfert d’objets entre dépôts ; voir git-replace[1] pour un système plus flexible et plus robuste pour faire la même chose.
\nDans le contexte de Git, synonyme de nom de l’objet.
", - "tête": "Une référence nommée au commit au sommet d’une branche. Les têtes sont stockées dans un fichier dans le répertoire
", + "tête": "$GIT_DIR/refs/heads/, sauf lors de l’utilisation de refs empaquetées. (Voir linkgit:git-pack-refs[1].)Une référence nommée au commit au sommet d’une branche. Les têtes sont stockées dans un fichier dans le répertoire
", "HEAD": "$GIT_DIR/refs/heads/, sauf lors de l’utilisation de refs empaquetées. (Voir git-pack-refs[1].)La branche actuelle. Plus en détail : Votre arbre de travail est normalement dérivé de l’état de l’arbre auquel fait référence HEAD. HEAD est une référence à l’un des têtes de votre dépôt, sauf si vous utilisez une HEAD détachée, auquel cas elle fait directement et librement référence à un commit.
", "réf. tête": "Un synonyme de tête.
", "crochet": "Au cours de l’exécution normale de plusieurs commandes Git, des appels sont faits à des scripts optionnels qui permettent à un développeur d’ajouter des fonctionnalités ou des vérifications. Typiquement, les crochets permettent de pré-vérifier une commande et de l’interrompre éventuellement, et permettent une post-notification une fois l’opération effectuée. Les scripts de crochet se trouvent dans le répertoire
", @@ -48,22 +48,22 @@ "superposition": "$GIT_DIR/hooks/, et sont activés en retirant simplement le suffixe.sampledu nom du fichier. Dans les versions précédentes de Git, vous deviez les rendre exécutables.Ne fait que mettre à jour et ajouter des fichiers dans le répertoire de travail, mais ne les supprime pas, de la même manière que cp -R mettrait à jour le contenu du répertoire de destination. C’est le mode par défaut de l'extraction lors de l’extraction de fichiers depuis l'index ou un arbresque. En revanche, le mode sans superposition supprime également les fichiers suivis qui ne sont pas présents dans la source, de manière similaire à rsync --delete.
", "paquet": "Un ensemble d’objets qui ont été compressés en un seul fichier (pour gagner de l’espace ou pour les transmettre efficacement).
", "index du paquet": "La liste des identifiants, et d’autres informations, des objets dans un paquet, pour aider à accéder efficacement au contenu d’un paquet.
", - "spéc-de-chemin": "Motif utilisé pour limiter les chemins dans les commandes Git.
\n\n\nLes spécifications de chemin sont utilisées sur la ligne de commande de \"git ls-files\", \"git ls-tree\", \"git add\", \"git grep\", \"git diff\", \"git checkout\" et de nombreuses autres commandes pour limiter la portée des opérations à un sous-ensemble de l’arbre ou de l’arbre de travail. Consultez la documentation de chaque commande pour savoir si les chemins sont relatifs au répertoire courant ou au premier niveau. La syntaxe de spécificateurs de chemin est la suivante :
\n\n\n\n\n\n\n\n
\n- \n
\ntout chemin correspond à lui-même
\n- \n
\nle spécificateur de chemin jusqu’à la dernière barre oblique représente un préfixe de répertoire. La portée de ce spécificateur de chemin est limitée à ce sous-arbre.
\n- \n
\nle reste du spécificateur de chemin est un motif pour le reste du nom de chemin. Les chemins relatifs au préfixe du répertoire seront comparés à ce motif en utilisant fnmatch(3) ; en particulier, * et ? peuvent correspondre aux séparateurs de répertoire.
\n\n\nPar exemple, Documentation/*.jpg correspondra à tous les fichiers .jpg du sous-arbre Documentation, y compris Documentation/chapitre_1/figure_1.jpg.
\n\n\nUn spécificateur de chemin qui commence par un deux-points
\n:a une signification particulière. Dans la forme courte, le deux-points de tête:sont suivis par zéro ou plusieurs lettres de la \"signature magique\" (qui se termine éventuellement par un autre deux-points:), et le reste est le motif à faire correspondre au chemin. La \"signature magique\" est constituée de symboles ASCII qui ne sont ni des caractères alphanumériques, ni des glob, ni des caractères spéciaux de regex, ni des deux-points. Le deux-points facultatif qui termine la \"signature magique\" peut être omis si le motif commence par un caractère qui n’appartient pas au jeu de symboles de la \"signature magique\" et qui n’est pas un deux-points.\n\nDans la forme longue, le deux-points de tête
\n:est suivi d’une parenthèse ouverte (, d’une liste de zéro ou plus de \"mots magiques\" séparée par des virgules, et d’une parenthèse fermée ), et le reste est le motif à comparer au chemin.\n\nUn spécificateur de chemin avec seulement un deux-points signifie \"il n’y a pas de spécificateur de chemin\". Cette forme ne doit pas être combinée avec d’autres spécificateurs de chemin.
\n\n", + "spéc-de-chemin": "\n\n\n\n\n
\n- top
\n- \n
\nLe mot magique
\ntop(signature magique :/) fait correspondre le motif à partir de la racine de l’arbre de travail, même si vous exécutez la commande depuis un sous-répertoire.- literal
\n- \n
\nLes caractères génériques dans le motif tels que
\n*ou ? sont traités comme des caractères littéraux.- icase
\n- \n
\nCorrespondance insensible à la casse.
\n- glob
\n- \n
\nGit traite le motif comme un glob shell qui peut être utilisé par fnmatch(3) avec l’option FNM_PATHNAME : les caractères génériques du motif ne correspondent pas à un / dans le chemin d’accès. Par exemple, \"Documentation/*.html\" ; correspond à \"Documentation/git.html\" ; mais pas à \"Documentation/ppc/ppc.html\" ; ou à \"tools/perf/Documentation/perf.html\" ;.
\n\n\nDeux astérisques consécutifs (\"
\n**\") dans les motifs comparés au nom de chemin complet peuvent avoir une signification spéciale :\n\n\n
\n- \n
\nUn \"
\n**\" suivi d’une barre oblique signifie une correspondance dans tous les répertoires. Par exemple, \"**/foo\" correspond au fichier ou au répertoire \"foo\" n’importe où. \"**/foo/bar\" correspond au fichier ou au répertoire \"bar\" n’importe où, directement sous le répertoire \"foo\".- \n
\nUn \"
\n/**\" de queue correspond à tout ce qui se trouve à l’intérieur. Par exemple, \"abc/**\" correspond à tous les fichiers du répertoire \"abc\", relativement à l’emplacement du fichier.gitignore, avec une profondeur infinie.- \n
\nUne barre oblique suivie de deux astérisques consécutifs puis d’une barre oblique correspond à zéro ou plusieurs répertoires. Par exemple, \"
\na/**/b\" correspond à \"a/b\", \"a/x/b\", \"a/x/y/b\" et ainsi de suite.- \n
\nLes autres astérisques consécutifs sont considérés comme non valides.
\n\n\nLa correspondance globale est incompatible avec la correspondance littérale.
\n- attr
\n- \n
\nAprès
\nattr:vient une liste, séparée par des espaces, d'« exigences d’attribut », qui doivent tous être satisfaits pour que le chemin soit considéré comme une correspondance ; ceci est en plus de la correspondance habituelle des motifs non-magiques de spécificateur de chemin. Voir linkgit:gitattributes[5].\n\nChacun des attributs requis pour le chemin prend l’une de ces formes :
\n\n\n\n
\n- \n
\n\"
\nATTR\" exige que l’attributATTRsoit défini.- \n
\n\"
\n-ATTR\" exige que l’attributATTRsoit désactivé.- \n
\n\"
\nATTR=VALEUR\" exige que l’attributATTRsoit défini comme la chaîne de caractèresVALEUR.- \n
\n\"
\n!ATTR\" exige que l’attributATTRsoit non spécifié.\n\nNotez que lors de la correspondance avec un objet arbre, les attributs sont toujours obtenus à partir de l’arbre de travail, et non de l’objet arbre donné.
\n- exclude
\n- \n
\nAprès qu’un chemin corresponde à un spécificateur de chemin non exclu, il sera parcouru par tous les spécificateurs de chemin exclus (signature magique :
\n!ou son synonyme^). S’il correspond, le chemin est ignoré. S’il n’y a pas de chemin d’accès non exclu, l’exclusion est appliquée au résultat comme si elle était invoquée sans spécificateur de chemin.Motif utilisé pour limiter les chemins dans les commandes Git.
\n\n\nLes spécifications de chemin sont utilisées sur la ligne de commande de \"git ls-files\", \"git ls-tree\", \"git add\", \"git grep\", \"git diff\", \"git checkout\" et de nombreuses autres commandes pour limiter la portée des opérations à un sous-ensemble de l’arbre ou de l’arbre de travail. Consultez la documentation de chaque commande pour savoir si les chemins sont relatifs au répertoire courant ou au premier niveau. La syntaxe de spécificateurs de chemin est la suivante :
\n\n\n\n\n\n\n\n
\n- \n
\ntout chemin correspond à lui-même
\n- \n
\nle spécificateur de chemin jusqu’à la dernière barre oblique représente un préfixe de répertoire. La portée de ce spécificateur de chemin est limitée à ce sous-arbre.
\n- \n
\nle reste du spécificateur de chemin est un motif pour le reste du nom de chemin. Les chemins relatifs au préfixe du répertoire seront comparés à ce motif en utilisant fnmatch(3) ; en particulier, * et ? peuvent correspondre aux séparateurs de répertoire.
\n\n\nPar exemple, Documentation/*.jpg correspondra à tous les fichiers .jpg du sous-arbre Documentation, y compris Documentation/chapitre_1/figure_1.jpg.
\n\n\nUn spécificateur de chemin qui commence par un deux-points
\n:a une signification particulière. Dans la forme courte, le deux-points de tête:sont suivis par zéro ou plusieurs lettres de la \"signature magique\" (qui se termine éventuellement par un autre deux-points:), et le reste est le motif à faire correspondre au chemin. La \"signature magique\" est constituée de symboles ASCII qui ne sont ni des caractères alphanumériques, ni des glob, ni des caractères spéciaux de regex, ni des deux-points. Le deux-points facultatif qui termine la \"signature magique\" peut être omis si le motif commence par un caractère qui n’appartient pas au jeu de symboles de la \"signature magique\" et qui n’est pas un deux-points.\n\nDans la forme longue, le deux-points de tête
\n:est suivi d’une parenthèse ouverte (, d’une liste de zéro ou plus de \"mots magiques\" séparée par des virgules, et d’une parenthèse fermée ), et le reste est le motif à comparer au chemin.\n\nUn spécificateur de chemin avec seulement un deux-points signifie \"il n’y a pas de spécificateur de chemin\". Cette forme ne doit pas être combinée avec d’autres spécificateurs de chemin.
\n\n", "parent": "\n\n\n\n\n
\n- top
\n- \n
\nLe mot magique
\ntop(signature magique :/) fait correspondre le motif à partir de la racine de l’arbre de travail, même si vous exécutez la commande depuis un sous-répertoire.- literal
\n- \n
\nLes caractères génériques dans le motif tels que
\n*ou ? sont traités comme des caractères littéraux.- icase
\n- \n
\nCorrespondance insensible à la casse.
\n- glob
\n- \n
\nGit traite le motif comme un glob shell qui peut être utilisé par fnmatch(3) avec l’option FNM_PATHNAME : les caractères génériques du motif ne correspondent pas à un / dans le chemin d’accès. Par exemple, \"Documentation/*.html\" ; correspond à \"Documentation/git.html\" ; mais pas à \"Documentation/ppc/ppc.html\" ; ou à \"tools/perf/Documentation/perf.html\" ;.
\n\n\nDeux astérisques consécutifs (\"
\n**\") dans les motifs comparés au nom de chemin complet peuvent avoir une signification spéciale :\n\n\n
\n- \n
\nUn \"
\n**\" suivi d’une barre oblique signifie une correspondance dans tous les répertoires. Par exemple, \"**/foo\" correspond au fichier ou au répertoire \"foo\" n’importe où. \"**/foo/bar\" correspond au fichier ou au répertoire \"bar\" n’importe où, directement sous le répertoire \"foo\".- \n
\nUn \"
\n/**\" de queue correspond à tout ce qui se trouve à l’intérieur. Par exemple, \"abc/**\" correspond à tous les fichiers du répertoire \"abc\", relativement à l’emplacement du fichier.gitignore, avec une profondeur infinie.- \n
\nUne barre oblique suivie de deux astérisques consécutifs puis d’une barre oblique correspond à zéro ou plusieurs répertoires. Par exemple, \"
\na/**/b\" correspond à \"a/b\", \"a/x/b\", \"a/x/y/b\" et ainsi de suite.- \n
\nLes autres astérisques consécutifs sont considérés comme non valides.
\n\n\nLa correspondance globale est incompatible avec la correspondance littérale.
\n- attr
\n- \n
\nAprès
\nattr:vient une liste, séparée par des espaces, d'« exigences d’attribut », qui doivent tous être satisfaits pour que le chemin soit considéré comme une correspondance ; ceci est en plus de la correspondance habituelle des motifs non-magiques de spécificateur de chemin. Voir gitattributes[5].\n\nChacun des attributs requis pour le chemin prend l’une de ces formes :
\n\n\n\n
\n- \n
\n\"
\nATTR\" exige que l’attributATTRsoit défini.- \n
\n\"
\n-ATTR\" exige que l’attributATTRsoit désactivé.- \n
\n\"
\nATTR=VALEUR\" exige que l’attributATTRsoit défini comme la chaîne de caractèresVALEUR.- \n
\n\"
\n!ATTR\" exige que l’attributATTRsoit non spécifié.\n\nNotez que lors de la correspondance avec un objet arbre, les attributs sont toujours obtenus à partir de l’arbre de travail, et non de l’objet arbre donné.
\n- exclude
\n- \n
\nAprès qu’un chemin corresponde à un spécificateur de chemin non exclu, il sera parcouru par tous les spécificateurs de chemin exclus (signature magique :
\n!ou son synonyme^). S’il correspond, le chemin est ignoré. S’il n’y a pas de chemin d’accès non exclu, l’exclusion est appliquée au résultat comme si elle était invoquée sans spécificateur de chemin.Un objet commit contient une liste (éventuellement vide) du ou des prédécesseurs logiques dans la ligne de développement, c’est-à-dire ses parents.
", "peler": "L’action de récursivement déréférencer un objet étiquette.
", - "pioche": "Le terme pioche fait référence à une option des routines diffcore qui aide à sélectionner les modifications qui ajoutent ou suppriment une chaîne de texte donnée. Avec l’option
", + "pioche": "--pickaxe-all, elle peut être utilisée pour afficher la totalité des ensembles de modifications qui ont introduit ou supprimé, disons, une ligne de texte particulière. Voir linkgit:git-diff[1].Le terme pioche fait référence à une option des routines diffcore qui aide à sélectionner les modifications qui ajoutent ou suppriment une chaîne de texte donnée. Avec l’option
", "plomberie": "--pickaxe-all, elle peut être utilisée pour afficher la totalité des ensembles de modifications qui ont introduit ou supprimé, disons, une ligne de texte particulière. Voir git-diff[1].Nom mignon pour core Git.
", "porcelaine": "Nom mignon pour les programmes et les suites de programmes dépendant de core Git, présentant une interface de haut niveau au noyau Git. Les porcelaines exposent une interface plus SCM que la la plomberie.
", "référence par-arbre-de-travail": "Les références qui sont par-arbre-de-travail, plutôt que globales. Il ne s’agit actuellement que de HEAD et de toutes les références qui commencent par
", - "pseudoref": "refs/bisect/, mais pourraient ultérieurement inclure d’autres références inhabituelles.Une réf qui a une sémantique différente des réfs normales. Ces réfs peuvent être accédées par des commandes Git normales mais peuvent pas être écrites par des commandes comme linkgit:git-update-ref[1].
\n\n\nLes pseudo-réfs suivantes sont connues de Git :
\n\n", - "tirage, tirer": "\n
\n- \n
\n\n
FETCH_HEADest écrite par linkgit:git-fetch[1] ou linkgit:git-pull[1]. Elle peut faire référence à plusieurs identifiants d’objets. Chaque identifiant d’objet est annoté avec des métadonnées indiquant l’endroit d’où il a été récupéré et son statut de récupération.- \n
\n\n
MERGE_HEADest écrit par linkgit:git-merge[1] lors de la résolution des conflits de fusion. Il contient tous les identifiants de commit qui sont fusionnés.Tirer une branche signifie la récupérer et la fusionner. Voir aussi linkgit:git-pull[1].
", + "pseudoref": "Une réf qui a une sémantique différente des réfs normales. Ces réfs peuvent être accédées par des commandes Git normales mais peuvent pas être écrites par des commandes comme git-update-ref[1].
\n\n\nLes pseudo-réfs suivantes sont connues de Git :
\n\n", + "tirage, tirer": "\n
\n- \n
\n\n
FETCH_HEADest écrite par git-fetch[1] ou git-pull[1]. Elle peut faire référence à plusieurs identifiants d’objets. Chaque identifiant d’objet est annoté avec des métadonnées indiquant l’endroit d’où il a été récupéré et son statut de récupération.- \n
\n\n
MERGE_HEADest écrit par git-merge[1] lors de la résolution des conflits de fusion. Il contient tous les identifiants de commit qui sont fusionnés.Tirer une branche signifie la récupérer et la fusionner. Voir aussi git-pull[1].
", "pousser": "Pousser une branche signifie obtenir la la référence de tête à partir d’un d’un dépôt distant, savoir s’il s’agit d’un ancêtre de la référence de tête locale de la branche et, dans ce cas, placer tous les objets, qui sont accessibles de la référence de tête locale et qui sont manquants dans le dépôt distant, dans la la base de données d’objets distante et mettre à jour la référence de tête distante. Si la la tête distante n’est pas un ancêtre de la tête locale, la poussée échoue.
", "accessible": "Tous les ancêtres d’un commit donné sont dits « accessibles » à partir de ce commit. Plus généralement, un objet est accessible depuis un autre si nous pouvons atteindre l’un de l’autre par une chaîne qui suit les étiquettes à tout ce qu’ils marquent, les commits à leurs parents ou arbres, et les arbres aux arbres ou les blobs qu’ils contiennent.
", "bitmaps d’accessibilité": "Les bitmaps d’accessibilité stockent des informations sur l'accessibilité d’un ensemble sélectionné de commits dans un fichier paquet, ou un index multi-paquet (MIDX), pour accélérer la recherche d’objets. Les bitmaps sont stockés dans un fichier \".bitmap\". Un dépôt peut avoir au maximum un fichier bitmap en cours d’utilisation. Le fichier bitmap peut appartenir soit à un paquet, soit à l’index multi-paquet du dépôt (s’il existe).
", "rebaser, rebasage": "Réappliquer une série de modifications d’une branche à une autre base et réinitialiser la tête de cette branche au résultat.
", - "réf, référence": "Un nom qui pointe vers un nom d’objet ou une autre réf (cette dernière est appelée réf symbolique). Pour plus de commodité, une réf peut parfois être abrégée lorsqu’elle est utilisée comme argument pour une commande Git ; voir linkgit:gitrevisions[7] pour plus de détails. Les références sont stockées dans le dépôt.
\n\n\nL’espace de référence est hiérarchique. Les noms réf doivent soit commencer par
\nrefs/ou être situés dans la racine de la hiérarchie. Pour ce dernier, leur nom doit suivre ces règles :\n", - "reflog": "\n
\n- \n
\nLe nom se compose uniquement de caractères majuscules ou de soulignements.
\n- \n
\nLe nom se termine par \"
\n_HEAD\" ou est égal à \"HEAD\".\n\nIl y a quelques réfs irrégulières dans la racine de la hiérarchie qui ne correspondent pas à ces règles. La liste suivante est exhaustive et ne peut être étendue à l’avenir :
\n- \n
\n\n
AUTO_MERGE- \n
\n\n
BISECT_EXPECTED_REV- \n
\n\n
NOTES_MERGE_PARTIAL- \n
\n\n
NOTES_MERGE_REF- \n
\n\n
MERGE_AUTOSTASH\n\nDifférentes sous-hiérarchies sont utilisées à des fins différentes. par exemple, la hiérarchie
\nrefs/heads/est utilisée pour représenter les branches locales) alors que la hiérarchierefs/tagsest utilisée pour représenter les balises locales.Un reflog montre l'« historique » local d’une référence. En d’autres termes, il peut vous dire quelle était la 3ème dernière révision dans ce dépôt, et quel était l’état actuel dans ce dépôt, hier à 21h14. Voir linkgit:git-reflog[1] pour plus de détails.
", - "refspec": "Un \"refspec\" est utilisé par fetch et push pour décrire la correspondance entre le réf distant et le réf local. Voir linkgit:git-fetch[1] ou linkgit:git-push[1] pour les détails.
", + "réf, référence": "Un nom qui pointe vers un nom d’objet ou une autre réf (cette dernière est appelée réf symbolique). Pour plus de commodité, une réf peut parfois être abrégée lorsqu’elle est utilisée comme argument pour une commande Git ; voir gitrevisions[7] pour plus de détails. Les références sont stockées dans le dépôt.
\n\n\nL’espace de référence est hiérarchique. Les noms réf doivent soit commencer par
\nrefs/ou être situés dans la racine de la hiérarchie. Pour ce dernier, leur nom doit suivre ces règles :\n", + "reflog": "\n
\n- \n
\nLe nom se compose uniquement de caractères majuscules ou de soulignements.
\n- \n
\nLe nom se termine par \"
\n_HEAD\" ou est égal à \"HEAD\".\n\nIl y a quelques réfs irrégulières dans la racine de la hiérarchie qui ne correspondent pas à ces règles. La liste suivante est exhaustive et ne peut être étendue à l’avenir :
\n- \n
\n\n
AUTO_MERGE- \n
\n\n
BISECT_EXPECTED_REV- \n
\n\n
NOTES_MERGE_PARTIAL- \n
\n\n
NOTES_MERGE_REF- \n
\n\n
MERGE_AUTOSTASH\n\nDifférentes sous-hiérarchies sont utilisées à des fins différentes. par exemple, la hiérarchie
\nrefs/heads/est utilisée pour représenter les branches locales) alors que la hiérarchierefs/tagsest utilisée pour représenter les balises locales.Un reflog montre l'« historique » local d’une référence. En d’autres termes, il peut vous dire quelle était la 3ème dernière révision dans ce dépôt, et quel était l’état actuel dans ce dépôt, hier à 21h14. Voir git-reflog[1] pour plus de détails.
", + "refspec": "Un \"refspec\" est utilisé par fetch et push pour décrire la correspondance entre le réf distant et le réf local. Voir git-fetch[1] ou git-push[1] pour les détails.
", "dépôt distant": "Un dépôt qui est utilisé pour suivre le même projet mais qui réside ailleurs. Pour communiquer avec les distants, voir recupérer ou poussée.
", "branche de suivi à distance": "Une réf qui est utilisée pour suivre les changements d’un autre dépôt. Elle ressemble typiquement à refs/remotes/foo/bar (indiquant qu’elle suit une branche nommée bar dans un dépôt distant nommé foo), et correspond au côté droit d’un refspec configuré. Une branche de suivi à distance ne doit pas contenir de modifications directes ou avoir des commits locaux effectués sur elle.
", "dépôt": "Une collection de refs accompagnée d’une base de données d’objets contenant tous les objets qui sont joignables à partir des refs, éventuellement accompagnés de métadonnées provenant d’une ou plusieurs porcelaines. Un dépôt peut partager une base de données d’objets avec d’autres dépôts via des mécanismes alternatifs.
", @@ -73,15 +73,15 @@ "SCM": "Gestion du code source (Source Code Management en anglais).
", "SHA-1": "\"Secure Hash Algorithm 1\" une fonction de hachage cryptographique. Dans le contexte de Git, utilisé comme synonyme de nom d’objet.
", "clone superficiel": "Principalement un synonyme de dépôt superficiel mais la phrase rend plus explicite qu’il a été créé en exécutant la commande
", - "dépôt superficiel": "gitclone--depth=....Un dépôt superficiel a un historique incomplet dont certains commits ont des parents « cautérisés » (en d’autres termes, on dit à Git de prétendre que ces commits n’ont pas de parents, même s’ils sont enregistrés dans le l’objet commit). Ceci est parfois utile lorsque vous n’êtes intéressé que par l’historique récent d’un projet même si l’historique réel enregistré dans l’amont est beaucoup plus important. Un dépôt superficiel est créé en donnant l’option
", + "dépôt superficiel": "--depthà linkgit:git-clone[1], et son historique peut être approfondi plus tard avec linkgit:git-fetch[1].Un dépôt superficiel a un historique incomplet dont certains commits ont des parents « cautérisés » (en d’autres termes, on dit à Git de prétendre que ces commits n’ont pas de parents, même s’ils sont enregistrés dans le l’objet commit). Ceci est parfois utile lorsque vous n’êtes intéressé que par l’historique récent d’un projet même si l’historique réel enregistré dans l’amont est beaucoup plus important. Un dépôt superficiel est créé en donnant l’option
", "entrée de remisage": "--depthà git-clone[1], et son historique peut être approfondi plus tard avec git-fetch[1].Un objet utilisé pour stocker temporairement le contenu d’un répertoire de travail sale et l’index pour une réutilisation future.
", "sous-module": "Un dépôt qui contient l’historique d’un projet séparé à l’intérieur d’un autre dépôt (ce dernier est appelé superprojet).
", "superprojet": "Un dépôt qui fait référence aux dépôts d’autres projets dans son arbre de travail comme sous-modules. Le superprojet connaît les noms des objets commit des sous-modules contenus (mais n’en détient pas de copie).
", - "symref ou référence symbolique": "Référence symbolique : au lieu de contenir l’identifiant SHA-1 lui-même, elle est au format ref:refs/quelque/chose et lorsqu’elle est référencée, elle déréférence récursivement vers cette référence. HEAD est un excellent exemple de symref. Les références symboliques sont manipulées avec la commande linkgit:git-symbolic-ref[1].
", + "symref ou référence symbolique": "Référence symbolique : au lieu de contenir l’identifiant SHA-1 lui-même, elle est au format ref:refs/quelque/chose et lorsqu’elle est référencée, elle déréférence récursivement vers cette référence. HEAD est un excellent exemple de symref. Les références symboliques sont manipulées avec la commande git-symbolic-ref[1].
", "étiquette": "Une réf sous l’espace de noms
", "objet étiquette": "refs/tags/qui pointe vers un objet d’un type arbitraire (typiquement, une étiquette pointe vers un objet tag ou un objet commit). Contrairement à une tête, une étiquette n’est pas mise à jour par la commandecommit. Une étiquette Git n’a rien à voir avec un tag Lisp (qui serait appelé un type d’objet dans le contexte de Git). Une étiquette est le plus souvent utilisée pour marquer un point particulier dans la chaîne d’ascendance de commits.Un objet contenant une réf pointant vers un autre objet, qui peut contenir un message tout comme un objet commit. Il peut également contenir une signature (PGP), auquel cas il est appelé un \"objet étiquette signé\".
", "branche thématique": "Une branche régulière de Git qui est utilisée par un développeur pour identifier une ligne conceptuelle de développement. Comme les branches sont très faciles et peu coûteuses, il est souvent souhaitable d’avoir plusieurs petites branches qui contiennent chacune des concepts très bien définis ou de petits changements incrémentiels mais liés.
", - "ligne terminale": "Métadonnées de type clé-valeur. Les lignes terminales sont en option à la fin d’un message de validation. Elles peuvent être appelées \"pieds\" ou \"étiquettes\" dans d’autres communautés. Voir linkgit:git-interpret-trailers[1].
", + "ligne terminale": "Métadonnées de type clé-valeur. Les lignes terminales sont en option à la fin d’un message de validation. Elles peuvent être appelées \"pieds\" ou \"étiquettes\" dans d’autres communautés. Voir git-interpret-trailers[1].
", "arbre": "Soit un arbre de travail, soit un objet arbre avec les blob et objets arbre dépendants (c’est-à-dire une représentation stockée d’un arbre de travail).
", "objet arbre": "Un objet contenant une liste de noms et de modes de fichiers ainsi que des références aux objets blob et/ou arbres associés. Un arbre est équivalent à un répertoire.
", "arbre-esque": "Un objet arbre ou un objet qui peut être déréférencé récursivement vers un objet arbre. Le déréférencement d’un objet commit donne l’objet arbre correspondant au répertoire racine de la révision. Les éléments suivants sont tous des arbres-esques : un commit-esque, un objet arbre, un objet étiquette qui pointe vers un objet arbre, un objet étiquette qui pointe vers un objet étiquette qui pointe vers un objet arbre, etc.
", diff --git a/external/docs/data/glossary/ja.json b/external/docs/data/glossary/ja.json index 826f708678..5ab7fa666f 100644 --- a/external/docs/data/glossary/ja.json +++ b/external/docs/data/glossary/ja.json @@ -23,13 +23,13 @@ "ダーティ (dirty)": "ワーキングツリーは、現在のブランチ に対して コミット されていない変更が含まれている場合、「ダーティ」であると言われます。
", "邪悪なマージ (evil merge)": "邪悪なマージとは、どの 親 にも表示されない変更を導入する マージ のことです。
", "早送り (fast-forward)": "早送りとは、特殊なタイプの マージ で、ある リビジョン が、たまたまその子孫である別の ブランチ の変更をマージするときに起こるものです。このような場合、新たに マージ コミット を行うのではなく、マージするブランチと同じリビジョンを指すようにブランチを更新するだけです。これは、リモート リポジトリ の リモートトラッキングブランチ で頻繁に発生します。
", - "フェッチ (fetch)": "ブランチ のフェッチとは、リモートの リポジトリ からブランチの ヘッド参照 を取得し、ローカルの オブジェクトデータベース から足りないオブジェクトを探して、それらも取得することを指します。linkgit:git-fetch[1] も参照してください。
", + "フェッチ (fetch)": "ブランチ のフェッチとは、リモートの リポジトリ からブランチの ヘッド参照 を取得し、ローカルの オブジェクトデータベース から足りないオブジェクトを探して、それらも取得することを指します。git-fetch[1] も参照してください。
", "ファイルシステム (file system)": "リーナス・トーバルズはもともと、Gitをユーザー空間のファイルシステム、すなわち、ファイルとディレクトリを保持するためのインフラストラクチャとして設計しました。それによって、Gitの効率と速度が確保されました。
", "Git アーカイブ (Git archive)": "リポジトリの同義語 (arch の人々向け)。
", - "gitファイル (gitfile)": "ワーキングツリーのルートにあるプレーンなファイル
", - "移植 (grafts)": ".gitは、実際のリポジトリとなるディレクトリを指します。適切な使用については linkgit:git-worktree[1] または linkgit:git-submodule[1] を参照してください。構文については linkgit:gitrepository-layout[5] を参照してください。移植を使用すると、コミットの偽の祖先情報を記録することで、2つの異なる開発ラインを結合できます。このようにして、Gitに コミット の 親 のセット が、コミットが作成されたときに記録したものとは異なるというふりをさせることができます。
\n.git/info/graftsファイルを介して構成されます。\n", + "gitファイル (gitfile)": "移植 の仕組みは時代遅れで、リポジトリ間でオブジェクトを転送する際に問題になる場合があることに注意してください。同じことを行うためのより柔軟で堅牢なシステムについては linkgit:git-replace[1] をご覧ください。
\nワーキングツリーのルートにあるプレーンなファイル
", + "移植 (grafts)": ".gitは、実際のリポジトリとなるディレクトリを指します。適切な使用については git-worktree[1] または git-submodule[1] を参照してください。構文については gitrepository-layout[5] を参照してください。移植を使用すると、コミットの偽の祖先情報を記録することで、2つの異なる開発ラインを結合できます。このようにして、Gitに コミット の 親 のセット が、コミットが作成されたときに記録したものとは異なるというふりをさせることができます。
\n.git/info/graftsファイルを介して構成されます。\n", "ハッシュ (hash)": "移植 の仕組みは時代遅れで、リポジトリ間でオブジェクトを転送する際に問題になる場合があることに注意してください。同じことを行うためのより柔軟で堅牢なシステムについては git-replace[1] をご覧ください。
\nGit の文脈では、 オブジェクト名 の同義語です。
", - "ヘッド (head)": "名前を付けて参照する ブランチ の先端にある コミット のことです。ヘッダは、パックされた参照を使うとき以外は、
", + "ヘッド (head)": "$GIT_DIR/refs/heads/ディレクトリにあるファイルに格納されます。(linkgit:git-pack-refs[1] を参照してください。)名前を付けて参照する ブランチ の先端にある コミット のことです。ヘッダは、パックされた参照を使うとき以外は、
", "HEAD": "$GIT_DIR/refs/heads/ディレクトリにあるファイルに格納されます。(git-pack-refs[1] を参照してください。)現在の branch。詳細: ワーキングツリー は通常、HEADによって参照されるツリーの状態から派生します。HEADはリポジトリ内の ヘッド の1つを参照するものですが、 分離したHEAD を使用する場合は、任意のコミットを直接参照します。
", "ヘッド参照 (head ref)": "head と同義です。
", "フック (hook)": "Gitコマンドの通常の実行中に、開発者が機能やチェックを追加するためのオプションのスクリプトを呼び出すことができます。典型的には、フックはコマンドの事前検証をして中止を可能にし、操作の終了後に事後通知を可能にします。フックスクリプトは
", @@ -48,22 +48,22 @@ "オーバーレイ (overlay)": "$GIT_DIR/hooks/ディレクトリにあり、ファイル名から.sampleというサフィックスを取り除くだけで有効になります。以前のバージョンのGitでは、それらを実行可能にする必要がありました。作業ディレクトリへのファイルの更新と追加のみを行う一方で削除は行わない、 cp -R が宛先ディレクトリの内容を更新するのと同様の方法です。これは、チェックアウト が インデックス や ツリーの性質を持つものからファイルをチェックアウトするときにおけるデフォルトモードです。一方、非オーバーレイ モードでは、 rsync --delete のように、ソースに存在しない追跡済みのファイルも削除されます。
", "パック (pack)": "1つのファイルに圧縮されたオブジェクトのセット（容量を節約するため、または効率的に転送するために）。
", "パックインデックス (pack index)": "パックの中身への効率よいアクセスを補助する、 パック にあるオブジェクトの識別子やその他の情報のリストです。
", - "パススペック (pathspec)": "Git コマンドでパスを制限するために使用するパターン。
\n\n\nパススペック は、\"git ls-files\", \"git ls-tree\", \"git add\", \"git grep\", \"git diff\", \"git checkout\" やその他多くのコマンドで、操作範囲をツリーの一部やワーキングツリーに限定して使用するために使用するものです。パスがカレントディレクトリやトップレベルからの相対パスであるかどうかは、各コマンドのドキュメントを参照してください。パススペックの構文は次のとおりです。
\n\n\n\n\n\n\n\n
\n- \n
\nすべてのパスが一致する
\n- \n
\nパススペックの最後のスラッシュまでの部分は、ディレクトリプレフィックスを表します。そのパススペックのスコープは、そのサブツリーに制限されます。
\n- \n
\nパススペックの残りの部分は、パス名の残りの部分のパターンです。ディレクトリプレフィックスに関連するパスは、fnmatch(3) を使用してそのパターンと照合されます。特に、「*」と「?」 はディレクトリセパレータに一致させることができます。
\n\n\n例えば、Documentation/*.jpg とすると、Documentation/chapter_1/figure_1.jpg を含む、Documentationサブツリーにあるすべての .jpg ファイルにマッチします。
\n\n\nコロン
\n:で始まるパススペックは特別な意味を持ちます。短い形式では、先頭のコロン:の後に 0 個以上の「マジックシグネチャ」文字が続き (オプションで別のコロン:で終了します)、残りの部分がパスに対してマッチするパターンになります。「マジックシグネチャ」は英数字でもグロブでも正規表現の特殊文字でもコロンでもないASCIIシンボルで構成されます。「マジックシグネチャ」を終了するオプションのコロンは、「マジックシグネチャ」シンボルセットに属さず、かつコロンでもない文字でパターンが始まっている場合には省略することが可能です。\n\n長い形式では、先頭のコロン
\n:の後に、開き括弧 (, カンマで区切られた0個以上の「マジックワード」のリスト、閉じ括弧 ) が続き、残りがパスに対してマッチするパターンになります。\n\nコロンのみのパス指定は、「パススペックがない」ことを意味します。この形式は他の パススペック と組み合わせてはいけません。
\n\n", + "パススペック (pathspec)": "\n\n\n\n\n
\n- top
\n- \n
\nマジックワードの
\ntop(マジックシグネチャ:/) は、サブディレクトリの中からコマンドを実行した場合でも、ワーキングツリーのルートからパターンにマッチするようにします。- literal
\n- \n
\nパターン中の
\n*や ? などのワイルドカードは、リテラル文字として扱われます。- icase
\n- \n
\n大文字・小文字を区別せずマッチ。
\n- glob
\n- \n
\nGit はこのパターンを、FNM_PATHNAME フラグを指定した fnmatch(3) に適したシェルグロブとして扱います。パターン中のワイルドカードは、パス名中の / にはマッチしません。例えば、\"Documentation/*.html\" は \"Documentation/git.html\" にマッチしますが、\"Documentation/ppc/ppc.html\" や \"tools/perf/Documentation/perf.html\" にはマッチしません。
\n\n\n2つ連続したアスタリスク(\"
\n**\")はフルパス名に対してマッチするパターンにおいて、特別な意味を持つ場合があります:\n\n\n
\n- \n
\nA leading \"
\n**\" followed by a slash means match in all directories. For example, \"**/foo\" matches file or directory \"foo\" anywhere. \"**/foo/bar\" matches file or directory \"bar\" anywhere that is directly under directory \"foo\".- \n
\n末尾の \"
\n/**\" は、その中にあるすべてのファイルにマッチします。例えば、\"abc/**\" はディレクトリ \"abc\" 内のすべてのファイルにマッチします。これは.gitignoreファイルの位置からの相対パスで、深さは無限です。- \n
\n末尾以外での \"
\n/**\" は、0個以上のディレクトリにマッチします。例えば、\"a/**/b\" は \"a/b\", \"a/x/b\", \"a/x/y/b\" といった具合にマッチする。- \n
\nこれら以外の連続したアスタリスクは無効とする。
\n\n\nグロブの魔法は魔法と互換性がありません。
\n- attr
\n- \n
\n\n
attr:の後にはスペースで区切られた「属性要件」のリストが続き、パスがマッチしたとみなされるためには、これらの要件がすべて満たされなければなりません。これは、普通の魔法のないパススペック パターン マッチングに追加されます。linkgit:gitattributes[5]を参照してください。\n\nパスの各属性要件は、これらのいずれかの形式をとる:
\n\n\n\n
\n- \n
\n\"
\nATTR\" は、属性ATTRを設定することを要求します。- \n
\n\"
\n-ATTR\" は、属性ATTRの設定を解除することを要求しています。- \n
\n\"
\nATTR=VALUE\" は、属性ATTRに文字列VALUEを設定することを要求しています。- \n
\n\"
\n!ATTR\" は、属性ATTRが指定されていないことを要求しています。\n\nツリーオブジェクトに対してマッチングを行う場合、属性は与えられたツリーオブジェクトからではなく、ワーキングツリーから取得されることに注意してください。
\n- exclude
\n- \n
\nパスが何らかの非除外パススペックにマッチした後、すべての除外パススペック (マジックシグネチャ:
\n!またはその同義語^) を通して実行されることになります。マッチした場合、そのパスは無視されます。非除外パススペックがない場合は、パススペックなしで起動された場合と同じように、結果セットに除外が適用されます。Git コマンドでパスを制限するために使用するパターン。
\n\n\nパススペック は、\"git ls-files\", \"git ls-tree\", \"git add\", \"git grep\", \"git diff\", \"git checkout\" やその他多くのコマンドで、操作範囲をツリーの一部やワーキングツリーに限定して使用するために使用するものです。パスがカレントディレクトリやトップレベルからの相対パスであるかどうかは、各コマンドのドキュメントを参照してください。パススペックの構文は次のとおりです。
\n\n\n\n\n\n\n\n
\n- \n
\nすべてのパスが一致する
\n- \n
\nパススペックの最後のスラッシュまでの部分は、ディレクトリプレフィックスを表します。そのパススペックのスコープは、そのサブツリーに制限されます。
\n- \n
\nパススペックの残りの部分は、パス名の残りの部分のパターンです。ディレクトリプレフィックスに関連するパスは、fnmatch(3) を使用してそのパターンと照合されます。特に、「*」と「?」 はディレクトリセパレータに一致させることができます。
\n\n\n例えば、Documentation/*.jpg とすると、Documentation/chapter_1/figure_1.jpg を含む、Documentationサブツリーにあるすべての .jpg ファイルにマッチします。
\n\n\nコロン
\n:で始まるパススペックは特別な意味を持ちます。短い形式では、先頭のコロン:の後に 0 個以上の「マジックシグネチャ」文字が続き (オプションで別のコロン:で終了します)、残りの部分がパスに対してマッチするパターンになります。「マジックシグネチャ」は英数字でもグロブでも正規表現の特殊文字でもコロンでもないASCIIシンボルで構成されます。「マジックシグネチャ」を終了するオプションのコロンは、「マジックシグネチャ」シンボルセットに属さず、かつコロンでもない文字でパターンが始まっている場合には省略することが可能です。\n\n長い形式では、先頭のコロン
\n:の後に、開き括弧 (, カンマで区切られた0個以上の「マジックワード」のリスト、閉じ括弧 ) が続き、残りがパスに対してマッチするパターンになります。\n\nコロンのみのパス指定は、「パススペックがない」ことを意味します。この形式は他の パススペック と組み合わせてはいけません。
\n\n", "親 (parent)": "\n\n\n\n\n
\n- top
\n- \n
\nマジックワードの
\ntop(マジックシグネチャ:/) は、サブディレクトリの中からコマンドを実行した場合でも、ワーキングツリーのルートからパターンにマッチするようにします。- literal
\n- \n
\nパターン中の
\n*や ? などのワイルドカードは、リテラル文字として扱われます。- icase
\n- \n
\n大文字・小文字を区別せずマッチ。
\n- glob
\n- \n
\nGit はこのパターンを、FNM_PATHNAME フラグを指定した fnmatch(3) に適したシェルグロブとして扱います。パターン中のワイルドカードは、パス名中の / にはマッチしません。例えば、\"Documentation/*.html\" は \"Documentation/git.html\" にマッチしますが、\"Documentation/ppc/ppc.html\" や \"tools/perf/Documentation/perf.html\" にはマッチしません。
\n\n\n2つ連続したアスタリスク(\"
\n**\")はフルパス名に対してマッチするパターンにおいて、特別な意味を持つ場合があります:\n\n\n
\n- \n
\nA leading \"
\n**\" followed by a slash means match in all directories. For example, \"**/foo\" matches file or directory \"foo\" anywhere. \"**/foo/bar\" matches file or directory \"bar\" anywhere that is directly under directory \"foo\".- \n
\n末尾の \"
\n/**\" は、その中にあるすべてのファイルにマッチします。例えば、\"abc/**\" はディレクトリ \"abc\" 内のすべてのファイルにマッチします。これは.gitignoreファイルの位置からの相対パスで、深さは無限です。- \n
\n末尾以外での \"
\n/**\" は、0個以上のディレクトリにマッチします。例えば、\"a/**/b\" は \"a/b\", \"a/x/b\", \"a/x/y/b\" といった具合にマッチする。- \n
\nこれら以外の連続したアスタリスクは無効とする。
\n\n\nグロブの魔法は魔法と互換性がありません。
\n- attr
\n- \n
\n\n
attr:の後にはスペースで区切られた「属性要件」のリストが続き、パスがマッチしたとみなされるためには、これらの要件がすべて満たされなければなりません。これは、普通の魔法のないパススペック パターン マッチングに追加されます。gitattributes[5]を参照してください。\n\nパスの各属性要件は、これらのいずれかの形式をとる:
\n\n\n\n
\n- \n
\n\"
\nATTR\" は、属性ATTRを設定することを要求します。- \n
\n\"
\n-ATTR\" は、属性ATTRの設定を解除することを要求しています。- \n
\n\"
\nATTR=VALUE\" は、属性ATTRに文字列VALUEを設定することを要求しています。- \n
\n\"
\n!ATTR\" は、属性ATTRが指定されていないことを要求しています。\n\nツリーオブジェクトに対してマッチングを行う場合、属性は与えられたツリーオブジェクトからではなく、ワーキングツリーから取得されることに注意してください。
\n- exclude
\n- \n
\nパスが何らかの非除外パススペックにマッチした後、すべての除外パススペック (マジックシグネチャ:
\n!またはその同義語^) を通して実行されることになります。マッチした場合、そのパスは無視されます。非除外パススペックがない場合は、パススペックなしで起動された場合と同じように、結果セットに除外が適用されます。コミットオブジェクト は、開発ラインにおける論理的な先行者、すなわちその親の (空かもしれない) リストを含んでいます。
", "皮を剥く (peel)": "", - "つるはし (pickaxe)": "つるはし という用語は、与えられたテキスト文字列を追加または削除する変更を選択するのに役立つ diffcore ルーチンのオプションのことを指します。
", + "つるはし (pickaxe)": "--pickaxe-allオプションを使うと、例えば特定の行を追加したり削除したりした チェンジセット をすべて表示することができます。linkgit:git-diff[1] を参照してください。つるはし という用語は、与えられたテキスト文字列を追加または削除する変更を選択するのに役立つ diffcore ルーチンのオプションのことを指します。
", "配管 (plumbing)": "--pickaxe-allオプションを使うと、例えば特定の行を追加したり削除したりした チェンジセット をすべて表示することができます。git-diff[1] を参照してください。core Gitのかわいい名前です。
", "磁器 (porcelain)": "core Gitに依存するプログラムやプログラムスイートのかわいい名前で、core Gitへのハイレベルなアクセスを提示します。磁器は 配管 よりも多くの SCM インタフェースを公開します。
", "ワークツリーごとの参照 (per-worktree ref)": "グローバルではなく、ワークツリーごとの参照。現在は HEAD と
", - "疑似参照 (pseudoref)": "refs/bisect/で始まる参照のみですが、将来的には他の珍しい参照も含まれるかもしれません。通常の ref とは異なる意味を持つ ref です。これらの ref は通常の Git コマンドで読み取ることはできますが、linkgit:git-update-ref[1] のようなコマンドでは書き込むことができません。
\n\n\nThe following pseudorefs are known to Git:
\n\n", - "プル (pull)": "\n
\n- \n
\n\n
FETCH_HEADは linkgit:git-fetch[1] または linkgit:git-pull[1] によって書き込まれます。複数のオブジェクト ID を指す場合があります。それぞれのオブジェクト ID には、取得元やフェッチ状態を示すメタデータが付加されます。- \n
\n\n
MERGE_HEADis written by linkgit:git-merge[1] when resolving merge conflicts. It contains all commit IDs which are being merged.ブランチ をプルするということは、ブランチを フェッチ して マージ することを意味します。linkgit:git-pull[1] も参照してください。
", + "疑似参照 (pseudoref)": "通常の ref とは異なる意味を持つ ref です。これらの ref は通常の Git コマンドで読み取ることはできますが、git-update-ref[1] のようなコマンドでは書き込むことができません。
\n\n\nThe following pseudorefs are known to Git:
\n\n", + "プル (pull)": "\n
\n- \n
\n\n
FETCH_HEADは git-fetch[1] または git-pull[1] によって書き込まれます。複数のオブジェクト ID を指す場合があります。それぞれのオブジェクト ID には、取得元やフェッチ状態を示すメタデータが付加されます。- \n
\n\n
MERGE_HEADis written by git-merge[1] when resolving merge conflicts. It contains all commit IDs which are being merged.ブランチ をプルするということは、ブランチを フェッチ して マージ することを意味します。git-pull[1] も参照してください。
", "プッシュ (push)": "「ブランチをプッシュする」とは、ローカルのHEAD 参照の変更をリモートのリポジトリに反映させることを意味します。まず、対象のブランチについて、リモートの HEAD 参照を取得し、それがローカルの HEAD の祖先であるかを確認します。祖先であれば、ローカルの HEAD から到達可能なオブジェクトのうち、リモートに存在しないものをリモートのオブジェクトデータベースへ送信し、HEAD 参照を更新します。リモートのHEADがローカルの HEAD の祖先でない場合は、プッシュは失敗します。
", "到達可能 (reachable)": "特定のコミットのすべての祖先は、そのコミットから「到達可能」と言われます。より一般的には、一つのオブジェクトが別のオブジェクトから到達可能であるとは、我々がその他のオブジェクトから一つのオブジェクトにチェーンをたどって到達できる場合を指し、タグからタグ付けている何か、コミットからその親またはツリー、そしてツリーから内包するツリーやブロブをたどって到達することです。
", "到達可能性ビットマップ (reachability bitmaps)": "到達可能性ビットマップは、パックファイルやマルチパックインデックス（MIDX）における選択されたコミット群の到達可能性に関する情報を格納し、オブジェクト検索を速めるために使用されます。ビットマップは \".bitmap\" ファイルに格納されます。リポジトリは最大で一つのビットマップファイルを使用できます。ビットマップファイルは、単一のパックに属しているか、またはリポジトリのマルチパックインデックス（存在する場合）に属しているかのどちらかです。
", "リベース (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 linkgit:gitrevisions[7] for details. Refs are stored in the repository.
\n\n\nrefの名前空間は階層的です。refの名前は、
\nrefs/で始まるか、階層のルートに位置するかのどちらか一方でなければなりません。後者は、次のルールに従わなくてはなりません:\n", - "参照ログ(reflog)": "\n
\n- \n
\n名前は大文字かアンダースコアのみで構成される。
\n- \n
\n名前は \"
\n_HEAD\" で終わるか \"HEAD\" と一致する。\n\nrefの中には、これらのルールに一致しない階層のルートに属するものがあります。後述のリストは、網羅的で今後拡張されてはなりません。
\n- \n
\n\n
AUTO_MERGE- \n
\n\n
BISECT_EXPECTED_REV- \n
\n\n
NOTES_MERGE_PARTIAL- \n
\n\n
NOTES_MERGE_REF- \n
\n\n
MERGE_AUTOSTASH\n\nDifferent subhierarchies are used for different purposes. For example, the
\nrefs/heads/hierarchy is used to represent local branches whereas therefs/tags/hierarchy is used to represent local tags..参照ログは参照のローカル「履歴」を表示します。言い換えると、この リポジトリで3番目に最近のリビジョンが何であったか、また、この リポジトリで昨日の午後9時14分現在の状態が何であったかを教えてくれます。詳細は linkgit:git-reflog[1] を参照してください。
", - "参照スペック(refspec)": "「refspec（リファレンス指定）」は、fetch や push において、リモートの ref とローカルの ref の対応関係を表すために使用されます。詳細は linkgit:git-fetch[1] または linkgit:git-push[1] を参照してください。
", + "参照(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.
\n\n\nrefの名前空間は階層的です。refの名前は、
\nrefs/で始まるか、階層のルートに位置するかのどちらか一方でなければなりません。後者は、次のルールに従わなくてはなりません:\n", + "参照ログ(reflog)": "\n
\n- \n
\n名前は大文字かアンダースコアのみで構成される。
\n- \n
\n名前は \"
\n_HEAD\" で終わるか \"HEAD\" と一致する。\n\nrefの中には、これらのルールに一致しない階層のルートに属するものがあります。後述のリストは、網羅的で今後拡張されてはなりません。
\n- \n
\n\n
AUTO_MERGE- \n
\n\n
BISECT_EXPECTED_REV- \n
\n\n
NOTES_MERGE_PARTIAL- \n
\n\n
NOTES_MERGE_REF- \n
\n\n
MERGE_AUTOSTASH\n\nDifferent subhierarchies are used for different purposes. For example, the
\nrefs/heads/hierarchy is used to represent local branches whereas therefs/tags/hierarchy is used to represent local tags..参照ログは参照のローカル「履歴」を表示します。言い換えると、この リポジトリで3番目に最近のリビジョンが何であったか、また、この リポジトリで昨日の午後9時14分現在の状態が何であったかを教えてくれます。詳細は git-reflog[1] を参照してください。
", + "参照スペック(refspec)": "「refspec（リファレンス指定）」は、fetch や push において、リモートの ref とローカルの ref の対応関係を表すために使用されます。詳細は git-fetch[1] または git-push[1] を参照してください。
", "リモートリポジトリ (remote repository)": "同じプロジェクトを追跡するが別の場所に存在するリポジトリ。リモートと通信するには、フェッチまたはプッシュを参照してください。
", "リモートトラッキングブランチ (remote-tracking branch)": "他のリポジトリからの変更をたどるために使用される参照。通常は refs/remotes/foo/bar のような形をしており（これは、foo という名前のリモートの bar という名前のブランチを追跡していることを示します）、設定されたフェッチの参照スペックの右側に一致します。リモート追跡ブランチには直接の変更を加えたり、ローカルコミットを行ったりするべきではありません。
", "リポジトリ(repository)": "参照の集まりと、参照から到達可能なすべてのオブジェクトを含むオブジェクトデータベースで構成されたコレクションで、これには一つまたは複数の磁器からのメタデータが付随することもあります。リポジトリは代替の仕組みを通じて他のリポジトリとオブジェクトデータベースを共有することができます。
", @@ -73,15 +73,15 @@ "SCM": "ソースコードマネジメント(ツール).
", "SHA-1": "\"Secure Hash Algorithm 1\" 暗号学的ハッシュ関数です。Gitの文脈ではオブジェクト名の同義語として使用されます。
", "シャロークローン (shallow clone)": "主にシャローリポジトリの同義語ですが、この文言は
", - "シャローリポジトリ (shallow repository)": "gitclone--depth=...コマンドを実行して作成されたことをより明確に表しています。シャローリポジトリは、不完全な履歴を持ち、その中のいくつかのコミットは親が切り取られています（言い換えると、これらのコミットがコミットオブジェクトに記録されているにも関わらず、Gitはこれらのコミットが親を持たないかのように振る舞うよう指示されています）。これは、プロジェクトの最近の履歴にのみ興味がある場合に便利ですが、実際の履歴はアップストリームにもっと大きく記録されている場合があります。シャローリポジトリは、 linkgit:git-clone[1] に`--depth`オプションを与えることで作成され、後に linkgit:git-fetch[1] を使って履歴を深めることができます。
", + "シャローリポジトリ (shallow repository)": "シャローリポジトリは、不完全な履歴を持ち、その中のいくつかのコミットは親が切り取られています（言い換えると、これらのコミットがコミットオブジェクトに記録されているにも関わらず、Gitはこれらのコミットが親を持たないかのように振る舞うよう指示されています）。これは、プロジェクトの最近の履歴にのみ興味がある場合に便利ですが、実際の履歴はアップストリームにもっと大きく記録されている場合があります。シャローリポジトリは、 git-clone[1] に`--depth`オプションを与えることで作成され、後に git-fetch[1] を使って履歴を深めることができます。
", "スタッシュエントリー (stash entry)": "一時的にダーティな作業ディレクトリとインデックスの内容を将来的な再利用のために保存することに使用されるオブジェクトです。
", "サブモジュール (submodule)": "別のリポジトリ（親プロジェクトと呼ばれます）の中で分離されたプロジェクトの履歴を保持するリポジトリです。
", "親プロジェクト (superproject)": "作業ツリー内で他のプロジェクトのリポジトリを サブモジュール として参照する リポジトリ。親プロジェクトは内包するサブモジュールのコミットオブジェクトの名前を知っています(が、それらのコピーは保持しません) 。
", - "シンボリック参照 (symref)": "シンボリック参照: SHA-1 ID自体を含むのではなく ref: refs/some/thing’という形式をとり、参照されると再帰的に 逆参照 をします。HEAD'はシンボリック参照の主な例です。シンボリック参照は linkgit:git-symbolic-ref[1] コマンドで操作されます。
", + "シンボリック参照 (symref)": "シンボリック参照: SHA-1 ID自体を含むのではなく ref: refs/some/thing’という形式をとり、参照されると再帰的に 逆参照 をします。HEAD'はシンボリック参照の主な例です。シンボリック参照は git-symbolic-ref[1] コマンドで操作されます。
", "タグ (tag)": "`refs/tags/`名前空間の下にある 参照 で、任意のタイプのオブジェクトを指します（通常はタグがタグまたはコミットオブジェクトを指します）。ヘッドとは対照的に、タグは`commit`コマンドによって更新されません。GitのタグはLispのタグとは関係がありません（Gitの文脈ではオブジェクトタイプと呼ばれるでしょう）。タグは通常、コミットの祖先チェーンの特定のポイントをマークするために使用されます。
", "タグオブジェクト (tag object)": "他のオブジェクトを指す参照を含むオブジェクトで、コミットオブジェクトのようにメッセージを含むことができます。また、（PGPの）署名を含む場合は、「署名付きタグオブジェクト」と呼ばれます。
", "トピックブランチ(topic branch)": "開発者が開発の概念的な流れを識別するために使用する通常のGitブランチです。ブランチは非常に簡単かつ安価であるため、非常に明確に定義された概念のものや 小さく少しずつ進めた関連する変更を含むもの などの小さなブランチをいくつか持つことが望ましいです。
", - "トレーラー": "Key-value metadata. Trailers are optionally found at the end of a commit message. Might be called \"footers\" or \"tags\" in other communities. See linkgit:git-interpret-trailers[1].
", + "トレーラー": "Key-value metadata. Trailers are optionally found at the end of a commit message. Might be called \"footers\" or \"tags\" in other communities. See git-interpret-trailers[1].
", "ツリー (tree)": "ワーキングツリー または、 ツリーオブジェクト のどちらかと、それに従属する ブロブ およびツリーオブジェクト（つまりワーキングツリーの保存された表現）である。
", "ツリーオブジェクト (tree object)": "ファイル名とモードのリスト、および関連するブロブオブジェクトとツリーオブジェクトへの参照を含む オブジェクト 。ツリー は、 ディレクトリ と同じです。
", "ツリーの性質を持つもの (tree-ish (also treeish))": "ツリーオブジェクトを再帰的に 逆参照 できる ツリーオブジェクト または オブジェクト 。コミッオブジェクト の参照先を展開すると、 リビジョン の最上位 ディレクトリ に対応するツリーオブジェクトが生成されます。以下はすべてツリーの性質を持つものです: コミットの性質を持つもの、 ツリーオブジェクト、ツリーオブジェクトを指す タグオブジェクト 、ツリーオブジェクトを指すタグオブジェクトを指すタグオブジェクトなど。
", diff --git a/external/docs/data/glossary/ko.json b/external/docs/data/glossary/ko.json index 3fad3052a5..f127ae2521 100644 --- a/external/docs/data/glossary/ko.json +++ b/external/docs/data/glossary/ko.json @@ -23,13 +23,13 @@ "더티(dirty)": "현재 분기에 커밋되지 않은 수정 사항이 있는 경우, 이 작업 트리는 \"더티(dirty)\" 상태라고 합니다.
", "사악한 병합(evil merge)": "An evil merge is a merge that introduces changes that do not appear in any parent.
", "정방향 진행(fast-forward)": "정방향 진행(fast-forward)은 특정한 타입의 병합으로, 현재 가지고 있는 리비전과 동일한 조상을 가진 다른 분기의 변경사항을 \"병합\"하는 경우를 말합니다. 이 경우, 새로운 병합 커밋 을 만들지 않고 대신 분기를 병합하는 분기와 동일한 리비전을 가리키도록 업데이트합니다. 이러한 상황은 원격 저장소의 원격 추적 분기에서 자주 발생할 수 있습니다.
", - "페치(fetch)": "분기를 페치한다는 것은 원격 저장소에서 해당 분기의 헤드 참조를 가져오고, 로컬 객체 데이터베이스에서 누락된 객체를 찾아서 가져오는 것을 의미합니다. linkgit:git-fetch[1]를 참조하세요.
", + "페치(fetch)": "분기를 페치한다는 것은 원격 저장소에서 해당 분기의 헤드 참조를 가져오고, 로컬 객체 데이터베이스에서 누락된 객체를 찾아서 가져오는 것을 의미합니다. git-fetch[1]를 참조하세요.
", "파일 시스템(file system)": "리누스 토르발스는 처음 깃을 설계할 때 사용자 공간 파일 시스템으로 설계했습니다. 즉, 파일과 디렉토리를 보유하기 위한 인프라입니다. 이를 통해 깃의 효율성과 속도를 보장하고 있습니다.
", "깃 아카이브(Git archive)": "저장소의 동의어 (arch 사용자 대상).
", - "깃 파일(gitfile)": "실제 저장소인 디렉토리를 가리키는 작업 트리의 루트에 위치한 일반 파일
", - "이식(grafts)": ".git. 적절한 용도는 linkgit:git-worktree[1] 또는 linkgit:git-submodule[1]를 참조하세요. 문법은 linkgit:gitrepository-layout[5]를 참조하세요.이식(Grafts)은 커밋에 대한 가짜 조상 정보를 기록함으로써 서로 다른 두 개발 라인을 함께 연할 수 있게 해줍니다. 이렇게 하면 깃이 커밋의 부모 집합이 커밋이 생성될 때 기록된 것과 다른 것처럼 가장할 수 있습니다. `.git/info/grafts`파일을 통해 구성할 수 있습니다.
\n\n", + "깃 파일(gitfile)": "이식(grafts) 메커니즘은 오래되었고, 저장소 간 객체 전송에 문제를 일으킬 수 있습니다. 같은 작업을 수행하는 더 유연하고 견고한 시스템으로서 linkgit:git-replace[1]를 참조하세요.
\n실제 저장소인 디렉토리를 가리키는 작업 트리의 루트에 위치한 일반 파일
", + "이식(grafts)": ".git. 적절한 용도는 git-worktree[1] 또는 git-submodule[1]를 참조하세요. 문법은 gitrepository-layout[5]를 참조하세요.이식(Grafts)은 커밋에 대한 가짜 조상 정보를 기록함으로써 서로 다른 두 개발 라인을 함께 연할 수 있게 해줍니다. 이렇게 하면 깃이 커밋의 부모 집합이 커밋이 생성될 때 기록된 것과 다른 것처럼 가장할 수 있습니다. `.git/info/grafts`파일을 통해 구성할 수 있습니다.
\n\n", "해시(hash)": "이식(grafts) 메커니즘은 오래되었고, 저장소 간 객체 전송에 문제를 일으킬 수 있습니다. 같은 작업을 수행하는 더 유연하고 견고한 시스템으로서 git-replace[1]를 참조하세요.
\nGit의 문맥에서 객체명에 대한 동의어.
", - "헤드(head)": "분기의 끝에 있는 커밋을 가리키는 명명된 참조를 헤드라고 합니다. 헤드는 패킹된 참조를 사용하는 경우를 제외하면`$GIT_DIR/refs/heads/` 디렉토리에 있는 파일에 저장됩니다(linkgit:git-pack-refs[1]를 참조하세요).
", + "헤드(head)": "분기의 끝에 있는 커밋을 가리키는 명명된 참조를 헤드라고 합니다. 헤드는 패킹된 참조를 사용하는 경우를 제외하면`$GIT_DIR/refs/heads/` 디렉토리에 있는 파일에 저장됩니다(git-pack-refs[1]를 참조하세요).
", "HEAD": "현재의 분기입니다. 좀 더 자세히 설명하면, 작업 트리는 일반적으로 HEAD가 가리키는 트리의 상태에서 유도됩니다. HEAD는 저장소 내의 하나의 헤드를 가리키는 참조입니다. 다만, 분리된 HEAD를 사용하는 경우에는 임의의 커밋을 직접 참조합니다.
", "헤드 참조": "헤드와 동의어.
", "훅(hook)": "여러 깃 명령의 정상적인 실행 중에는 개발자가 기능 또는 확인을 추가할 수 있는 선택적인 스크립트를 호출합니다. 일반적으로 훅(hooks)은 명령이 사전에 확인되고 중단될 수 있도록 하며, 작업이 완료된 후에 후속 알림을 허용합니다. 훅 스크립트는`$GIT_DIR/hooks/`디렉토리에서 찾을 수 있으며, 파일명에서 `.sample`접미사를 제거함으로써 활성화됩니다. 초기 버전의 깃에서는 이것을 실행할 수 있도록 직접 만들어야 했었습니다.
", @@ -48,22 +48,22 @@ "오버레이(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)": "깃 명령어에서 경로를 제한하는 데 사용되는 패턴입니다.
\n\n\nPathspecs 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:
\n\n\n\n\n\n\n\n
\n- \n
\n어떤 경로든 자기 자신과 일치
\n- \n
\nthe pathspec up to the last slash represents a directory prefix. The scope of that pathspec is limited to that subtree.
\n- \n
\nthe 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.
\n\n\n예를 들어, Documentation/*.jpg는 Documentation 서브트리에 있는 모든 .jpg 파일과 일치합니다. 이는 Documentation/chapter_1/figure_1.jpg를 포함합니다.
\n\n\nA pathspec that begins with a colon
\n: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.\n\n긴 형식에서는 선행하는 콜론
\n:다음에 여는 괄호 (, 영문자로 이루어진 \"매직 워드\"의 쉼표로 구분된 리스트(0개 이상), 그리고 닫는 괄호 `)`가 옵니다. 그리고 나머지는 경로와 일치시킬 패턴입니다.\n\n단순히 콜론만 있는 경로명세는 \"경로명세가 없음\"을 의미합니다. 이 형식은 다른 경로명세와 결합해서 사용되어서는 안 됩니다.
\n\n", + "경로명세(pathspec)": "\n\n\n\n\n
\n- top
\n- \n
\n매직 워드인
\ntop(매직 시그니처:/)는 패턴이 작업 트리의 루트부터 일치하도록 만듭니다. 이는 현재 작업 중인 디렉토리 내에서 명령을 실행하더라도 적용됩니다.- literal
\n- \n
\n패턴 내의
\n*또는 `?`와 같은 와일드카드는 리터럴 문자로 처리됩니다.- icase
\n- \n
\n대소문자 구분 없이 매치.
\n- glob
\n- \n
\nGit 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\".
\n\n\n패턴 내에서 전체 경로명에 대해 일치하는 경우, 두 개의 연속된 별표(\"
\n**\")는 특별한 의미를 가질 수 있습니다:\n\n\n
\n- \n
\nA leading \"
\n**\" followed by a slash means match in all directories. For example, \"**/foo\" matches file or directory \"foo\" anywhere. \"**/foo/bar\" matches file or directory \"bar\" anywhere that is directly under directory \"foo\".- \n
\n말미의 \"
\n/**\"는 그 안에 있는 모든 파일과 매치됩니다. 예를 들어, \"abc/**\"는 디렉토리 \"abc\" 내의 모든 파일에 매치됩니다. 이는.gitignore파일의 위치를 기준으로 하며, 깊이는 무한입니다.- \n
\n말미 이외에서의 \"
\n/**\"는 0개 이상의 디렉토리에 매치됩니다. 예를 들어, \"a/**/b\"는 \"a/b\", \"a/x/b\", \"a/x/y/b\"와 같은 식으로 매치됩니다.- \n
\n이 이외의 연속된 별표는 무효로 취급됩니다.
\n\n\n글로브 매직과 리터럴 매직은 서로 호환되지 않습니다.
\n- attr
\n- \n
\nAfter
\nattr: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 linkgit:gitattributes[5].\n\n패스의 각 속성 요구사항은 다음 중 하나의 형식을 취합니다:
\n\n\n\n
\n- \n
\n\"
\nATTR\"은 속성 `ATTR`이 설정되어야 함을 요구합니다.- \n
\n\"
\n-ATTR\"은 속성 `ATTR`이 설정되지 않아야 함을 요구합니다.- \n
\n\"
\nATTR=VALUE\"는 속성 `ATTR`이 문자열 `VALUE`로 설정되어야 함을 요구합니다.- \n
\n\"
\n!ATTR\"은 속성 `ATTR`이 지정되지 않아야 함을 요구합니다.\n\n여기서 주의할 점은 트리 객체와 매치시킬 때 속성은 주어진 트리 객체에서 가져오는 것이 아니라, 작업 트리에서 가져온다는 것입니다.
\n- exclude
\n- \n
\nAfter a path matches any non-exclude pathspec, it will be run through all exclude pathspecs (magic signature:
\n!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.깃 명령어에서 경로를 제한하는 데 사용되는 패턴입니다.
\n\n\nPathspecs 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:
\n\n\n\n\n\n\n\n
\n- \n
\n어떤 경로든 자기 자신과 일치
\n- \n
\nthe pathspec up to the last slash represents a directory prefix. The scope of that pathspec is limited to that subtree.
\n- \n
\nthe 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.
\n\n\n예를 들어, Documentation/*.jpg는 Documentation 서브트리에 있는 모든 .jpg 파일과 일치합니다. 이는 Documentation/chapter_1/figure_1.jpg를 포함합니다.
\n\n\nA pathspec that begins with a colon
\n: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.\n\n긴 형식에서는 선행하는 콜론
\n:다음에 여는 괄호 (, 영문자로 이루어진 \"매직 워드\"의 쉼표로 구분된 리스트(0개 이상), 그리고 닫는 괄호 `)`가 옵니다. 그리고 나머지는 경로와 일치시킬 패턴입니다.\n\n단순히 콜론만 있는 경로명세는 \"경로명세가 없음\"을 의미합니다. 이 형식은 다른 경로명세와 결합해서 사용되어서는 안 됩니다.
\n\n", "부모(parent)": "\n\n\n\n\n
\n- top
\n- \n
\n매직 워드인
\ntop(매직 시그니처:/)는 패턴이 작업 트리의 루트부터 일치하도록 만듭니다. 이는 현재 작업 중인 디렉토리 내에서 명령을 실행하더라도 적용됩니다.- literal
\n- \n
\n패턴 내의
\n*또는 `?`와 같은 와일드카드는 리터럴 문자로 처리됩니다.- icase
\n- \n
\n대소문자 구분 없이 매치.
\n- glob
\n- \n
\nGit 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\".
\n\n\n패턴 내에서 전체 경로명에 대해 일치하는 경우, 두 개의 연속된 별표(\"
\n**\")는 특별한 의미를 가질 수 있습니다:\n\n\n
\n- \n
\nA leading \"
\n**\" followed by a slash means match in all directories. For example, \"**/foo\" matches file or directory \"foo\" anywhere. \"**/foo/bar\" matches file or directory \"bar\" anywhere that is directly under directory \"foo\".- \n
\n말미의 \"
\n/**\"는 그 안에 있는 모든 파일과 매치됩니다. 예를 들어, \"abc/**\"는 디렉토리 \"abc\" 내의 모든 파일에 매치됩니다. 이는.gitignore파일의 위치를 기준으로 하며, 깊이는 무한입니다.- \n
\n말미 이외에서의 \"
\n/**\"는 0개 이상의 디렉토리에 매치됩니다. 예를 들어, \"a/**/b\"는 \"a/b\", \"a/x/b\", \"a/x/y/b\"와 같은 식으로 매치됩니다.- \n
\n이 이외의 연속된 별표는 무효로 취급됩니다.
\n\n\n글로브 매직과 리터럴 매직은 서로 호환되지 않습니다.
\n- attr
\n- \n
\nAfter
\nattr: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].\n\n패스의 각 속성 요구사항은 다음 중 하나의 형식을 취합니다:
\n\n\n\n
\n- \n
\n\"
\nATTR\"은 속성 `ATTR`이 설정되어야 함을 요구합니다.- \n
\n\"
\n-ATTR\"은 속성 `ATTR`이 설정되지 않아야 함을 요구합니다.- \n
\n\"
\nATTR=VALUE\"는 속성 `ATTR`이 문자열 `VALUE`로 설정되어야 함을 요구합니다.- \n
\n\"
\n!ATTR\"은 속성 `ATTR`이 지정되지 않아야 함을 요구합니다.\n\n여기서 주의할 점은 트리 객체와 매치시킬 때 속성은 주어진 트리 객체에서 가져오는 것이 아니라, 작업 트리에서 가져온다는 것입니다.
\n- exclude
\n- \n
\nAfter a path matches any non-exclude pathspec, it will be run through all exclude pathspecs (magic signature:
\n!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.커밋 객체에는 개발 라인에서의 논리적 조상, 즉 그 부모(비어있을 수도 있음) 목록이 포함되어 있습니다.
", "peel": "", - "곡괭이(pickaxe)": "곡괭이라는 용어는 주어진 텍스트 문자열을 추가하거나 삭제하는 변경사항을 선택하는 데 도움이 되는 diffcore 루틴의 옵션을 가리킵니다. `--pickaxe-all`옵션을 사용하면 특정 텍스트 줄을 도입하거나 제거한 전체 변경 세트를 볼 수 있습니다. linkgit:git-diff[1]를 참조해 주세요.
", + "곡괭이(pickaxe)": "곡괭이라는 용어는 주어진 텍스트 문자열을 추가하거나 삭제하는 변경사항을 선택하는 데 도움이 되는 diffcore 루틴의 옵션을 가리킵니다. `--pickaxe-all`옵션을 사용하면 특정 텍스트 줄을 도입하거나 제거한 전체 변경 세트를 볼 수 있습니다. git-diff[1]를 참조해 주세요.
", "배관(plumbing)": "코어 깃의 애칭.
", "사용자 친화적 인터페이스": "코어 깃에 의존하는 프로그램이나 프로그램 콜렉션의 애칭으로, 코어 깃에 대한 고수준 액세스를 제공합니다. 사용자 친화적 인터페이스는 배관보다 더 많은 SCM 인터페이스를 노출합니다.
", "작업트리별 참조": "Refs that are per-worktree, rather than global. This is presently only HEAD and any refs that start with
", - "의사참조(pseudoref)": "refs/bisect/, but might later include other unusual refs.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 linkgit:git-update-ref[1].
\n\n\nThe following pseudorefs are known to Git:
\n\n", - "풀(pull)": "\n
\n- \n
\n\n
FETCH_HEADis written by linkgit:git-fetch[1] or linkgit: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.- \n
\n\n
MERGE_HEADis written by linkgit:git-merge[1] when resolving merge conflicts. It contains all commit IDs which are being merged.Pulling a branch means to fetch it and merge it. See also linkgit:git-pull[1].
", + "의사참조(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].
\n\n\nThe following pseudorefs are known to Git:
\n\n", + "풀(pull)": "\n
\n- \n
\n\n
FETCH_HEADis 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.- \n
\n\n
MERGE_HEADis written by git-merge[1] when resolving merge conflicts. It contains all commit IDs which are being merged.Pulling a branch means to fetch it and merge it. See also git-pull[1].
", "푸시(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 linkgit:gitrevisions[7] for details. Refs are stored in the repository.
\n\n\n참조 이름 공간은 계층적입니다. 참조 이름은 `refs/`로 시작되거나 계층의 루트에 위치해야 합니다. 후자의 경우 이름은 다음의 규칙을 준수해야 합니다.
\n\n", - "참조 로그(reflog)": "\n
\n- \n
\n이름은 대문자 또는 밑줄로만 구성됩니다.
\n- \n
\nThe name ends with \"
\n_HEAD\" or is equal to \"HEAD\".\n\n이 규칙과 일치하지 않는 계층의 루트에 일부 불규칙한 참조가 있습니다. 다음 목록은 철저하며 향후에도 확장되지 않습니다.
\n- \n
\n\n
AUTO_MERGE- \n
\n\n
BISECT_EXPECTED_REV- \n
\n\n
NOTES_MERGE_PARTIAL- \n
\n\n
NOTES_MERGE_REF- \n
\n\n
MERGE_AUTOSTASH\n\nDifferent subhierarchies are used for different purposes. For example, the
\nrefs/heads/hierarchy is used to represent local branches whereas therefs/tags/hierarchy is used to represent local tags..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 linkgit:git-reflog[1] for details.
", - "refspec": "\"refspec\"은 페치와 푸시 시 원격 참조와 로컬 참조 간의 맵핑을 설명하는 데 사용됩니다. 자세한 내용은 linkgit:git-fetch[1] 또는 linkgit:git-push[1]를 참조하세요.
", + "참조(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.
\n\n\n참조 이름 공간은 계층적입니다. 참조 이름은 `refs/`로 시작되거나 계층의 루트에 위치해야 합니다. 후자의 경우 이름은 다음의 규칙을 준수해야 합니다.
\n\n", + "참조 로그(reflog)": "\n
\n- \n
\n이름은 대문자 또는 밑줄로만 구성됩니다.
\n- \n
\nThe name ends with \"
\n_HEAD\" or is equal to \"HEAD\".\n\n이 규칙과 일치하지 않는 계층의 루트에 일부 불규칙한 참조가 있습니다. 다음 목록은 철저하며 향후에도 확장되지 않습니다.
\n- \n
\n\n
AUTO_MERGE- \n
\n\n
BISECT_EXPECTED_REV- \n
\n\n
NOTES_MERGE_PARTIAL- \n
\n\n
NOTES_MERGE_REF- \n
\n\n
MERGE_AUTOSTASH\n\nDifferent subhierarchies are used for different purposes. For example, the
\nrefs/heads/hierarchy is used to represent local branches whereas therefs/tags/hierarchy is used to represent local tags..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": "\"refspec\"은 페치와 푸시 시 원격 참조와 로컬 참조 간의 맵핑을 설명하는 데 사용됩니다. 자세한 내용은 git-fetch[1] 또는 git-push[1]를 참조하세요.
", "원격 저장소(remote repository)": "동일한 프로젝트를 추적하는 데 사용되지만 다른 위치에 있는 저장소입니다. 원격 저장소와 통신하기 위해서는 페치(fetch) 또는 푸시(push)를 참조해 주십시오.
", "원격 추적 분기(remote-tracking branch)": "다른 저장소의 변경사항을 추적하는 데 사용되는 참조입니다. 일반적으로 refs/remotes/foo/bar’와 같은 형식을 가지며('foo’라는 이름의 원격 저장소의 'bar 분기를 추적한다는 것을 나타냄) 설정된 페치 refspec의 오른쪽 부분과 일치합니다. 원격 추적 분기에는 직접적인 수정사항이 포함되어 있거나 해당 분기에 로컬 커밋이 적용되어서는 안 됩니다.
", "저장소(repository)": "참조와 참조의 도달 가능한 모든 객체를 포함하는 객체 데이터베이스로 구성된 콜렉션이며, 하나 이상의 사용자 친화적 인터페이스의 메타 데이터와 함께 제공될 수도 있습니다. 저장소는 대체 매커니즘을 통해 다른 저장소와 객체 데이터베이스를 공유할 수 있습니다.
", @@ -73,15 +73,15 @@ "SCM": "소스 코드 관리(도구).
", "SHA-1": "“보안 해시 알고리즘 1”; 암호화 해시 함수. Git의 맥락에서 객체명의 동의어로 사용됩니다.
", "얕은 복사": "대부분 얕은 저장소와 동의어지만, 이 문구를 사용하면 git clone --depth=… 명령을 실행하여 생성되었음을 더 명확히 알 수 있습니다.
", - "얕은 저장소": "얕은 저장소에는 몇몇 커밋의 삭제된 불완전한 기록이 있습니다. (즉, Git은 커밋들이 커밋 객체에 기록되었더라도 부모들을 가지지 않는 것처럼 가장하라고 지시 받습니다.) 이것은 때때로 업스트림에 기록된 실제 기록이 훨씬 더 크더라도 프로젝트의 최신 기록에만 관심이 있을 때 유용합니다. 앝은 저장소는 linkgit:git-clone[1]의
", + "얕은 저장소": "--depth옵션을 제공하여 만들어지게 되고 기록은 이후에 linkgit:git-fetch[1]을 사용하여 심화할 수 있습니다.얕은 저장소에는 몇몇 커밋의 삭제된 불완전한 기록이 있습니다. (즉, Git은 커밋들이 커밋 객체에 기록되었더라도 부모들을 가지지 않는 것처럼 가장하라고 지시 받습니다.) 이것은 때때로 업스트림에 기록된 실제 기록이 훨씬 더 크더라도 프로젝트의 최신 기록에만 관심이 있을 때 유용합니다. 앝은 저장소는 git-clone[1]의
", "숨김 항목": "--depth옵션을 제공하여 만들어지게 되고 기록은 이후에 git-fetch[1]을 사용하여 심화할 수 있습니다.object는 더티 작업 디렉토리의 내용과 향후 재사용을 위한 인덱스를 임시로 저장하는 데 사용됩니다.
", "서브 모듈": "다른 저장소 내의 별도의 프로젝트 기록을 보관하는 저장소입니다. (후자는 슈퍼프로젝트라고 불립니다.)
", "슈퍼프로젝트": "작업 트리에 있는 다른 프로젝트의 저장소들을 서브 모듈로 참조하는 저장소입니다. 슈퍼 프로젝트는 포함된 서브 모듈들의 커밋 객체들의 이름(사본은 보관하지 않습니다.)에 대해 알고 있습니다.
", - "기호 참조": "기호 참조: SHA-1 ID 자체를 포함하는 대신’ref: refs/some/thing' 형식으로 포함하고 참조될 때, 재귀적으로 역참조합니다. '<<def_HEAD,HEAD'는 기호 참조의 대표적인 예입니다. 기호참조는 linkgit:git-symbolic-ref[1] 명령으로 조작되어 집니다.
", + "기호 참조": "기호 참조: SHA-1 ID 자체를 포함하는 대신’ref: refs/some/thing' 형식으로 포함하고 참조될 때, 재귀적으로 역참조합니다. '<<def_HEAD,HEAD'는 기호 참조의 대표적인 예입니다. 기호참조는 git-symbolic-ref[1] 명령으로 조작되어 집니다.
", "태그": "임의의 타입의 객체(일반적으로 태그는 태그 또는 커밋 객체를 가리킵니다.)를 가리키는 네임스페이스 refs/tags/ 아래의 ' 참조입니다. 헤드와는 대조적으로 태그는 commit 명령어로 업데이트되지 않습니다. Git 태그는 Lisp 태그(Git에서는 객체 타입으로 불립니다)와 아무 관련 없습니다. 태그는 커밋 조상 체인의 특정 지점을 표시하는 데 가장 일반적으로 사용됩니다.
", "태그 객체": "커밋 객체와 마찬가지로 메세지를 포함할 수 있는 다른 객체를 가리키는 참조를 포함하는 객체입니다. 또한 PGP 서명을 포함할 수 있으며, 이 경우 \"서명된 태그 객체\"라고 합니다.
", "주제 분기": "개발자가 개념적인 개발 라인을 식별하기 위해 사용하는 일반적인 Git 분기. 분기는 매우 쉽고 비용이 저렴하기 때문에, 각각 매우 잘 정의된 개념이나 점진적이지만 관련된 변경사항을 포함하는 여러 작은 분기를 갖는 것이 종종 바람직합니다.
", - "trailer": "키-값 메타데이터. 트레일러는 커밋 메시지의 끝에서 선택적으로 발견됩니다. 다른 커뮤니티에서는 \"footers\"또는 \"tags\"라고도 합니다. linkgit:git-interpret-trailers[1]를 참조하세요.
", + "trailer": "키-값 메타데이터. 트레일러는 커밋 메시지의 끝에서 선택적으로 발견됩니다. 다른 커뮤니티에서는 \"footers\"또는 \"tags\"라고도 합니다. git-interpret-trailers[1]를 참조하세요.
", "트리": "하나의 작업 트리 또는 종속된 블롭 및 트리 객체와 함께하는 트리 객체 (즉, 작업 트리의 저장된 표현).
", "트리 객체": "파일 이름과 모드의 목록과 함께 관련된 블롭 및/또는 트리 객체에 대한 참조를 포함하는 객체. 트리는 디렉토리와 동일합니다.
", "유사 트리": "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.
", diff --git a/external/docs/data/glossary/pt_BR.json b/external/docs/data/glossary/pt_BR.json index bef6ae1cc4..95d6e6c018 100644 --- a/external/docs/data/glossary/pt_BR.json +++ b/external/docs/data/glossary/pt_BR.json @@ -23,13 +23,13 @@ "dirty (sujo)": "Se diz que uma árvore de trabalho está \"suja\" caso contenha alterações que não foram feito os commits no ramo atual.
", "evil merge (mesclagem má, mau, ruim)": "Uma mesclagem má é uma mesclagem que introduz as alterações que não aparecem em nenhuma origem.
", "fast-forward (avanço-rápido)": "Um avanço rápido é um tipo especial de mesclagem, onde você tem uma revisão e está \"mesclando\" outras alterações do ramo que são descendentes do que você tem. Nesse caso, você não faz um merge commit, mas em vez disso, atualiza apenas o seu ramo para que aponte para a mesma revisão do ramo que você está fazendo a mesclagem. Isso acontecerá frequentemente em um ramo monitorado remotamente de um repositório remoto.
", - "fetch (busca)": "Busque um ramo significa obter o cabeçalho ref de um ramo remoto repositório, para descobrir quais os objetos estão faltando no local banco de dados do objeto e para obtê-los também. Consulte também linkgit:git-fetch[1].
", + "fetch (busca)": "Busque um ramo significa obter o cabeçalho ref de um ramo remoto repositório, para descobrir quais os objetos estão faltando no local banco de dados do objeto e para obtê-los também. Consulte também git-fetch[1].
", "file system (sistema de arquivo)": "O Linus Torvalds originalmente projetou o Git para ser um sistema de arquivos no espaço do usuário, ou seja, a infraestrutura para armazenar os arquivos e os diretórios. Isso garantiu a eficiência e a velocidade do Git.
", "Git archive (arquivo Git)": "É um sinônimo para repositório (para o pessoal do arch).
", - "gitfile": "Um arquivo simples
", - "grafts (grafos)": ".gitna raiz de uma árvore em funcionamento que aponte para o diretório que seja o repositório real. Consulte linkgit:git-worktree[1] para saber mais ou linkgit:git-submodule[1]. Para conhecer a sintaxe, consulte linkgit:gitrepository-layout[5].O Grafts permite que duas linhas de desenvolvimento diferentes sejam unidas, registrando informações falsas de ancestralidade para os commits. Dessa forma, é possível fazer o Git fingir que o conjunto de parents um commit tenha é diferente do que foi registrado quando o commit foi criado. Configurado através do arquivo
\n.git/info/grafts.\n", + "gitfile": "Observe que o mecanismo de enxertos está desatualizado e pode levar a problemas na transferência dos objetos entre os repositórios; para fazer a mesma coisa consulte linkgit:git-replace[1] para um sistema mais flexível e robusto.
\nUm arquivo simples
", + "grafts (grafos)": ".gitna raiz de uma árvore em funcionamento que aponte para o diretório que seja o repositório real. Consulte git-worktree[1] para saber mais ou git-submodule[1]. Para conhecer a sintaxe, consulte gitrepository-layout[5].O Grafts permite que duas linhas de desenvolvimento diferentes sejam unidas, registrando informações falsas de ancestralidade para os commits. Dessa forma, é possível fazer o Git fingir que o conjunto de parents um commit tenha é diferente do que foi registrado quando o commit foi criado. Configurado através do arquivo
\n.git/info/grafts.\n", "hash": "Observe que o mecanismo de enxertos está desatualizado e pode levar a problemas na transferência dos objetos entre os repositórios; para fazer a mesma coisa consulte git-replace[1] para um sistema mais flexível e robusto.
\nEm termos do Git, é um sinônimo para nome do objeto.
", - "head (cabeçalho, cabeça)": "Um named reference para o commit no topo do ramo. Os
", + "head (cabeçalho, cabeça)": "HEADSsão armazenados em um arquivo no diretório$GIT_DIR/refs/heads/, exceto quando é utilizado umrefempacotado. (Consulte linkgit:git-pack-refs[1].)Um named reference para o commit no topo do ramo. Os
", "HEAD (CABEÇALHO, CABEÇA)": "HEADSsão armazenados em um arquivo no diretório$GIT_DIR/refs/heads/, exceto quando é utilizado umrefempacotado. (Consulte git-pack-refs[1].)O ramo atual. Com mais detalhes: A sua árvore de trabalho normalmente deriva da condição da referência da árvore através do
", "head ref (referência do cabeçalho)": "HEAD. OHEADé a referência para um dos cabeçalhos no seu repositório, exceto quando utilizar um HEAD desanexado, neste caso, referencia diretamente um commit arbitrário.É um sinônimo para cabeçalho.
", "hook (gancho)": "Durante a execução normal dos vários comandos Git, são feitas chamadas para os scripts opcionais que permitem que um desenvolvedor adicione mais funcionalidades ou verificações. Normalmente, os ganchos permitem que um comando seja pré-verificado e potencialmente abortado e permite uma notificação após a conclusão da operação. Os scripts do gancho são encontrados no diretório
", @@ -48,22 +48,22 @@ "overlay (cobrir, revestir, sobrepor, capa, camada)": "$GIT_DIR/hooks/e são ativados simplesmente ao remover o sufixo.sampledo nome do arquivo. Nas versões anteriores do Git, era necessário torná-los executáveis.Atualize e adicione apenas os arquivos ao diretório de trabalho porém não os exclua, semelhante a como o comando cp -R atualizaria o conteúdo no diretório de destino. Este é o modo predefinido em checkout ao fazer averiguação dos arquivos vindo do índice ou tree-ish. Por outro lado, o modo sem sobreposição também exclui os arquivos monitorados que não estão presentes na fonte, semelhante ao comando rsync --delete.
", "pack (pacote)": "Um conjunto de objetos que foram compactados em um arquivo (para economizar espaço ou transmiti-los com eficiência).
", "pack index (índice do pacote)": "A lista de identificadores e das outras informações dos objetos em um pacote, para ajudar no acesso eficiente ao conteúdo de um pacote.
", - "pathspec (a especificação do caminho)": "O padrão utilizado para limitar os caminhos nos comandos do Git.
\n\n\nOs pathspecs são utilizados na linha de comando, os comando \"git ls-files\", \"git ls-tree\", \"git add\", \"git grep\", \"git diff\", \"git checkout\" e muitos outros para limitar o escopo das operações para algum subconjunto da árvore ou da árvore de trabalho. Consulte a documentação de cada comando para saber se os caminhos são relativos ao diretório atual ou ao nível mais alto. A sintaxe do pathspec é a seguinte:
\n\n\n\n\n\n\n\n
\n- \n
\nqualquer caminho corresponde a si próprio
\n- \n
\no pathspec até a última barra representa um prefixo do diretório. O escopo deste pathspec é limitado a esta subárvore.
\n- \n
\no restante do pathspec é um padrão para o restante do nome do caminho. Os caminhos relativos ao prefixo do diretório serão comparados com este padrão usando fnmatch(3); * e ? em particular podem ser comparados com os separadores dos diretórios.
\n\n\nComo por exemplo, Documentação/*.jpg irá coincidir com todos os arquivos .jpg na subárvore Documentação, incluindo Documentação/capítulo_1/figura_1.jpg.
\n\n\nUm pathspec que começa com dois pontos
\n:tem um significado especial. Na forma abreviada, os dois pontos iniciais:são seguidos por zero ou mais letras da \"assinatura mágica\" (que opcionalmente são terminadas por outros dois pontos:), o restante é o padrão que será comparado ao caminho. A \"assinatura mágica\" consiste em símbolos ASCII que não são caracteres alfanuméricos, glob, regex nem caracteres especiais. Os dois pontos opcionais que encerram a \"assinatura mágica\" podem ser omitidos caso o padrão comece com um caractere que não pertença ao conjunto dos símbolos da \"assinatura mágica\" e não seja dois pontos.\n\nNa forma longa, os dois pontos iniciais
\n:são seguidos por um parêntese aberto (, uma lista separada por vírgula de zeros ou mais \"palavras mágicas\" e parênteses próximos ), o restante é o padrão para coincidir contra o caminho.\n\nUm pathspec com apenas dois pontos significa \"não há um pathspec\". Este formulário não deve ser combinado com um outro pathspec.
\n\n", + "pathspec (a especificação do caminho)": "\n\n\n\n\n
\n- top
\n- \n
\nA palavra mágica
\ntop(assinatura mágica:/) faz o padrão da raiz da árvore de trabalho coincidir mesmo quando você está executando o comando de dentro de um subdiretório.- literal
\n- \n
\nCuringas no padrão como
\n*ou ? são tratados como caracteres literais.- icase
\n- \n
\nCoincidência indiferente a letras maiúsculas ou minúsculas.
\n- glob
\n- \n
\nO Git trata o padrão como um \"shell glob\" adequado para o consumo do
\nfnmatch(3) com a sinalizaçãoFNM_PATHNAME: curingas no padrão não corresponderão com opathname. Por exemplo, \"Documentation/*.html\" coincide com \"Documentation/git.html\", mas não com \"Documentation/ppc/ppc.html\" ou \"tools/perf/Documentation/perf.html\".\n\nDois asteriscos consecutivos (\"
\n**\") nos padrões coincidentes aopathnamecompleto podem ter um significado especial:\n\n\n
\n- \n
\nA leading \"
\n**\" followed by a slash means match in all directories. For example, \"**/foo\" matches file or directory \"foo\" anywhere. \"**/foo/bar\" matches file or directory \"bar\" anywhere that is directly under directory \"foo\".- \n
\nUm \"
\n/**\" à direita corresponde a tudo que estiver dentro. Por exemplo, \"abc/**\" coincide todos os arquivos dentro do diretório \"abc\", relativos à localização do arquivo.gitignore, com uma profundidade infinita.- \n
\nUma barra seguida por dois asteriscos consecutivos e uma barra coincide com zero ou mais diretórios. Por exemplo, \"
\na/**/b\" coincide com \"a/b\", \"a/x/b\", \"a/x/y/b\" e assim por diante.- \n
\nOs outros asteriscos consecutivos são considerados inválidos.
\n\n\nA magica \"glob\" é incompatível com a mágica literal.
\n- attr
\n- \n
\nApós o
\nattr:, vem um espaço separado da lista do \"attribute requirements\" (requisitos dos atributos), todos os quais devem ser atendidos para que o caminho seja considerado uma correspondência; isso é um acréscimo à coincidência usual dos padrões dopathspec. Consulte linkgit:gitattributes[5].\n\nCada um dos requisitos de atributo para o caminho assume uma destas formas:
\n\n\n\n
\n- \n
\n\"
\nATTR\" requer que o atributoATTRseja definido.- \n
\n\"
\nATTR\" requer que o atributoATTRnão seja definido.- \n
\n\"
\nATTR=VALUE\" requer que o atributoATTRseja definido como a stringVALUE.- \n
\n\"
\n!ATTR\"requer que o atributo` ATTR` não seja especificado.\n\nObserve que durante a coincidência com um objeto da árvore, os atributos ainda serão obtidos da mesma e não do objeto da árvore especificado.
\n- exclude (excluí)
\n- \n
\nDepois que um caminho coincida com qualquer
\npathspecque não foi excluído ele será executado em todos ospathspecsque foram excluídos (assinatura mágica:!or its synonym^). Caso coincida, o caminho é ignorado. Quando não há umpathspecnão excluído a exclusão é aplicada ao conjunto de resultados como se fosse invocada sem nenhumpathspec.O padrão utilizado para limitar os caminhos nos comandos do Git.
\n\n\nOs pathspecs são utilizados na linha de comando, os comando \"git ls-files\", \"git ls-tree\", \"git add\", \"git grep\", \"git diff\", \"git checkout\" e muitos outros para limitar o escopo das operações para algum subconjunto da árvore ou da árvore de trabalho. Consulte a documentação de cada comando para saber se os caminhos são relativos ao diretório atual ou ao nível mais alto. A sintaxe do pathspec é a seguinte:
\n\n\n\n\n\n\n\n
\n- \n
\nqualquer caminho corresponde a si próprio
\n- \n
\no pathspec até a última barra representa um prefixo do diretório. O escopo deste pathspec é limitado a esta subárvore.
\n- \n
\no restante do pathspec é um padrão para o restante do nome do caminho. Os caminhos relativos ao prefixo do diretório serão comparados com este padrão usando fnmatch(3); * e ? em particular podem ser comparados com os separadores dos diretórios.
\n\n\nComo por exemplo, Documentação/*.jpg irá coincidir com todos os arquivos .jpg na subárvore Documentação, incluindo Documentação/capítulo_1/figura_1.jpg.
\n\n\nUm pathspec que começa com dois pontos
\n:tem um significado especial. Na forma abreviada, os dois pontos iniciais:são seguidos por zero ou mais letras da \"assinatura mágica\" (que opcionalmente são terminadas por outros dois pontos:), o restante é o padrão que será comparado ao caminho. A \"assinatura mágica\" consiste em símbolos ASCII que não são caracteres alfanuméricos, glob, regex nem caracteres especiais. Os dois pontos opcionais que encerram a \"assinatura mágica\" podem ser omitidos caso o padrão comece com um caractere que não pertença ao conjunto dos símbolos da \"assinatura mágica\" e não seja dois pontos.\n\nNa forma longa, os dois pontos iniciais
\n:são seguidos por um parêntese aberto (, uma lista separada por vírgula de zeros ou mais \"palavras mágicas\" e parênteses próximos ), o restante é o padrão para coincidir contra o caminho.\n\nUm pathspec com apenas dois pontos significa \"não há um pathspec\". Este formulário não deve ser combinado com um outro pathspec.
\n\n", "parent (pai, origem, matriz)": "\n\n\n\n\n
\n- top
\n- \n
\nA palavra mágica
\ntop(assinatura mágica:/) faz o padrão da raiz da árvore de trabalho coincidir mesmo quando você está executando o comando de dentro de um subdiretório.- literal
\n- \n
\nCuringas no padrão como
\n*ou ? são tratados como caracteres literais.- icase
\n- \n
\nCoincidência indiferente a letras maiúsculas ou minúsculas.
\n- glob
\n- \n
\nO Git trata o padrão como um \"shell glob\" adequado para o consumo do
\nfnmatch(3) com a sinalizaçãoFNM_PATHNAME: curingas no padrão não corresponderão com opathname. Por exemplo, \"Documentation/*.html\" coincide com \"Documentation/git.html\", mas não com \"Documentation/ppc/ppc.html\" ou \"tools/perf/Documentation/perf.html\".\n\nDois asteriscos consecutivos (\"
\n**\") nos padrões coincidentes aopathnamecompleto podem ter um significado especial:\n\n\n
\n- \n
\nA leading \"
\n**\" followed by a slash means match in all directories. For example, \"**/foo\" matches file or directory \"foo\" anywhere. \"**/foo/bar\" matches file or directory \"bar\" anywhere that is directly under directory \"foo\".- \n
\nUm \"
\n/**\" à direita corresponde a tudo que estiver dentro. Por exemplo, \"abc/**\" coincide todos os arquivos dentro do diretório \"abc\", relativos à localização do arquivo.gitignore, com uma profundidade infinita.- \n
\nUma barra seguida por dois asteriscos consecutivos e uma barra coincide com zero ou mais diretórios. Por exemplo, \"
\na/**/b\" coincide com \"a/b\", \"a/x/b\", \"a/x/y/b\" e assim por diante.- \n
\nOs outros asteriscos consecutivos são considerados inválidos.
\n\n\nA magica \"glob\" é incompatível com a mágica literal.
\n- attr
\n- \n
\nApós o
\nattr:, vem um espaço separado da lista do \"attribute requirements\" (requisitos dos atributos), todos os quais devem ser atendidos para que o caminho seja considerado uma correspondência; isso é um acréscimo à coincidência usual dos padrões dopathspec. Consulte gitattributes[5].\n\nCada um dos requisitos de atributo para o caminho assume uma destas formas:
\n\n\n\n
\n- \n
\n\"
\nATTR\" requer que o atributoATTRseja definido.- \n
\n\"
\nATTR\" requer que o atributoATTRnão seja definido.- \n
\n\"
\nATTR=VALUE\" requer que o atributoATTRseja definido como a stringVALUE.- \n
\n\"
\n!ATTR\"requer que o atributo` ATTR` não seja especificado.\n\nObserve que durante a coincidência com um objeto da árvore, os atributos ainda serão obtidos da mesma e não do objeto da árvore especificado.
\n- exclude (excluí)
\n- \n
\nDepois que um caminho coincida com qualquer
\npathspecque não foi excluído ele será executado em todos ospathspecsque foram excluídos (assinatura mágica:!or its synonym^). Caso coincida, o caminho é ignorado. Quando não há umpathspecnão excluído a exclusão é aplicada ao conjunto de resultados como se fosse invocada sem nenhumpathspec.Um objeto commit contém uma lista (possivelmente vazia) dos predecessores lógicos na linha de desenvolvimento, ou seja, as suas origens.
", "peel": "A ação de recursividade perder a referência a objeto tag.
", - "pickaxe": "O termo pickaxe refere-se a uma opção para as rotinas
", + "pickaxe": "diffcoreque ajudam a selecionar as alterações que adicionam ou excluem uma determinada string. Com a opção--pickaxe-all, ela pode ser utilizada para visualizar completamente o changeset que introduziu ou removeu, digamos, uma determinada linha de texto. Consulte linkgit:git-diff[1].O termo pickaxe refere-se a uma opção para as rotinas
", "plumbing (encanamento)": "diffcoreque ajudam a selecionar as alterações que adicionam ou excluem uma determinada string. Com a opção--pickaxe-all, ela pode ser utilizada para visualizar completamente o changeset que introduziu ou removeu, digamos, uma determinada linha de texto. Consulte git-diff[1].Um nome bonito para núcleo do Git.
", "porcelain (porcelana)": "Nome bonito para programas e conjunto de programas, dependendo do núcleo do Git, apresentando um acesso de alto nível ao núcleo do Git principal. As porcelanas expõem mais uma interface SCM do que o plumbing.
", "per-worktree ref (referência por árvore de trabalho)": "As refs que são por-worktree em vez de global. Atualmente isto é apresentado apenas como HEAD e qualquer outra
", - "pseudoref (pseudo referência)": "refsque inicie comrefs/bisect/, mas podem posteriormente, incluir outrasrefsincomuns.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 linkgit:git-update-ref[1].
\n\n\nThe following pseudorefs are known to Git:
\n\n", - "pull (captura, puxar, atrair, apertar)": "\n
\n- \n
\n\n
FETCH_HEADis written by linkgit:git-fetch[1] or linkgit: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.- \n
\n\n
MERGE_HEADis written by linkgit:git-merge[1] when resolving merge conflicts. It contains all commit IDs which are being merged.Captura um ramo significa fetch (obter) e merge (mesclar). Consulte também linkgit:git-pull[1].
", + "pseudoref (pseudo referência)": "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].
\n\n\nThe following pseudorefs are known to Git:
\n\n", + "pull (captura, puxar, atrair, apertar)": "\n
\n- \n
\n\n
FETCH_HEADis 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.- \n
\n\n
MERGE_HEADis written by git-merge[1] when resolving merge conflicts. It contains all commit IDs which are being merged.Captura um ramo significa fetch (obter) e merge (mesclar). Consulte também git-pull[1].
", "push (impulsionar, impulso, empurrar, apertar, pressionar, forçar, investida)": "Fazer um impulsionamento ao ramo significa pegar a ref do cabeçalho do ramo de um repositório remoto, descobrir se é um ancestral da ref (referência) do cabeçalho local e nesse caso, colocar todos os objetos que são acessíveis com base na ref do cabeçalho local e que estão faltando a partir do repositório remoto, para o banco de dados do objeto que atualiza a ref do cabeçalho remoto. Caso o cabeçalho não seja um ancestral do cabeçalho local, o impulsionamento (push) vai falhar.
", "reachable (acessível ou alcançável)": "Todos os ancestrais de um determinado commit são considerados \"reachable\" (ou acessíveis) a partir deste commit. De um modo mais geral, um objeto é acessível a partir do outro se pudermos alcançá-lo através de um chain seguido de tags para o que quer que eles marque com uma tag, commits para as suas origens ou árvores, e as árvores para as árvores ou as bolhas que os contém.
", "bitmaps de alcançabilidade": "Os bitmaps de acessibilidade armazenam informações sobre a acessibilidade de um conjunto de commits selecionados num arquivo de pacotes, ou num índice de multi-pack (MIDX), para acelerar a pesquisa dos objetos. Os bitmaps são armazenados num arquivo \".bitmap\". Um repositório pode ter, no máximo, um arquivo bitmap em uso. O arquivo bitmap pode pertencer a um pacote ou ao índice multi-pack do repositório (caso exista).
", "rebase (reconstrução da fundação ou reconstrução)": "Para reaplicar uma série de alterações de uma ramo para uma base diferente e redefinir o head dessa ramificação para o resultado.
", - "ref (referência)": "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 linkgit:gitrevisions[7] for details. Refs are stored in the repository.
\n\n\nThe ref namespace is hierarchical. Ref names must either start with
\nrefs/or be located in the root of the hierarchy. For the latter, their name must follow these rules:\n", - "reflog": "\n
\n- \n
\nThe name consists of only upper-case characters or underscores.
\n- \n
\nThe name ends with \"
\n_HEAD\" or is equal to \"HEAD\".\n\nThere 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:
\n- \n
\n\n
AUTO_MERGE- \n
\n\n
BISECT_EXPECTED_REV- \n
\n\n
NOTES_MERGE_PARTIAL- \n
\n\n
NOTES_MERGE_REF- \n
\n\n
MERGE_AUTOSTASH\n\nDifferent subhierarchies are used for different purposes. For example, the
\nrefs/heads/hierarchy is used to represent local branches whereas therefs/tags/hierarchy is used to represent local tags..Um
", - "refspec": "reflogexibe o \"histórico\" local de umaref. Em outras palavras, ele pode informar qual foi a 3ª última revisão neste repositório e qual era a sua condição atual, ontem às 21:14. Para mais detalhes consulte o comando linkgit:git-reflog[1].A \"refspec\" is used by fetch and push to describe the mapping between remote ref and local ref. See linkgit:git-fetch[1] or linkgit:git-push[1] for details.
", + "ref (referência)": "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.
\n\n\nThe ref namespace is hierarchical. Ref names must either start with
\nrefs/or be located in the root of the hierarchy. For the latter, their name must follow these rules:\n", + "reflog": "\n
\n- \n
\nThe name consists of only upper-case characters or underscores.
\n- \n
\nThe name ends with \"
\n_HEAD\" or is equal to \"HEAD\".\n\nThere 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:
\n- \n
\n\n
AUTO_MERGE- \n
\n\n
BISECT_EXPECTED_REV- \n
\n\n
NOTES_MERGE_PARTIAL- \n
\n\n
NOTES_MERGE_REF- \n
\n\n
MERGE_AUTOSTASH\n\nDifferent subhierarchies are used for different purposes. For example, the
\nrefs/heads/hierarchy is used to represent local branches whereas therefs/tags/hierarchy is used to represent local tags..Um
", + "refspec": "reflogexibe o \"histórico\" local de umaref. Em outras palavras, ele pode informar qual foi a 3ª última revisão neste repositório e qual era a sua condição atual, ontem às 21:14. Para mais detalhes consulte o comando git-reflog[1].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 (repositório remoto)": "Um repositório que é utilizado para rastrear os mesmo projeto porém reside em um outro lugar. Para se comunicar com ramos remotos, consulte fetch ou push.
", "remote-tracking branch (monitorando os ramos remotamente)": "Um ref que é utilizado para rastrear as modificações de outro repositório. Normalmente se parece com refs/remotes/foo/bar (indicando que rastreia um ramo com nome bar e um remoto chamado foo), coincide o lado direito do
", "repository (repositório)": "fetchconfigurado refspec. Um ramo monitorado remotamente não deve conter alterações diretas, tão pouco, ter commits locais.Uma coleção de refs junto com um banco de dados do objeto contendo todos os objetos que são acessível vindas das
", @@ -73,15 +73,15 @@ "SCM": "refs, possivelmente acompanhados por metadados de um ou mais porcelanas. Um repositório pode compartilhar um banco de dados de objetos com outros repositórios através de mecanismo alternativo.Gerenciamento do código fonte (ferramenta).
", "SHA-1": "\"Secure Hash Algorithm 1\"; uma função hash de criptográfica. No contexto do Git utilizado como sinônimo de object name.
", "shallow clone (clonagem superficial)": "Em geral um sinônimo para shallow repository porém a frase a torna mais explicita criada ao executar o comando
", - "shallow repository (repositório raso)": "gitclone--depth=....Um repositório repositório raso possui um histórico incompleto da quais commits possui parents dos quais cauterizam (em outras palavras, o Git é informado para fingir que estes commits não possuam origens, ainda que esteja cadastrados no objeto commit). Algumas vezes é útil quando você está interessado apenas no histórico recente de um projeto, ainda que o histórico real registrado no \"upstream\" seja muito maior. Um repositório raso é criado, ao usar a opção
", + "shallow repository (repositório raso)": "--depthpara linkgit:git-clone[1] e o seu histórico pode ser aprofundado posteriormente com linkgit:git-fetch[1].Um repositório repositório raso possui um histórico incompleto da quais commits possui parents dos quais cauterizam (em outras palavras, o Git é informado para fingir que estes commits não possuam origens, ainda que esteja cadastrados no objeto commit). Algumas vezes é útil quando você está interessado apenas no histórico recente de um projeto, ainda que o histórico real registrado no \"upstream\" seja muito maior. Um repositório raso é criado, ao usar a opção
", "stash entry (lançamento para a armazenagem)": "--depthpara git-clone[1] e o seu histórico pode ser aprofundado posteriormente com git-fetch[1].Um objeto é utilizado para armazenar temporariamente o conteúdo de um diretório de trabalho sujo e o seu índice para utilização futura.
", "submodule (submódulo)": "Um repositório retém o histórico de um projeto separado dentro de um outro repositório (o último na qual é chamado de superproject).
", "superproject (superprojeto)": "Um repositório se refere a repositórios de outros projetos em suas próprias árvores de trabalho como submódulo. O superprojeto conhece os nomes dos (mas não mantém cópias de nenhum deles) commits dos objetos que contenham os submódulos.
", - "symref (referência simbólica)": "Uma referência simbólica: em vez de conter o próprio id SHA-1, ele tem o formato ref: refs/some/thing e quando é referenciado, elimina a referência recursivamente a esta referência. HEAD é o exemplo primário de um
", + "symref (referência simbólica)": "symref. As referências simbólicas são manipuladas com o comando linkgit:git-symbolic-ref[1].Uma referência simbólica: em vez de conter o próprio id SHA-1, ele tem o formato ref: refs/some/thing e quando é referenciado, elimina a referência recursivamente a esta referência. HEAD é o exemplo primário de um
", "tag (etiqueta)": "symref. As referências simbólicas são manipuladas com o comando git-symbolic-ref[1].Um ref sob
", "objeto tag (objeto etiqueta, objeto da etiqueta)": "refs/tags/no espaço de nomes que aponte para um objeto arbitrário (em geral uma tag que aponta seja para tag ou um objeto commit). Em contraste de um head, a tag não é atualizada pelo comandocommit. Uma tag Git não tem nada a ver com uma tagLisp(que seria chamada de object type dentro do contexto do Git). Uma tag é normalmente utilizada para marcar um ponto específico na ancestralidade de um commit chain.Um objeto contendo um ref apontando para outro objeto que pode conter uma mensagem como um objeto commit. Também pode conter uma assinatura (PGP), nesse caso, é chamado de \"signed tag object\".
", "topic branch (tópico do ramo)": "Um Git comum ramo que é utilizado por um desenvolvedor para identificar uma linha conceitual de desenvolvimento. Como as ramificações são muito fáceis e baratas, muitas vezes é desejável ter várias ramificações pequenas, cada uma contendo conceitos muito bem definidos ou pequenas alterações incrementais, porém relacionadas.
", - "trailer": "Key-value metadata. Trailers are optionally found at the end of a commit message. Might be called \"footers\" or \"tags\" in other communities. See linkgit:git-interpret-trailers[1].
", + "trailer": "Key-value metadata. Trailers are optionally found at the end of a commit message. Might be called \"footers\" or \"tags\" in other communities. See git-interpret-trailers[1].
", "tree (árvore)": "Entre um árvore de trabalho ou um objeto árvore junto com os objetos dependentes blob e os objetos das árvores (uma representação de uma árvore de trabalho).
", "tree object (objeto árvore)": "Um objeto contendo uma lista de nomes e modos em conjunto com
", "tree-ish (também treeish)": "refsassociados as sua bolhas e ou objetos da árvore. Um tree é equivalente a um diretório.Um objeto árvore ou um objeto que pode perder a referência recursivamente num objeto da árvore. Perder um objeto commit retorna o objeto da árvore revisão correspondente ao topo diretório. São todos os tree-ishes: um commit-ish, um objeto da árvore, um objeto tag que aponta para o objeto da árvore, um objeto tag que aponta para o objeto tag que aponta para o objeto árvore, etc.
", diff --git a/external/docs/data/glossary/ru.json b/external/docs/data/glossary/ru.json index d0663fd7fa..e41f788a69 100644 --- a/external/docs/data/glossary/ru.json +++ b/external/docs/data/glossary/ru.json @@ -23,13 +23,13 @@ "грязный (dirty)": "Рабочий каталог называют «грязным», если в нём есть изменения, которые ещё не были зафиксированы в текущей ветке.
", "порочное слияние (evil merge)": "Порочное слияние — это слияние, которое добавляет изменения, которых не было ни в одном из родительских коммитов.
", "быстрая перемотка (fast-forward)": "Быстрая перемотка — это особый тип слияния, когда вы «сливаете» уже имеющуюся у вас редакцию с изменениями в другой ветке, которые все являются потомками вашей редакции. В таком случае новый коммит слияния не будет создан, а вместо этого ваша ветка будет обновлена, чтобы она указывала на ту же редакцию, что и ветвь, с которой вы производите слияния. Такое часто будет происходить на отслеживаемых внешних ветках из удалённых репозиториев.
", - "извлечь (fetch)": "Извлечение ветки означает получение ссылки на голову этой ветки из внешнего репозитория, чтобы выяснить, какие объекты отсутствуют в локальной базе данных объектов, и получить их. См. также linkgit:git-fetch[1].
", + "извлечь (fetch)": "Извлечение ветки означает получение ссылки на голову этой ветки из внешнего репозитория, чтобы выяснить, какие объекты отсутствуют в локальной базе данных объектов, и получить их. См. также git-fetch[1].
", "файловая система": "Линус Торвальдс изначально разрабатывал Git как файловую систему в пользовательском пространстве, т.е. как инфраструктуру для хранения файлов и каталогов. Это являлось залогом эффективности и скорости работы Git.
", "Архив Git": "Синоним для репозитория (для ребят на Arch’е).
", - "git-файл (gitfile)": "Обычный файл
", - "сращивания (grafts)": ".gitв корне рабочего каталога, который указывает на каталог, являющийся настоящим репозиторием. Для непосредственно использования см. linkgit:git-worktree[1] или linkgit:git-submodule[1]. Для синтаксиса см. linkgit:gitrepository-layout[5].Сращивание позволяет объединять две иначе различные линии разработки, записывая фиктивную информацию о родстве коммитов. Таким образом, вы можете заставить Git делать вид, что набор родителей коммита, отличается от того, который был зафиксирован при создании коммита. Сращивания настраиваются в файле
\n.git/info/grafts.\n", + "git-файл (gitfile)": "Обратите внимание, что механизм сращиваний устарел и может вызывать проблемы при передаче объектов между репозиториями; смотрите linkgit:git-replace[1] для более гибкой и надёжной системы для выполнения той же задачи.
\nОбычный файл
", + "сращивания (grafts)": ".gitв корне рабочего каталога, который указывает на каталог, являющийся настоящим репозиторием. Для непосредственно использования см. git-worktree[1] или git-submodule[1]. Для синтаксиса см. gitrepository-layout[5].Сращивание позволяет объединять две иначе различные линии разработки, записывая фиктивную информацию о родстве коммитов. Таким образом, вы можете заставить Git делать вид, что набор родителей коммита, отличается от того, который был зафиксирован при создании коммита. Сращивания настраиваются в файле
\n.git/info/grafts.\n", "хеш (hash)": "Обратите внимание, что механизм сращиваний устарел и может вызывать проблемы при передаче объектов между репозиториями; смотрите git-replace[1] для более гибкой и надёжной системы для выполнения той же задачи.
\nВ контексте Git синоним имени объекта.
", - "голова (head)": "Именованная ссылка на коммит на верхушке ветки. Головы хранятся в файле в каталоге
", + "голова (head)": "$GIT_DIR/refs/heads/, за исключением случаев, когда используются упакованные ссылки. (См. linkgit:git-pack-refs[1].)Именованная ссылка на коммит на верхушке ветки. Головы хранятся в файле в каталоге
", "HEAD": "$GIT_DIR/refs/heads/, за исключением случаев, когда используются упакованные ссылки. (См. git-pack-refs[1].)Текущая ветка. Если подробнее, то ваш рабочий каталог, как правило, основывается на состоянии дерева, на которое указывает HEAD. HEAD — это ссылка на одну из голов голов веток, в вашем репозитории, за исключением случаев, когда указатель HEAD находится в отсоединённом состоянии; в этом случае он ссылается на произвольный коммит напрямую.
", "ссылка на голову (head ref)": "Синоним для головы (head).
", "перехватчик (hook)": "В ходе нормального выполнения некоторых команд Git могут вызываться дополнительные сценарии, которые позволяют разработчикам добавлять дополнительную функциональность или проверки. Обычно перехватчики позволяют проверить команду перед её непосредственным выполнением и, возможно, прервать её, а также выводить уведомления после завершения операции. Сценарии перехватчиков находятся в каталоге
", @@ -48,22 +48,22 @@ "оверлей (overlay)": "$GIT_DIR/hooks/и их можно включить просто удалив суффикс.sampleиз имени файла. В более ранних версиях Git вы также должны были сделать их исполняемыми.Режим, в котором файлы в рабочий каталоге только обновляются и добавляются, но не удаляются, подобно тому, как содержимое в целевом каталоге обновляет команда
", "пакет, pack-файл (pack)": "cp-R. Это режим извлечения состояния по умолчанию при извлечении отдельных файлов из индекса или указателя дерева. В отличие от него, «не оверлейный» режим также удаляет отслеживаемые файлы, отсутствующие в источнике, подобно тому как это делаетrsync--delete.Набор объектов, которые были сжаты в один файл (для экономии дискового пространства или эффективной передачи).
", "индекс пакета (pack index)": "Список идентификаторов объектов (и другая связанная с ними информация), хранимый в пакете, чтобы доступе к его содержимому был более эффективным.
", - "спецификатор пути (pathspec)": "Шаблоны, используемые для того чтобы ограничить пути в командах Git.
\n\n\nCпецификаторы пути используются в командной строке «git ls-files», «git ls-tree», «git add», «git grep», «git diff», «git checkout», а также многих других команд, чтобы ограничить область действия операций некоторым подмножеством в дереве или рабочем каталоге. Являются ли пути относительными для текущего каталога или корневого каталога рабочей копии, см. в документации каждой конкретной команды. Синтаксис спецификаторов пути следующий:
\n\n\n\n\n\n\n\n
\n- \n
\nлюбой путь соответствует самому себе
\n- \n
\nспецификатор пути до последнего слэша представляет собой префикс каталога. Область действия этого спецификатора пути ограничивается этим поддеревом.
\n- \n
\nостальная часть спецификатора пути является шаблоном для остатка пути. Пути относительно префикса каталога будут сопоставляться с этим шаблоном, используя fnmatch(3); в частности, * и ? могут быть сопоставлены символу разделителя каталогов.
\n\n\nНапример, Documentation/*.jpg будет сопоставлено всем файлам c расширением .jpg в поддереве Documentation, включая, Documentation/chapter_1/figure_1.jpg.
\n\n\nУ спецификатора пути, который начинается с двоеточия
\n:, есть особое значение. В короткой форме после начального двоеточия:идёт \"волшебная сигнатура\" (которая, по желанию, может завершаться вторым двоеточием:), а остаток является шаблоном, который будет сопоставляться с путём. \"Волшебная сигнатура\" состоит из ASCII-символов, которые не являются ни буквенно-цифровыми символями, ни glob-символами, ни особыми символами регулярных выражений, ни двоеточием. Двоеточие, которое завершает \"волшебную сигнатуру\", может быть опущено, если паттерн начинается с символа, который не входит в набор символов, допустимых в \"волшебной сигнатуре\", и не является двоеточием.\n\nВ длинной форме после двоеточия
\n:идёт открывающая скобка (, разделённый запятыми список из нуля или более \"волшебных слов\" и закрывающая скобка ), а остаток является шаблон, который будет сопоставляться пути.\n\nСпецификатор пути, содержащий только одно двоеточие, означает \"спецификатор пути отсутствует\". Эта форма не должна использоваться совместно с другими спецификаторами пути.
\n\n", + "спецификатор пути (pathspec)": "\n\n\n\n\n
\n- top
\n- \n
\nВолшебное слово
\ntop(волшебная сигнатура/) делает так, что паттерн сопоставляется относительно корня рабочего каталога, даже когда вы запускаете команду внутри одного из подкаталогов.- literal
\n- \n
\nДжокеры (
\n*и ?) в паттерне будут обрабатываться буквально, как обычные символы.- icase
\n- \n
\nСопоставление без учёта регистра.
\n- glob
\n- \n
\nGit будет обрабатывать паттерн как glob-выражение оболочки, передаваемого в fnmatch(3) с флагом FNM_PATHNAME: джокеры в шаблоне не будут сопоставляться слешу
\n/в путях. Например, шаблону \"Documentation/*.html\" будет сопоставлен \"Documentation/git.html\", но не \"Documentation/ppc/ppc.html\" или \"tools/perf/Documentation/perf.html\".\n\nДве последовательных звёздочки («
\n**») в шаблонах, сопоставленных с полным именем пути, могут иметь особое значение:\n\n\n
\n- \n
\nНачальные «
\n**», после которых идёт слэш (/) означают сопоставление во всех каталогах. Например, шаблон «**/foo» будет сопоставлять файл или каталог «`foo» в любом месте. А шаблон \"**/foo/bar\" будет сопоставлять файл или каталог \"bar\" в каталоге \"foo\", который в свою очередь уже может находится в любом месте.- \n
\nВыражению \"
\n/**\" на конце шаблона будет сопоставлено всё. Например, шаблону \"abc/**\" будут сопоставлены все файлы в каталоге \"abc\", относительно местоположения файла.gitignore, и всех его подкатологах рекурсивно.- \n
\nСлэш после которого идут две последовательные звёздочки, а затем ещё один слэш сопоставляется нулю или более каталогов. Например, шаблону «
\na/**/b» будут сопоставляться «a/b», «a/x/b», «a/x/y/b» и т.д.- \n
\nДальнейшие последующие звёздочки
\n*будут считаться ошибкой.\n\nМагическое слово \"glob\" несовместимо с \"literal\".
\n- attr
\n- \n
\nПосле
\nattr:идёт разделённый пробелами список \"требований аттрибутов\", каждое из которых должно быть удовлетворено, чтобы путь считался сопоставленным; всё это в дополнение к обычному, не волшебному, сопоставлению шаблона спецификаторов пути. См. linkgit:gitattributes[5].\n\nКаждое требование аттрибута пути принимает одну из следующих форм:
\n\n\n\n
\n- \n
\n\"АТТР\" требует чтобы аттрибут АТТР был установлен.
\n- \n
\n\"-АТТР\" требует, чтобы атрибут \"АТТР\" не был установлен.
\n- \n
\n\"АТТР=ЗНАЧЕНИЕ\" требует, чтобы в атрибуте \"АТТР\" было установлено строковое значение \"ЗНАЧЕНИЕ\".
\n- \n
\n\"‘!АТТР’\" требует, чтобы атрибут \"АТТР\" был неопределён.
\n\n\nОбратите внимание, что при сопоставлении с объектом-деревом, атрибуты всё равно будут получаться из рабочей копии, а не из объекта-дерева.
\n- exclude
\n- \n
\nПосле того, как спецификатор пути будет сопоставлен любому не-exclude шаблону, он будет проходить через все исключающие (exclude) спецификаторы пути (волшебная сигнатура: !', или её синоним: `^). Если шаблон будет сопоставлен, то, путь будет проигнорирован. Если не задано ни одного спецификатора пути кроме исключающих, то они будут применяется к тому набору путей, который был бы сформирован, если бы не было указано вообще ни одного спецификатора пути.
\nШаблоны, используемые для того чтобы ограничить пути в командах Git.
\n\n\nCпецификаторы пути используются в командной строке «git ls-files», «git ls-tree», «git add», «git grep», «git diff», «git checkout», а также многих других команд, чтобы ограничить область действия операций некоторым подмножеством в дереве или рабочем каталоге. Являются ли пути относительными для текущего каталога или корневого каталога рабочей копии, см. в документации каждой конкретной команды. Синтаксис спецификаторов пути следующий:
\n\n\n\n\n\n\n\n
\n- \n
\nлюбой путь соответствует самому себе
\n- \n
\nспецификатор пути до последнего слэша представляет собой префикс каталога. Область действия этого спецификатора пути ограничивается этим поддеревом.
\n- \n
\nостальная часть спецификатора пути является шаблоном для остатка пути. Пути относительно префикса каталога будут сопоставляться с этим шаблоном, используя fnmatch(3); в частности, * и ? могут быть сопоставлены символу разделителя каталогов.
\n\n\nНапример, Documentation/*.jpg будет сопоставлено всем файлам c расширением .jpg в поддереве Documentation, включая, Documentation/chapter_1/figure_1.jpg.
\n\n\nУ спецификатора пути, который начинается с двоеточия
\n:, есть особое значение. В короткой форме после начального двоеточия:идёт \"волшебная сигнатура\" (которая, по желанию, может завершаться вторым двоеточием:), а остаток является шаблоном, который будет сопоставляться с путём. \"Волшебная сигнатура\" состоит из ASCII-символов, которые не являются ни буквенно-цифровыми символями, ни glob-символами, ни особыми символами регулярных выражений, ни двоеточием. Двоеточие, которое завершает \"волшебную сигнатуру\", может быть опущено, если паттерн начинается с символа, который не входит в набор символов, допустимых в \"волшебной сигнатуре\", и не является двоеточием.\n\nВ длинной форме после двоеточия
\n:идёт открывающая скобка (, разделённый запятыми список из нуля или более \"волшебных слов\" и закрывающая скобка ), а остаток является шаблон, который будет сопоставляться пути.\n\nСпецификатор пути, содержащий только одно двоеточие, означает \"спецификатор пути отсутствует\". Эта форма не должна использоваться совместно с другими спецификаторами пути.
\n\n", "родитель (parent)": "\n\n\n\n\n
\n- top
\n- \n
\nВолшебное слово
\ntop(волшебная сигнатура/) делает так, что паттерн сопоставляется относительно корня рабочего каталога, даже когда вы запускаете команду внутри одного из подкаталогов.- literal
\n- \n
\nДжокеры (
\n*и ?) в паттерне будут обрабатываться буквально, как обычные символы.- icase
\n- \n
\nСопоставление без учёта регистра.
\n- glob
\n- \n
\nGit будет обрабатывать паттерн как glob-выражение оболочки, передаваемого в fnmatch(3) с флагом FNM_PATHNAME: джокеры в шаблоне не будут сопоставляться слешу
\n/в путях. Например, шаблону \"Documentation/*.html\" будет сопоставлен \"Documentation/git.html\", но не \"Documentation/ppc/ppc.html\" или \"tools/perf/Documentation/perf.html\".\n\nДве последовательных звёздочки («
\n**») в шаблонах, сопоставленных с полным именем пути, могут иметь особое значение:\n\n\n
\n- \n
\nНачальные «
\n**», после которых идёт слэш (/) означают сопоставление во всех каталогах. Например, шаблон «**/foo» будет сопоставлять файл или каталог «`foo» в любом месте. А шаблон \"**/foo/bar\" будет сопоставлять файл или каталог \"bar\" в каталоге \"foo\", который в свою очередь уже может находится в любом месте.- \n
\nВыражению \"
\n/**\" на конце шаблона будет сопоставлено всё. Например, шаблону \"abc/**\" будут сопоставлены все файлы в каталоге \"abc\", относительно местоположения файла.gitignore, и всех его подкатологах рекурсивно.- \n
\nСлэш после которого идут две последовательные звёздочки, а затем ещё один слэш сопоставляется нулю или более каталогов. Например, шаблону «
\na/**/b» будут сопоставляться «a/b», «a/x/b», «a/x/y/b» и т.д.- \n
\nДальнейшие последующие звёздочки
\n*будут считаться ошибкой.\n\nМагическое слово \"glob\" несовместимо с \"literal\".
\n- attr
\n- \n
\nПосле
\nattr:идёт разделённый пробелами список \"требований аттрибутов\", каждое из которых должно быть удовлетворено, чтобы путь считался сопоставленным; всё это в дополнение к обычному, не волшебному, сопоставлению шаблона спецификаторов пути. См. gitattributes[5].\n\nКаждое требование аттрибута пути принимает одну из следующих форм:
\n\n\n\n
\n- \n
\n\"АТТР\" требует чтобы аттрибут АТТР был установлен.
\n- \n
\n\"-АТТР\" требует, чтобы атрибут \"АТТР\" не был установлен.
\n- \n
\n\"АТТР=ЗНАЧЕНИЕ\" требует, чтобы в атрибуте \"АТТР\" было установлено строковое значение \"ЗНАЧЕНИЕ\".
\n- \n
\n\"‘!АТТР’\" требует, чтобы атрибут \"АТТР\" был неопределён.
\n\n\nОбратите внимание, что при сопоставлении с объектом-деревом, атрибуты всё равно будут получаться из рабочей копии, а не из объекта-дерева.
\n- exclude
\n- \n
\nПосле того, как спецификатор пути будет сопоставлен любому не-exclude шаблону, он будет проходить через все исключающие (exclude) спецификаторы пути (волшебная сигнатура: !', или её синоним: `^). Если шаблон будет сопоставлен, то, путь будет проигнорирован. Если не задано ни одного спецификатора пути кроме исключающих, то они будут применяется к тому набору путей, который был бы сформирован, если бы не было указано вообще ни одного спецификатора пути.
\nКаждый объект-коммит содержит (возможно, пустой) список своих логических предшественников в линии развития, т.е. его родителей.
", "шелушение (peel)": "Действие рекурсивного разыменования объекта-метки.
", - "кирка (pickaxe)": "Термин pickaxe относится к параметру подпрограмм diffcore, которая помогает выбирать изменения, добавляющие или удаляющие заданную текстовую строку. С помощью параметра
", + "кирка (pickaxe)": "--pickaxe-allёе можно использовать для просмотра полного набора изменений changeset, который ввёл или удалил, например, определённую строку текста. См. linkgit:git-diff[1].Термин pickaxe относится к параметру подпрограмм diffcore, которая помогает выбирать изменения, добавляющие или удаляющие заданную текстовую строку. С помощью параметра
", "внутренний интерфейс Git (plumbing)": "--pickaxe-allёе можно использовать для просмотра полного набора изменений changeset, который ввёл или удалил, например, определённую строку текста. См. git-diff[1].Тоже что и ядро Git. Иногда используется неформальный термин «plumbing» (канализация).
", "пользовательские программы, высокоуровневый программный интерфейс Git, фарфор (porcelain)": "Высокоуровневый программный интерфейс к ядру Git, который предоставляет доступ к нему в виде вызовов больше напоминающих работу с СКВ. Подобно тому как фарфоровые изделия в наших домах предоставляют более удобный доступ к канализационным трубам, «фарфоровый» интерфейс предоставляет доступ к внутреннему интерфейсу Git. Кроме того термином «фарфор» (porcelain) называют сами высокоуровневые пользовательские программы и пакеты программ, а также машиночитаемый формат данных, используемый в этом интерфейсе.
", "per-worktree ref": "Refs that are per-worktree, rather than global. This is presently only HEAD and any refs that start with
", - "pseudoref": "refs/bisect/, but might later include other unusual refs.Ссылка, семантика которой отличается от семантики обычных ссылок. Эти ссылки можно читать с помощью обычных команд Git, но их нельзя записывать с помощью таких команд, как linkgit:git-update-ref[1].
\n\n\nGit знает следующие псевдоссылки:
\n\n", - "получить": "\n
\n- \n
\n\n
FETCH_HEADis written by linkgit:git-fetch[1] or linkgit: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.- \n
\n\n
MERGE_HEADзаписывается linkgit:git-merge[1] при разрешении конфликтов слияния. Он содержит все идентификаторы коммитов, которые сливаются.Получение branch означает выполнение fetch и merge. См. также linkgit:git-pull[1].
", + "pseudoref": "Ссылка, семантика которой отличается от семантики обычных ссылок. Эти ссылки можно читать с помощью обычных команд Git, но их нельзя записывать с помощью таких команд, как git-update-ref[1].
\n\n\nGit знает следующие псевдоссылки:
\n\n", + "получить": "\n
\n- \n
\n\n
FETCH_HEADis 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.- \n
\n\n
MERGE_HEADзаписывается git-merge[1] при разрешении конфликтов слияния. Он содержит все идентификаторы коммитов, которые сливаются.Получение branch означает выполнение fetch и merge. См. также git-pull[1].
", "отправить": "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.
", "достижимость": "Говорят, что все предки данного коммита «достижимы» из этого коммита. В более общем смысле, один объект достижим из другого, если мы можем добраться из одного до другого по цепочке переходов от метки к тому на что эта метка ссылается, от коммитов к их родителям или деревьям, и от деревьев к содержащимся в них поддеревьям или blob-объектам.
", "битовые карты доступности": "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).
", "перебазировать": "To reapply a series of changes from a branch to a different base, and reset the head of that branch to the result.
", - "ссылка (ref)": "Имя, которое указывает на имя объекта или другую ссылку (в последнем случае она называется символической ссылкой). Для удобства при использовании в качестве аргумента в командах Git, иногда ссылки могут быть сокращены; см. подробности в linkgit:gitrevisions[7]. Ссылки хранятся в репозиториях.
\n\n\nПространство имён ссылки является иерархическим. Имена ссылок должны начинаться с
\nrefs/или находиться в корне иерархии. В последнем случае их имена должны соответствовать следующим правилам:\n", - "reflog": "\n
\n- \n
\nИмя состоит только из заглавных букв или символов подчёркивания.
\n- \n
\nИмя заканчивается на «
\n_HEAD» или равно «HEAD».\n\nВ корне иерархии есть некоторые нестандартные ссылки, которые не соответствуют этим правилам. Следующий список является исчерпывающим и не будет расширяться в будущем:
\n- \n
\n\n
AUTO_MERGE- \n
\n\n
BISECT_EXPECTED_REV- \n
\n\n
NOTES_MERGE_PARTIAL- \n
\n\n
NOTES_MERGE_REF- \n
\n\n
MERGE_AUTOSTASH\n\nDifferent subhierarchies are used for different purposes. For example, the
\nrefs/heads/hierarchy is used to represent local branches whereas therefs/tags/hierarchy is used to represent local tags..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 linkgit:git-reflog[1] for details.
", - "спецификатор ссылки (refspec)": "«Спецификатор ссылки» используется при извлечении (fetch) и отправке (push) для описания соответствия между внешней и локальной ссылками. См. подробности в linkgit:git-fetch[1] или linkgit:git-push[1].
", + "ссылка (ref)": "Имя, которое указывает на имя объекта или другую ссылку (в последнем случае она называется символической ссылкой). Для удобства при использовании в качестве аргумента в командах Git, иногда ссылки могут быть сокращены; см. подробности в gitrevisions[7]. Ссылки хранятся в репозиториях.
\n\n\nПространство имён ссылки является иерархическим. Имена ссылок должны начинаться с
\nrefs/или находиться в корне иерархии. В последнем случае их имена должны соответствовать следующим правилам:\n", + "reflog": "\n
\n- \n
\nИмя состоит только из заглавных букв или символов подчёркивания.
\n- \n
\nИмя заканчивается на «
\n_HEAD» или равно «HEAD».\n\nВ корне иерархии есть некоторые нестандартные ссылки, которые не соответствуют этим правилам. Следующий список является исчерпывающим и не будет расширяться в будущем:
\n- \n
\n\n
AUTO_MERGE- \n
\n\n
BISECT_EXPECTED_REV- \n
\n\n
NOTES_MERGE_PARTIAL- \n
\n\n
NOTES_MERGE_REF- \n
\n\n
MERGE_AUTOSTASH\n\nDifferent subhierarchies are used for different purposes. For example, the
\nrefs/heads/hierarchy is used to represent local branches whereas therefs/tags/hierarchy is used to represent local tags..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)": "«Спецификатор ссылки» используется при извлечении (fetch) и отправке (push) для описания соответствия между внешней и локальной ссылками. См. подробности в git-fetch[1] или git-push[1].
", "внешний репозиторий": "Репозиторий, который используется для отслеживания того же проекта, но находится где-то в другом месте. Чтобы общаться со внешними или удалёнными репозиториями, см. описания извлечения (fetch) или отправки (push).
", "отслеживаемая внешняя ветка (remote-tracking branch)": "Ссылка, которая используется для отслеживания изменений из другого репозитория. Обычно она выглядит как «refs/remotes/foo/bar» (что указывает, что она отслеживает ветвь под названием «bar» во внешнем репозитории «foo»), и соответствует правой стороне спецификатора ссылки, которая используется при извлечении (fetch). Отслеживаемая внешняя ветка не должна содержать прямых модификаций или иметь локальные коммиты.
", "репозиторий": "Коллекция ссылок вместе с базой данных объектов содержащей все объекты, достижимые из ссылок, возможно, вместе с данными одной или нескольких пользовательских программ. Репозиторий может использовать свою базу данных объектов совместно с другими репозиториями через механизм дополнения базы данных.
", @@ -73,15 +73,15 @@ "СКВ (SCM)": "Система контроля версий (как инструмент), то же что и система управления версиями, систему управления исходным кодом, SCM-система.
", "SHA-1": "\"Secure Hash Algorithm 1\" (безопасный алгоритм хеширования-1); криптографическая хеш-функция. В контексте Git используется как синоним для имени объекта.
", "частичный клон (shallow clone)": "По большей части, это синоним для «частичный репозиторий», но эта формулировка делает акцент на том, что он был создан с помощью команды вроде
", - "частичный репозиторий (shallow repository)": "gitclone--depth=....Частичный репозиторий имеет неполную историю: ссылки на родителей некоторых из его коммитов были «ампутированы» (другими словами, Git’у сказано делать вид, что эти коммиты не имеют родителей, несмотря на то, что в объектном предаставлении этого коммита эти записи всё ещё присутствуют). Иногда это может быть полезно, например, когда вас интересует только недавняя история проекта, даже если реальная история, хранящаяся в вышестоящем репозитории, куда больше. Частичный репозиторий можно создать, передав параметр
", + "частичный репозиторий (shallow repository)": "--depthв linkgit:git-clone[1], и его история может быть позже углублена с помощью linkgit:git-fetch[1].Частичный репозиторий имеет неполную историю: ссылки на родителей некоторых из его коммитов были «ампутированы» (другими словами, Git’у сказано делать вид, что эти коммиты не имеют родителей, несмотря на то, что в объектном предаставлении этого коммита эти записи всё ещё присутствуют). Иногда это может быть полезно, например, когда вас интересует только недавняя история проекта, даже если реальная история, хранящаяся в вышестоящем репозитории, куда больше. Частичный репозиторий можно создать, передав параметр
", "stash entry": "--depthв git-clone[1], и его история может быть позже углублена с помощью git-fetch[1].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.
", - "символическая ссылка (symref)": "Вместо того, чтобы непосредственно содержать SHA-1, символическая ссылка имеет формат \"ref: refs/some/thing\" и при обращении она рекурсивно разыменовывается. «HEAD» — самый простой пример символической ссылки. Манипулировать символическими ссылками можно с помощью команды linkgit:git-symbolic-ref[1].
", + "символическая ссылка (symref)": "Вместо того, чтобы непосредственно содержать SHA-1, символическая ссылка имеет формат \"ref: refs/some/thing\" и при обращении она рекурсивно разыменовывается. «HEAD» — самый простой пример символической ссылки. Манипулировать символическими ссылками можно с помощью команды git-symbolic-ref[1].
", "метка (tag)": "Ссылка в пространстве имён
", "объект-метка": "refs/tags/, которая указывает на объект произвольного типа (как правило, метка указывает либо на объект-метку, либо на объект-коммит). В отличие от головы ветки, метка не обновляется командойcommit. Метки в Git не имеют ничего общего с тегами Lisp (который назывались бы типами объектов в контексте Git). Метка, как правило, используется для того, чтобы пометить определённую точку в цепочке наследования.Объект, который содержит ссылку, указывающую на другой объект, который может содержать сообщение точно так же, как объект-коммит. Он также может содержать подпись (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.
", - "завершитель (trailer)": "Метаданные вида «Ключ: Значение». Завершители находятся в конце сообщений коммитов. Они могут также называться «футтерами» («footer»), «тегами» («tags») или «трейлерами» в различных сообществах. linkgit:git-interpret-trailers[1].
", + "завершитель (trailer)": "Метаданные вида «Ключ: Значение». Завершители находятся в конце сообщений коммитов. Они могут также называться «футтерами» («footer»), «тегами» («tags») или «трейлерами» в различных сообществах. git-interpret-trailers[1].
", "дерево (tree)": "Либо рабочий каталог, либо объект-дерево вместе со всеми своими зависимыми blob-объектами и объектами-деревьями (т.е. сохранённое представление рабочего каталога).
", "объект-дерево (tree object)": "Объект, который содержит список имён и прав доступа вместе со связанным с ними ссылками на бинарные объекты и/или другие объекты-деревья. Дерево эквивалентно каталогу.
", "tree-ish": "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.
", diff --git a/external/docs/data/glossary/sv.json b/external/docs/data/glossary/sv.json index 516cc8bb9e..291faba77b 100644 --- a/external/docs/data/glossary/sv.json +++ b/external/docs/data/glossary/sv.json @@ -23,13 +23,13 @@ "smutsig": "Ett arbetskatalog sägs vara \"smutsigt\" om det innehåller modifieringar som inte har incheckats till det aktuella grenen.
", "ond sammanslagning": "En ond sammanslagning är en sammanslagning som introducerar ändringar som inte visas i någon förälder.
", "snabbspola": "En snabbspolning är en speciell typ av sammanslagning där du har en revision och du \"sammanfogar\" en annan grens ändringar som råkar vara en underordnad fil till det du har. I ett sådant fall skapar du inte en ny sammanslagning incheckning utan uppdaterar istället bara din gren så att den pekar på samma revision som den gren du sammanfogar. Detta händer ofta på en fjärrspårningsgrenar tillhörande ett avlägset förvar.
", - "hämta": "Att hämta (\"Fetcha\") en gren innebär att hämta grenens huvud ref från ett fjärranslutet förvar, för att ta reda på vilka objekt som saknas i den lokala objektdatabasen, och för att hämta dem också. Se även linkgit:git-fetch[1].
", + "hämta": "Att hämta (\"Fetcha\") en gren innebär att hämta grenens huvud ref från ett fjärranslutet förvar, för att ta reda på vilka objekt som saknas i den lokala objektdatabasen, och för att hämta dem också. Se även git-fetch[1].
", "filsystem": "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.
", "Git arkiv": "Synonym för förvar (för ärkepersoner).
", - "gitfil": "En vanlig fil
", - "Ympningar": ".gitvid roten av ett arbetskatalog som pekar på den katalog som är det verkliga förvar. För korrekt användning, se linkgit:git-worktree[1] eller linkgit:git-submodule[1]. För syntax, se linkgit:gitrepository-layout[5].Ympningar gör det möjligt att sammanfoga två annars olika utvecklingslinjer genom att registrera falsk anorinformation för incheckningar. På så sätt kan du få Git att låtsas att uppsättningen föräldrar som en incheckningar har skiljer sig från vad som registrerades när incheckningen skapades. Konfigureras via filen
\n.git/info/grafts.\n", + "gitfil": "Observera att ympnings-mekanismen är föråldrad och kan leda till problem med att överföra objekt mellan arkiv; se linkgit:git-replace[1] för ett mer flexibelt och robust system som gör samma sak.
\nEn vanlig fil
", + "Ympningar": ".gitvid roten av ett arbetskatalog som pekar på den katalog som är det verkliga förvar. För korrekt användning, se git-worktree[1] eller git-submodule[1]. För syntax, se gitrepository-layout[5].Ympningar gör det möjligt att sammanfoga två annars olika utvecklingslinjer genom att registrera falsk anorinformation för incheckningar. På så sätt kan du få Git att låtsas att uppsättningen föräldrar som en incheckningar har skiljer sig från vad som registrerades när incheckningen skapades. Konfigureras via filen
\n.git/info/grafts.\n", "hash": "Observera att ympnings-mekanismen är föråldrad och kan leda till problem med att överföra objekt mellan arkiv; se git-replace[1] för ett mer flexibelt och robust system som gör samma sak.
\nI Gits kontext, synonym för objektnamn.
", - "huvud": "En namngiven referens till incheckning i toppen av en gren. Heads lagras i en fil i katalogen
", + "huvud": "$GIT_DIR/refs/heads/, förutom när packade referenser används. (Se linkgit:git-pack-refs[1].)En namngiven referens till incheckning i toppen av en gren. Heads lagras i en fil i katalogen
", "HEAD": "$GIT_DIR/refs/heads/, förutom när packade referenser används. (Se git-pack-refs[1].)Den aktuella grenen. Mer detaljerat: Ditt arbetskatalog härleds normalt från trädets tillstånd som HEAD refererar till. HEAD är en referens till en av heads i ditt förvar, förutom när du använder en fristående huvud (HEAD), i vilket fall den direkt refererar till en godtycklig incheckning.
", "huvud ref": "A synonym for huvud.
", "krok": "Under normal exekvering av flera Git-kommandon görs anrop till valfria skript som tillåter en utvecklare att lägga till funktionalitet eller kontroll. Vanligtvis tillåter krokarna (hook) att ett kommando förverifieras och eventuellt avbryts, och möjliggör en eftermeddelande efter att operationen är klar. Krok-skripten finns i katalogen
", @@ -48,22 +48,22 @@ "överlägg": "$GIT_DIR/hooks/och aktiveras genom att helt enkelt ta bort suffixet.samplefrån filnamnet. I tidigare versioner av Git var man tvungen att göra dem körbara.Uppdatera och lägg bara till filer i arbetskatalogen, men ta inte bort dem, ungefär på samma sätt som cp -R skulle uppdatera innehållet i målkatalogen. Detta är standardläget i en utcheckning när man checkar ut filer från index eller en trädlikt. Däremot tar läget utan överlagring också bort spårade filer som inte finns i källkoden, ungefär som rsync --delete.
", "pack": "En uppsättning objekt som har komprimerats till en fil (för att spara utrymme eller för att överföra dem effektivt).
", "pack index": "Listan över identifierare och annan information om objekten i ett packet, för att effektivt komma åt innehållet i ett paket.
", - "sökvägsspec": "Mönster som används för att begränsa sökvägar i Git-kommandon.
\n\n\nSökvägsspec används på kommandoraden för \"git ls-files\", \"git ls-tree\", \"git add\", \"git grep\", \"git diff\", \"git checkout\" och många andra kommandon för att begränsa operationernas omfattning till en delmängd av trädet eller arbetsträdet. Se dokumentationen för varje kommando för att se om sökvägarna är relativa till den aktuella katalogen eller toppnivån. Syntaxen för sökvägsspec är följande:
\n\n\n\n\n\n\n\n
\n- \n
\nvarje sökväg matchar sig själv
\n- \n
\nSökvägsspecifikationen fram till sista snedstrecket representerar ett katalogprefix. Omfattningen av den sökvägsspecifikationen är begränsad till det underträdet.
\n- \n
\nresten av sökvägsspecifikationen är ett mönster för resten av sökvägsnamnet. Sökvägar relativa till katalogprefixet matchas mot det mönstret med hjälp av fnmatch(3); i synnerhet matchar * och ? kan katalogavgränsare.
\n\n\nTill exempel, kommer Documentation/*.jpg att matcha alla .jpg-filer i underträdet Dokumentation, inklusive Documentation/kapitel_1/figur_1.jpg.
\n\n\nEn sökvägsspecifikation som börjar med ett kolon
\n:har en speciell betydelse. I den korta formen följs det inledande kolonet:av noll eller fler \"magiska signatur\"-bokstäver (som valfritt avslutas med ett annat kolon:), och resten är mönstret som matchar sökvägen. Den \"magiska signaturen\" består av ASCII-symboler som varken är alfanumeriska, glob-, regex-specialtecken eller kolon. Det valfria kolonet som avslutar den \"magiska signaturen\" kan utelämnas om mönstret börjar med ett tecken som inte tillhör symboluppsättningen \"magisk signatur\" och inte är ett kolon.\n\nI den långa formen följs det inledande kolonet
\n:av en öppen parentes (, en kommaseparerad lista med noll eller fler \"magiska ord\" och en avslutande parentes ), och resten är mönstret som ska matchas mot sökvägen.\n\nEn sökvägsspec med endast ett kolon betyder \"det finns ingen sökvägsspec\". Denna form bör inte kombineras med andra sökvägsspec.
\n\n", + "sökvägsspec": "\n\n\n\n\n
\n- top
\n- \n
\nDet magiska ordet
\ntop(magisk signatur:/) gör att mönstret matchar från roten av arbetsträdet, även när du kör kommandot inifrån en underkatalog.- bokstavlig
\n- \n
\nJokertecken i mönstret, såsom
\n*eller ?, behandlas som teckenlekter.- icase
\n- \n
\nSkiftlägeskänslig matchning.
\n- glob
\n- \n
\nGit behandlar mönstret som en skal-glob lämplig för konsumtion av fnmatch(3) med flaggan FNM_PATHNAME: jokertecken i mönstret kommer inte att matcha en / i sökvägen. Till exempel matchar \"Documentation/*.html\" \"Documentation/git.html\" men inte \"Documentation/ppc/ppc.html\" eller \"tools/perf/Documentation/perf.html\".
\n\n\nTvå asterisker i rad (\"
\n**\") i mönster som matchar det fullständiga sökvägsnamnet kan ha en speciell betydelse:\n\n\n
\n- \n
\nEtt inledande \"
\n**\" följt av ett snedstreck betyder matchning i alla kataloger. Till exempel matchar \"**/foo\" filen eller katalogen \"foo\" var som helst. \"**/foo/bar\" matchar filen eller katalogen \"bar\" var som helst som ligger direkt under katalogen \"foo\".- \n
\nEtt efterföljande \"
\n/**\" matchar allt inuti. Till exempel matchar \"abc/**\" alla filer i katalogen \"abc\", relativt till platsen för.gitignore-filen, med oändligt djup.- \n
\nEtt snedstreck följt av två asterisker i rad, sedan ett snedstreck, matchar noll eller fler kataloger. Till exempel matchar \"
\na/**/b\" \"a/b\", \"a/x/b\", \"a/x/y/b\" och så vidare.- \n
\nAndra efterföljande asterisker anses ogiltiga.
\n\n\nGlobmagi är oförenlig med bokstavlig magi.
\n- attr
\n- \n
\nEfter
\nattr:kommer en mellanslagsseparerad lista med \"attributkrav\", som alla måste vara uppfyllda för att sökvägen ska betraktas som en matchning; detta är utöver den vanliga icke-magiska sökvägsspecifikations-mönster-matchningen. Se linkgit:gitattributes[5].\n\nVarje attributkrav för sökvägen har en av dessa former:
\n\n\n\n
\n- \n
\n\"
\nATTR\" kräver att attributetATTRär angivet.- \n
\n\"
\n-ATTR\" kräver att attributetATTRinte är angivet.- \n
\n\"
\nATTR=VALUE\" kräver att attributetATTRsätts till strängenVALUE.- \n
\n\"
\n!ATTR\" kräver att attributetATTRär ospecificerat.\n\nObservera att vid matchning mot ett trädobjekt hämtas attribut fortfarande från arbetskatalogen, inte från det givna trädobjektet.
\n- uteslut
\n- \n
\nEfter att en sökväg matchar en icke-exkluderad sökvägsspecifikation, kommer den att köras genom alla exkluderade sökvägsspecifikationer (magisk signatur:
\n!eller dess synonym^). Om den matchar, ignoreras sökvägen. När det inte finns någon icke-exkluderad sökvägsspecifikation, tillämpas exkluderingen på resultatmängden som om den anropades utan någon sökvägsspecifikation.Mönster som används för att begränsa sökvägar i Git-kommandon.
\n\n\nSökvägsspec används på kommandoraden för \"git ls-files\", \"git ls-tree\", \"git add\", \"git grep\", \"git diff\", \"git checkout\" och många andra kommandon för att begränsa operationernas omfattning till en delmängd av trädet eller arbetsträdet. Se dokumentationen för varje kommando för att se om sökvägarna är relativa till den aktuella katalogen eller toppnivån. Syntaxen för sökvägsspec är följande:
\n\n\n\n\n\n\n\n
\n- \n
\nvarje sökväg matchar sig själv
\n- \n
\nSökvägsspecifikationen fram till sista snedstrecket representerar ett katalogprefix. Omfattningen av den sökvägsspecifikationen är begränsad till det underträdet.
\n- \n
\nresten av sökvägsspecifikationen är ett mönster för resten av sökvägsnamnet. Sökvägar relativa till katalogprefixet matchas mot det mönstret med hjälp av fnmatch(3); i synnerhet matchar * och ? kan katalogavgränsare.
\n\n\nTill exempel, kommer Documentation/*.jpg att matcha alla .jpg-filer i underträdet Dokumentation, inklusive Documentation/kapitel_1/figur_1.jpg.
\n\n\nEn sökvägsspecifikation som börjar med ett kolon
\n:har en speciell betydelse. I den korta formen följs det inledande kolonet:av noll eller fler \"magiska signatur\"-bokstäver (som valfritt avslutas med ett annat kolon:), och resten är mönstret som matchar sökvägen. Den \"magiska signaturen\" består av ASCII-symboler som varken är alfanumeriska, glob-, regex-specialtecken eller kolon. Det valfria kolonet som avslutar den \"magiska signaturen\" kan utelämnas om mönstret börjar med ett tecken som inte tillhör symboluppsättningen \"magisk signatur\" och inte är ett kolon.\n\nI den långa formen följs det inledande kolonet
\n:av en öppen parentes (, en kommaseparerad lista med noll eller fler \"magiska ord\" och en avslutande parentes ), och resten är mönstret som ska matchas mot sökvägen.\n\nEn sökvägsspec med endast ett kolon betyder \"det finns ingen sökvägsspec\". Denna form bör inte kombineras med andra sökvägsspec.
\n\n", "förälder": "\n\n\n\n\n
\n- top
\n- \n
\nDet magiska ordet
\ntop(magisk signatur:/) gör att mönstret matchar från roten av arbetsträdet, även när du kör kommandot inifrån en underkatalog.- bokstavlig
\n- \n
\nJokertecken i mönstret, såsom
\n*eller ?, behandlas som teckenlekter.- icase
\n- \n
\nSkiftlägeskänslig matchning.
\n- glob
\n- \n
\nGit behandlar mönstret som en skal-glob lämplig för konsumtion av fnmatch(3) med flaggan FNM_PATHNAME: jokertecken i mönstret kommer inte att matcha en / i sökvägen. Till exempel matchar \"Documentation/*.html\" \"Documentation/git.html\" men inte \"Documentation/ppc/ppc.html\" eller \"tools/perf/Documentation/perf.html\".
\n\n\nTvå asterisker i rad (\"
\n**\") i mönster som matchar det fullständiga sökvägsnamnet kan ha en speciell betydelse:\n\n\n
\n- \n
\nEtt inledande \"
\n**\" följt av ett snedstreck betyder matchning i alla kataloger. Till exempel matchar \"**/foo\" filen eller katalogen \"foo\" var som helst. \"**/foo/bar\" matchar filen eller katalogen \"bar\" var som helst som ligger direkt under katalogen \"foo\".- \n
\nEtt efterföljande \"
\n/**\" matchar allt inuti. Till exempel matchar \"abc/**\" alla filer i katalogen \"abc\", relativt till platsen för.gitignore-filen, med oändligt djup.- \n
\nEtt snedstreck följt av två asterisker i rad, sedan ett snedstreck, matchar noll eller fler kataloger. Till exempel matchar \"
\na/**/b\" \"a/b\", \"a/x/b\", \"a/x/y/b\" och så vidare.- \n
\nAndra efterföljande asterisker anses ogiltiga.
\n\n\nGlobmagi är oförenlig med bokstavlig magi.
\n- attr
\n- \n
\nEfter
\nattr:kommer en mellanslagsseparerad lista med \"attributkrav\", som alla måste vara uppfyllda för att sökvägen ska betraktas som en matchning; detta är utöver den vanliga icke-magiska sökvägsspecifikations-mönster-matchningen. Se gitattributes[5].\n\nVarje attributkrav för sökvägen har en av dessa former:
\n\n\n\n
\n- \n
\n\"
\nATTR\" kräver att attributetATTRär angivet.- \n
\n\"
\n-ATTR\" kräver att attributetATTRinte är angivet.- \n
\n\"
\nATTR=VALUE\" kräver att attributetATTRsätts till strängenVALUE.- \n
\n\"
\n!ATTR\" kräver att attributetATTRär ospecificerat.\n\nObservera att vid matchning mot ett trädobjekt hämtas attribut fortfarande från arbetskatalogen, inte från det givna trädobjektet.
\n- uteslut
\n- \n
\nEfter att en sökväg matchar en icke-exkluderad sökvägsspecifikation, kommer den att köras genom alla exkluderade sökvägsspecifikationer (magisk signatur:
\n!eller dess synonym^). Om den matchar, ignoreras sökvägen. När det inte finns någon icke-exkluderad sökvägsspecifikation, tillämpas exkluderingen på resultatmängden som om den anropades utan någon sökvägsspecifikation.Ett incheckning objekt innehåller en (möjligen tom) lista över den/de logiska föregångaren/föregångarna i utvecklingslinjen, dvs. dess föräldrar.
", "peel (skala)": "Åtgärden att rekursivt avreferera ett tag-objekt.
", - "hacka": "Termen hacka hänvisar till ett alternativ till diffcore-rutinerna som hjälper till att välja ändringar som lägger till eller tar bort en given textsträng. Med alternativet
", + "hacka": "--pickaxe-allkan det användas för att visa hela ändringsset som införde eller tog bort, till exempel, en viss textrad. Se linkgit:git-diff[1].Termen hacka hänvisar till ett alternativ till diffcore-rutinerna som hjälper till att välja ändringar som lägger till eller tar bort en given textsträng. Med alternativet
", "plumbing": "--pickaxe-allkan det användas för att visa hela ändringsset som införde eller tog bort, till exempel, en viss textrad. Se git-diff[1].Sött namn för kärnan av Git.
", "porcelain": "Sött namn för program och programsviter som är beroende av core Git, vilket ger högnivååtkomst till core Git. Porslin exponerar mer av ett SCM-gränssnitt än rörmokeri.
", "per-arbetsträdsreferens": "Referenser som är per-arbetsträd, snarare än globala. Detta är för närvarande endast HEAD och alla referenser som börjar med
", - "pseudoref": "refs/bisect/, men kan senare inkludera andra ovanliga referenser.En referens som har annan semantik än vanliga referenser. Dessa referenser kan läsas via vanliga Git-kommandon, men kan inte skrivas till med kommandon som linkgit:git-update-ref[1].
\n\n\nFöljande pseudorefs är kända för Git:
\n\n", - "dra in (\"pulla\")": "\n
\n- \n
\n\n
FETCH_HEADskrivs av linkgit:git-fetch[1] eller linkgit:git-pull[1]. Det kan referera till flera objekt-ID:n. Varje objekt-ID är annoterat med metadata som anger var det hämtades ifrån och dess hämtningsstatus.- \n
\n\n
MERGE_HEADskrivs av linkgit:git-merge[1] när det gäller att lösa sammanslagningskonflikter. Den innehåller alla incheckning-ID:n som sammanfogas.Att dra in (\"pulla\") en gren innebär att hämta den och sammanslå den. Se även linkgit:git-pull[1].
", + "pseudoref": "En referens som har annan semantik än vanliga referenser. Dessa referenser kan läsas via vanliga Git-kommandon, men kan inte skrivas till med kommandon som git-update-ref[1].
\n\n\nFöljande pseudorefs är kända för Git:
\n\n", + "dra in (\"pulla\")": "\n
\n- \n
\n\n
FETCH_HEADskrivs av git-fetch[1] eller git-pull[1]. Det kan referera till flera objekt-ID:n. Varje objekt-ID är annoterat med metadata som anger var det hämtades ifrån och dess hämtningsstatus.- \n
\n\n
MERGE_HEADskrivs av git-merge[1] när det gäller att lösa sammanslagningskonflikter. Den innehåller alla incheckning-ID:n som sammanfogas.Att dra in (\"pulla\") en gren innebär att hämta den och sammanslå den. Se även git-pull[1].
", "sänd (\"pusha\")": "Att sända (\"pusha\") en gren innebär att hämta grenens huvud ref från ett fjärr-repo, ta reda på om det är en förfader till grenens lokala huvud-referens, och i så fall lägga till alla objekt som är nåbar från den lokala huvud-referensen, och som saknas i fjärrförvar, till det fjärranslutna objektdatabas, och uppdatera den fjärranslutna huvud-referensen. Om den fjärranslutna huvud inte är en förfader till det lokala huvud-värdet, misslyckas sänd-processen.
", "nåbar": "Alla förfäder till en given incheckning sägs vara \"nåbara\" från den incheckningen. Mer generellt är en objekt nåbar från en annan om vi kan nå den från den andra via en kedja som följer tags till vad de än taggar, incheckningar till deras föräldrar eller träd, och träd till de träd eller blobs som de innehåller.
", "nåbarhetsbitmappar": "Nåbarhetsbitmappar lagrar information om nåbarhet för en vald uppsättning incheckningar i en packfil, eller ett multipackindex (MIDX), för att snabba upp objektsökningen. Bitmapparna lagras i en \".bitmap\"-fil. Ett arkiv får ha högst en bitmappsfil i bruk. Bitmappsfilen kan tillhöra antingen ett paket eller arkivets multipackindex (om det finns).
", "ombasering (\"rebase\")": "För att återanvända en serie ändringar från en gren till en annan bas, och återställa huvudet för den grenen till resultatet.
", - "ref": "Ett namn som pekar på en objektnamn eller en annan referens (den senare kallas en symbolisk ref). För enkelhetens skull kan en referens ibland förkortas när den används som ett argument till ett Git-kommando; se linkgit:gitrevisions[7] för mer information. Referenser lagras i förvar.
\n\n\nRef-namnrymden är hierarkisk. Ref-namn måste antingen börja med
\nrefs/eller finnas i roten av hierarkin. För de senare måste deras namn följa dessa regler:\n", - "reflogg": "\n
\n- \n
\nNamnet består endast av versaler eller understreck.
\n- \n
\nNamnet slutar med \"
\n_HEAD\" eller är lika med \"HEAD\".\n\nDet finns några oregelbundna referenser i hierarkin som inte överensstämmer med dessa regler. Följande lista är uttömmande och kommer inte att utökas i framtiden:
\n- \n
\n\n
AUTO_MERGE- \n
\n\n
BISECT_EXPECTED_REV- \n
\n\n
NOTES_MERGE_PARTIAL- \n
\n\n
NOTES_MERGE_REF- \n
\n\n
MERGE_AUTOSTASH\n\nOlika underhierarkier används för olika ändamål. Till exempel används hierarkin
\nrefs/heads/för att representera lokala grenar medan hierarkinrefs/tags/används för att representera lokala taggar.En reflogg visar den lokala \"historiken\" för en referens. Med andra ord kan den berätta vad den tredje senaste revisionen i detta repo var, och vad det aktuella läget var i detta repo, igår klockan 21:14. Se linkgit:git-reflog[1] för mer information.
", - "refspec": "En \"refspec\" används av hämta (\"fetcha\") och sänd (\"pusha\") för att beskriva mappningen mellan fjärren ref och lokal referens. Se linkgit:git-fetch[1] eller linkgit:git-push[1] för detaljer.
", + "ref": "Ett namn som pekar på en objektnamn eller en annan referens (den senare kallas en symbolisk ref). För enkelhetens skull kan en referens ibland förkortas när den används som ett argument till ett Git-kommando; se gitrevisions[7] för mer information. Referenser lagras i förvar.
\n\n\nRef-namnrymden är hierarkisk. Ref-namn måste antingen börja med
\nrefs/eller finnas i roten av hierarkin. För de senare måste deras namn följa dessa regler:\n", + "reflogg": "\n
\n- \n
\nNamnet består endast av versaler eller understreck.
\n- \n
\nNamnet slutar med \"
\n_HEAD\" eller är lika med \"HEAD\".\n\nDet finns några oregelbundna referenser i hierarkin som inte överensstämmer med dessa regler. Följande lista är uttömmande och kommer inte att utökas i framtiden:
\n- \n
\n\n
AUTO_MERGE- \n
\n\n
BISECT_EXPECTED_REV- \n
\n\n
NOTES_MERGE_PARTIAL- \n
\n\n
NOTES_MERGE_REF- \n
\n\n
MERGE_AUTOSTASH\n\nOlika underhierarkier används för olika ändamål. Till exempel används hierarkin
\nrefs/heads/för att representera lokala grenar medan hierarkinrefs/tags/används för att representera lokala taggar.En reflogg visar den lokala \"historiken\" för en referens. Med andra ord kan den berätta vad den tredje senaste revisionen i detta repo var, och vad det aktuella läget var i detta repo, igår klockan 21:14. Se git-reflog[1] för mer information.
", + "refspec": "En \"refspec\" används av hämta (\"fetcha\") och sänd (\"pusha\") för att beskriva mappningen mellan fjärren ref och lokal referens. Se git-fetch[1] eller git-push[1] för detaljer.
", "fjärr förvar": "Ett förvar som används för att spåra samma projekt men finns någon annanstans. För att kommunicera med fjärr, se hämta eller sänd.
", "rfjärrspårade gren": "En ref som används för att följa ändringar från en annan förvar. Den ser vanligtvis ut som refs/remotes/foo/bar (vilket indikerar att den spårar en gren med namnet bar i en fjärren med namnet foo), och matchar höger sida av en konfigurerad hämtningsgren refspec. En fjärrspårningsgren bör inte innehålla direkta modifieringar eller ha lokala incheckningar gjorda till den.
", "förvar": "En samling av refs tillsammans med en objektdatabas som innehåller alla objekt som är nåbara från referenserna, eventuellt åtföljda av metadata från en eller flera porslin. Ett förvar kan dela en objektdatabas med andra arkiv via alternativs mekanismen.
", @@ -73,15 +73,15 @@ "SCM": "Källkodshantering (verktyg), också känt som Source Code Management (tool).
", "SHA-1": "\"Säker hashalgoritm 1\"; en kryptografisk hashfunktion. I Git-sammanhang används den som en synonym för objektnamn.
", "ytlig klon": "Mestadels en synonym till ytligt förvar men frasen gör det mer explicit att den skapades genom att köra kommandot
", - "ytligt förvar": "gitclone--depth=....Ett ytligt förvar har en ofullständig historik varav en del incheckning har föräldrar bränts bort (med andra ord, Git får höra att låtsas att dessa incheckningar inte har föräldrarna, trots att de är registrerade i incheckning objekt). Detta är ibland användbart när man bara är intresserad av ett projekts aktuella historik trots att den verkliga historiken som registrerats uppströms är mycket större. Ett ytligt repo skapas genom att ge
", + "ytligt förvar": "--depth-alternativet till linkgit:git-clone[1], och dess historik kan senare fördjupas med linkgit:git-fetch[1].Ett ytligt förvar har en ofullständig historik varav en del incheckning har föräldrar bränts bort (med andra ord, Git får höra att låtsas att dessa incheckningar inte har föräldrarna, trots att de är registrerade i incheckning objekt). Detta är ibland användbart när man bara är intresserad av ett projekts aktuella historik trots att den verkliga historiken som registrerats uppströms är mycket större. Ett ytligt repo skapas genom att ge
", "gömma post": "--depth-alternativet till git-clone[1], och dess historik kan senare fördjupas med git-fetch[1].En object som används för att tillfälligt lagra innehållet i en smutsig arbetskatalog och indexet för framtida återanvändning.
", "undermodul (\"submodule\")": "Ett repo som lagrar historiken för ett separat projekt inuti ett annat förvar (det senare kallas 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.
", - "symref": "Symbolisk referens: istället för att innehålla själva SHA-1-id:t, är det av formatet ref: refs/some/thing och när det refereras, avrefereras till denna referens. HEAD är ett utmärkt exempel på en symref. Symboliska referenser manipuleras med kommandot linkgit:git-symbolic-ref[1].
", + "symref": "Symbolisk referens: istället för att innehålla själva SHA-1-id:t, är det av formatet ref: refs/some/thing och när det refereras, avrefereras till denna referens. HEAD är ett utmärkt exempel på en symref. Symboliska referenser manipuleras med kommandot git-symbolic-ref[1].
", "tag": "En ref under namnrymden
", "tag objekt": "refs/tags/som pekar på ett objekt av en godtycklig typ (vanligtvis pekar en tagg på antingen ett tag eller ett inchecknings-objekt). Till skillnad från en huvud uppdateras inte en tagg avcommit-kommandot. En Git-tagg har ingenting att göra med en Lisp-tagg (som skulle kallas en objekttyp i Gits kontext). En tagg används oftast för att markera en viss punkt i commit-anor kedja.Ett objekt som innehåller ett ref som pekar på ett annat objekt, vilket kan innehålla ett meddelande precis som ett inchecknings-objekt. Det kan också innehålla en (PGP) signatur, i vilket fall det kallas ett \"signerat taggobjekt\".
", "ämnes-gren": "En vanlig Git gren som används av en utvecklare för att identifiera en konceptuell utvecklingslinje. Eftersom grenar är mycket enkla och billiga är det ofta önskvärt att ha flera små grenar som var och en innehåller mycket väldefinierade koncept eller små stegvisa men relaterade förändringar.
", - "sidfotsrader": "Nyckel-värde-metadata. Sidfotsrader finns valfritt i slutet av ett incheckning-meddelande. Kan kallas \"sidfötter\" (\"footers\") eller \"tags\" i andra gemenskaper. Se linkgit:git-interpret-trailers[1].
", + "sidfotsrader": "Nyckel-värde-metadata. Sidfotsrader finns valfritt i slutet av ett incheckning-meddelande. Kan kallas \"sidfötter\" (\"footers\") eller \"tags\" i andra gemenskaper. Se git-interpret-trailers[1].
", "träd": "Antingen ett arbetskatalog, eller ett trädobjekt tillsammans med det beroende blob och trädobjekten (dvs. en lagrad representation av ett arbetskatalog).
", "trädobjekt": "Ett objekt som innehåller en lista med filnamn och lägen tillsammans med referenser till tillhörande blob- och/eller trädobjekt. Ett träd motsvarar ett katalog.
", "trädlikt (also träd-ikt)": "Ett trädobjekt eller ett objekt som kan avrefereras rekursivt till ett trädobjekt. Att avreferera ett inchecknings-objekt ger trädobjektet som motsvarar revisions översta katalog. Följande är alla träd-liknande: ett inchecknings-aktig, ett trädobjekt, ett tag-objekt som pekar på ett trädobjekt, ett tag-objekt som pekar på ett tag-objekt som pekar på ett trädobjekt, etc.
", diff --git a/external/docs/data/glossary/uk.json b/external/docs/data/glossary/uk.json index 562377923a..e7f5c85e6f 100644 --- a/external/docs/data/glossary/uk.json +++ b/external/docs/data/glossary/uk.json @@ -23,13 +23,13 @@ "dirty": "working tree називається \"брудним\", якщо воно містить модифікації, які не були committed внесені до поточної branch.
", "злиття зла": "Злісне злиття — це merge, яке вносить зміни, що не відображаються в жодному parent.
", "перемотування вперед": "Перемотування вперед — це особливий тип merge, де у вас є revision, і ви \"зливаєте\" зміни з іншої branch, які є нащадком вашої. У такому випадку ви не створюєте новий merge commit, а просто оновлюєте свою гілку, щоб вона вказувала на ту саму ревізію, що й гілка, яку ви зливаєте. Це часто трапляється на гілці remote-tracking віддаленого repository.
", - "принести": "Отримання branch означає отримання head ref гілки з віддаленого repository, щоб знайти, які об’єкти відсутні в локальній object database, та отримати їх. Див. також linkgit:git-fetch[1].
", + "принести": "Отримання branch означає отримання head ref гілки з віддаленого repository, щоб знайти, які об’єкти відсутні в локальній object database, та отримати їх. Див. також git-fetch[1].
", "файлова система": "Лінус Торвальдс спочатку розробляв Git як файлову систему простору користувача, тобто інфраструктуру для зберігання файлів і каталогів. Це забезпечило ефективність і швидкість Git.
", "Git-архів": "Синонім до repository (для архітекторів).
", - "gitfile": "Звичайний файл
", - "трансплантати": ".gitу корені робочого дерева, який вказує на каталог, що є справжнім репозиторієм. Інструкції з правильного використання див. у linkgit:git-worktree[1] або linkgit:git-submodule[1]. Синтаксис див. у linkgit:gitrepository-layout[5].Графти дозволяють об’єднати дві інакше різні лінії розробки, записуючи фальшиву інформацію про походження для комітів. Таким чином, ви можете змусити Git вдавати, що набір parents commit відрізняється від того, що було записано під час створення коміту. Налаштовується через файл
\n.git/info/grafts.\n", + "gitfile": "Зверніть увагу, що механізм пересадки застарів і може призвести до проблем із передачею об’єктів між репозиторіями; див. linkgit:git-replace[1] для більш гнучкої та надійної системи для виконання того ж завдання.
\nЗвичайний файл
", + "трансплантати": ".gitу корені робочого дерева, який вказує на каталог, що є справжнім репозиторієм. Інструкції з правильного використання див. у git-worktree[1] або git-submodule[1]. Синтаксис див. у gitrepository-layout[5].Графти дозволяють об’єднати дві інакше різні лінії розробки, записуючи фальшиву інформацію про походження для комітів. Таким чином, ви можете змусити Git вдавати, що набір parents commit відрізняється від того, що було записано під час створення коміту. Налаштовується через файл
\n.git/info/grafts.\n", "хеш": "Зверніть увагу, що механізм пересадки застарів і може призвести до проблем із передачею об’єктів між репозиторіями; див. git-replace[1] для більш гнучкої та надійної системи для виконання того ж завдання.
\nУ контексті Git, синонім object name.
", - "голова": "Посилання іменоване на commit наприкінці branch. Заголовки зберігаються у файлі в каталозі
", + "голова": "$GIT_DIR/refs/heads/, за винятком випадків використання упакованих посилань. (Див. linkgit:git-pack-refs[1].)Посилання іменоване на commit наприкінці branch. Заголовки зберігаються у файлі в каталозі
", "ГОЛОВА": "$GIT_DIR/refs/heads/, за винятком випадків використання упакованих посилань. (Див. git-pack-refs[1].)Поточна branch. Детальніше: Ваше робоче дерево зазвичай походить від стану дерева, на яке посилається HEAD. HEAD – це посилання на один з heads у вашому репозиторії, за винятком випадків використання detached HEAD, у цьому випадку воно безпосередньо посилається на довільний коміт.
", "головний суддя": "Синонім до head.
", "гачок": "Під час звичайного виконання кількох команд Git викликаються додаткові скрипти, які дозволяють розробнику додавати функціональність або перевіряти. Зазвичай, перехоплювальні скрипти дозволяють попередньо перевірити команду та потенційно перервати її, а також дозволяють відправити повідомлення після завершення операції. Перехоплювальні скрипти знаходяться в каталозі
", @@ -48,22 +48,22 @@ "накладання": "$GIT_DIR/hooks/та активуються простим видаленням суфікса.sampleз назви файлу. У попередніх версіях Git їх потрібно було зробити виконуваними.Оновлювати та додавати файли лише до робочого каталогу, але не видаляти їх, подібно до того, як cp -R оновлює вміст у каталозі призначення. Це режим за замовчуванням у checkout під час отримання файлів з index або tree-ish. На противагу цьому, режим без накладання також видаляє відстежувані файли, яких немає у джерелі, подібно до rsync --delete.
", "пачка": "Набір об’єктів, стиснутих в один файл (для економії місця або ефективної передачі).
", "індекс пачки": "Список ідентифікаторів та іншої інформації про об’єкти в pack, що допомагає в ефективному доступі до вмісту пакета.
", - "специфікація шляху": "Шаблон, який використовується для обмеження шляхів у командах Git.
\n\n\nСпецифікації шляхів використовуються в командному рядку команд \"git ls-files\", \"git ls-tree\", \"git add\", \"git grep\", \"git diff\", \"git checkout\" та багатьох інших, щоб обмежити область дії певною підмножиною дерева або робочим деревом. Дивіться документацію кожної команди, щоб дізнатися, чи шляхи відносні до поточного каталогу чи верхнього рівня. Синтаксис специфікації шляхів такий:
\n\n\n\n\n\n\n\n
\n- \n
\nбудь-який шлях відповідає сам собі
\n- \n
\nСпецифікація шляху до останньої косої риски представляє префікс каталогу. Область дії цієї специфікації шляху обмежена цим піддеревом.
\n- \n
\nРешта специфікації шляху є шаблоном для решти імені шляху. Шляхи відносно префікса каталогу будуть зіставлені з цим шаблоном за допомогою fnmatch(3); зокрема, * та ? можуть збігатися з роздільниками каталогів.
\n\n\nНаприклад, Documentation/*.jpg відповідатиме всім файлам .jpg у піддереві Документація, включаючи Documentation/chapter_1/figure_1.jpg.
\n\n\nСпецифікація шляху, що починається з двокрапки
\n:, має спеціальне значення. У скороченій формі після початкової двокрапки:йде нуль або більше літер \"магічного підпису\" (яка необов’язково завершується ще однією двокрапкою:), а решта - це шаблон для зіставлення зі шляхом. \"Магічний підпис\" складається з символів ASCII, які не є ні буквено-цифровими, ні глобальними, ні спеціальними символами регулярних виразів, ні двокрапкою. Необов’язкова двокрапка, яка завершує \"магічний підпис\", може бути пропущена, якщо шаблон починається з символу, який не належить до набору символів \"магічного підпису\" і не є двокрапкою.\n\nУ довгій формі після двокрапки
\n:йде відкрита дужка (, список з нуля або більше «магічних слів», розділений комами, та закриваюча дужка ), а решта — це шаблон, який потрібно зіставити зі шляхом.\n\nСпецифікація шляху, що містить лише двокрапку, означає, що «специфікації шляху немає». Цю форму не слід поєднувати з іншими специфікаціями шляху.
\n\n", + "специфікація шляху": "\n\n\n\n\n
\n- верх
\n- \n
\nМагічне слово
\ntop(магічний підпис:/) забезпечує збіг зі зразком з кореня робочого дерева, навіть якщо ви виконуєте команду з підкаталогу.- буквальний
\n- \n
\nСимволи-підстановки у шаблоні, такі як
\n*або ?, обробляються як літерали.- справа
\n- \n
\nЗбіг без урахування регістру.
\n- глоб
\n- \n
\nGit трактує шаблон як глобальний об’єкт оболонки, придатний для використання fnmatch(3) з прапорцем FNM_PATHNAME: підстановлювальні символи у шаблоні не збігатимуться з / у шляху. Наприклад, \"Documentation/*.html\" відповідає \"Documentation/git.html\", але не \"Documentation/ppc/ppc.html\" або \"tools/perf/Documentation/perf.html\".
\n\n\nДві послідовні зірочки (\"**\") у шаблонах, що збігаються з повним шляхом, можуть мати спеціальне значення:
\n\n\n\n
\n- \n
\nПочатковий символ \"
\n**\", а потім скісний риса, означає збіг у всіх каталогах. Наприклад, \"**/foo\" відповідає файлу або каталогу \"foo\" будь-де. \"**/foo/bar\" відповідає файлу або каталогу \"bar\" будь-де, що знаходиться безпосередньо в каталозі \"foo\".- \n
\nЗавершальний \"
\n/**\" відповідає всьому всередині. Наприклад, \"abc/**\" відповідає всім файлам у каталозі \"abc\", відносно розташування файлу.gitignore, з нескінченною глибиною.- \n
\nСлеш-риска, за якою слідують дві послідовні зірочки, а потім ще одна скісну риска, відповідає нулю або більше каталогам. Наприклад, \"
\na/**/b\" відповідає \"a/b\", \"a/x/b\", \"a/x/y/b\" тощо.- \n
\nІнші послідовні зірочки вважаються недійсними.
\n\n\nГлобальна магія несумісна з буквальною магією.
\n- атрибут
\n- \n
\nПісля
\nattr:йде список \"вимог до атрибутів\", розділений пробілами, всі з яких мають бути виконані, щоб шлях вважався збігом; це на додаток до звичайного немагічного зіставлення зі зразком pathspec. Див. linkgit:gitattributes[5].\n\nКожен з атрибутів, що вимагаються для шляху, має одну з таких форм:
\n\n\n\n
\n- \n
\n\"
\nATTR\" вимагає, щоб атрибутATTRбув встановлений.- \n
\n\"
\n-ATTR\" вимагає, щоб атрибутATTRбув скасований.- \n
\n\"
\nATTR=VALUE\" вимагає, щоб атрибутATTRбув встановлений на рядокVALUE.- \n
\n\"
\n!ATTR\" вимагає, щоб атрибутATTRбув невказаним.\n\nЗверніть увагу, що під час зіставлення з об’єктом дерева атрибути все одно отримуються з робочого дерева, а не з заданого об’єкта дерева.
\n- виключити
\n- \n
\nПісля того, як шлях збігається з будь-якою невиключеною специфікацією шляху, він буде пропущений через усі виключені специфікації шляху (магічний підпис:
\n!або її синонім^). Якщо шлях збігається, його ігнорується. Якщо невиключеної специфікації шляху немає, виключення застосовується до результуючого набору так, ніби викликано без будь-якої специфікації шляху.Шаблон, який використовується для обмеження шляхів у командах Git.
\n\n\nСпецифікації шляхів використовуються в командному рядку команд \"git ls-files\", \"git ls-tree\", \"git add\", \"git grep\", \"git diff\", \"git checkout\" та багатьох інших, щоб обмежити область дії певною підмножиною дерева або робочим деревом. Дивіться документацію кожної команди, щоб дізнатися, чи шляхи відносні до поточного каталогу чи верхнього рівня. Синтаксис специфікації шляхів такий:
\n\n\n\n\n\n\n\n
\n- \n
\nбудь-який шлях відповідає сам собі
\n- \n
\nСпецифікація шляху до останньої косої риски представляє префікс каталогу. Область дії цієї специфікації шляху обмежена цим піддеревом.
\n- \n
\nРешта специфікації шляху є шаблоном для решти імені шляху. Шляхи відносно префікса каталогу будуть зіставлені з цим шаблоном за допомогою fnmatch(3); зокрема, * та ? можуть збігатися з роздільниками каталогів.
\n\n\nНаприклад, Documentation/*.jpg відповідатиме всім файлам .jpg у піддереві Документація, включаючи Documentation/chapter_1/figure_1.jpg.
\n\n\nСпецифікація шляху, що починається з двокрапки
\n:, має спеціальне значення. У скороченій формі після початкової двокрапки:йде нуль або більше літер \"магічного підпису\" (яка необов’язково завершується ще однією двокрапкою:), а решта - це шаблон для зіставлення зі шляхом. \"Магічний підпис\" складається з символів ASCII, які не є ні буквено-цифровими, ні глобальними, ні спеціальними символами регулярних виразів, ні двокрапкою. Необов’язкова двокрапка, яка завершує \"магічний підпис\", може бути пропущена, якщо шаблон починається з символу, який не належить до набору символів \"магічного підпису\" і не є двокрапкою.\n\nУ довгій формі після двокрапки
\n:йде відкрита дужка (, список з нуля або більше «магічних слів», розділений комами, та закриваюча дужка ), а решта — це шаблон, який потрібно зіставити зі шляхом.\n\nСпецифікація шляху, що містить лише двокрапку, означає, що «специфікації шляху немає». Цю форму не слід поєднувати з іншими специфікаціями шляху.
\n\n", "батько": "\n\n\n\n\n
\n- верх
\n- \n
\nМагічне слово
\ntop(магічний підпис:/) забезпечує збіг зі зразком з кореня робочого дерева, навіть якщо ви виконуєте команду з підкаталогу.- буквальний
\n- \n
\nСимволи-підстановки у шаблоні, такі як
\n*або ?, обробляються як літерали.- справа
\n- \n
\nЗбіг без урахування регістру.
\n- глоб
\n- \n
\nGit трактує шаблон як глобальний об’єкт оболонки, придатний для використання fnmatch(3) з прапорцем FNM_PATHNAME: підстановлювальні символи у шаблоні не збігатимуться з / у шляху. Наприклад, \"Documentation/*.html\" відповідає \"Documentation/git.html\", але не \"Documentation/ppc/ppc.html\" або \"tools/perf/Documentation/perf.html\".
\n\n\nДві послідовні зірочки (\"**\") у шаблонах, що збігаються з повним шляхом, можуть мати спеціальне значення:
\n\n\n\n
\n- \n
\nПочатковий символ \"
\n**\", а потім скісний риса, означає збіг у всіх каталогах. Наприклад, \"**/foo\" відповідає файлу або каталогу \"foo\" будь-де. \"**/foo/bar\" відповідає файлу або каталогу \"bar\" будь-де, що знаходиться безпосередньо в каталозі \"foo\".- \n
\nЗавершальний \"
\n/**\" відповідає всьому всередині. Наприклад, \"abc/**\" відповідає всім файлам у каталозі \"abc\", відносно розташування файлу.gitignore, з нескінченною глибиною.- \n
\nСлеш-риска, за якою слідують дві послідовні зірочки, а потім ще одна скісну риска, відповідає нулю або більше каталогам. Наприклад, \"
\na/**/b\" відповідає \"a/b\", \"a/x/b\", \"a/x/y/b\" тощо.- \n
\nІнші послідовні зірочки вважаються недійсними.
\n\n\nГлобальна магія несумісна з буквальною магією.
\n- атрибут
\n- \n
\nПісля
\nattr:йде список \"вимог до атрибутів\", розділений пробілами, всі з яких мають бути виконані, щоб шлях вважався збігом; це на додаток до звичайного немагічного зіставлення зі зразком pathspec. Див. gitattributes[5].\n\nКожен з атрибутів, що вимагаються для шляху, має одну з таких форм:
\n\n\n\n
\n- \n
\n\"
\nATTR\" вимагає, щоб атрибутATTRбув встановлений.- \n
\n\"
\n-ATTR\" вимагає, щоб атрибутATTRбув скасований.- \n
\n\"
\nATTR=VALUE\" вимагає, щоб атрибутATTRбув встановлений на рядокVALUE.- \n
\n\"
\n!ATTR\" вимагає, щоб атрибутATTRбув невказаним.\n\nЗверніть увагу, що під час зіставлення з об’єктом дерева атрибути все одно отримуються з робочого дерева, а не з заданого об’єкта дерева.
\n- виключити
\n- \n
\nПісля того, як шлях збігається з будь-якою невиключеною специфікацією шляху, він буде пропущений через усі виключені специфікації шляху (магічний підпис:
\n!або її синонім^). Якщо шлях збігається, його ігнорується. Якщо невиключеної специфікації шляху немає, виключення застосовується до результуючого набору так, ніби викликано без будь-якої специфікації шляху.Об’єкт commit містить (можливо, порожній) список логічних попередників у лінії розробки, тобто його батьків.
", "шкірка": "Дія рекурсивного виконання dereferencing об’єкта tag.
", - "кирка": "Термін pickaxe стосується опції процедур diffcore, які допомагають вибирати зміни, що додають або видаляють заданий текстовий рядок. За допомогою опції
", + "кирка": "--pickaxe-allїї можна використовувати для перегляду повного changeset, який додав або видалив, скажімо, певний рядок тексту. Див. linkgit:git-diff[1].Термін pickaxe стосується опції процедур diffcore, які допомагають вибирати зміни, що додають або видаляють заданий текстовий рядок. За допомогою опції
", "сантехніка": "--pickaxe-allїї можна використовувати для перегляду повного changeset, який додав або видалив, скажімо, певний рядок тексту. Див. git-diff[1].Миле ім’я для core Git.
", "порцеляна": "Миле ім’я для програм та пакетів програм, що залежать від core Git, що забезпечує високорівневий доступ до ядра Git. Порцелянові елементи надають більше інтерфейсу SCM, ніж plumbing.
", "посилання на робоче дерево": "Посилання, що є per-worktree, а не глобальними. Наразі це лише HEAD та будь-які посилання, що починаються з
", - "псевдопосилання": "refs/bisect/, але пізніше можуть включати інші незвичайні посилання.Посилання, яке має іншу семантику, ніж звичайні посилання. Ці посилання можна зчитувати за допомогою звичайних команд Git, але не можна записувати в них за допомогою команд, таких як linkgit:git-update-ref[1].
\n\n\nGit відомі такі псевдопосилання:
\n\n", - "тягнути": "\n
\n- \n
\n\n
FETCH_HEADзаписується за допомогою linkgit:git-fetch[1] або linkgit:git-pull[1]. Він може посилатися на кілька ідентифікаторів об’єктів. Кожен ідентифікатор об’єкта анотується метаданими, що вказують, звідки його було отримано, та його статус отримання.- \n
\n\n
MERGE_HEADзаписується командою linkgit:git-merge[1] під час вирішення конфліктів злиття. Він містить усі ідентифікатори комітів, які об’єднуються.Витягування branch означає виконання fetch та merge її. Див. також linkgit:git-pull[1].
", + "псевдопосилання": "Посилання, яке має іншу семантику, ніж звичайні посилання. Ці посилання можна зчитувати за допомогою звичайних команд Git, але не можна записувати в них за допомогою команд, таких як git-update-ref[1].
\n\n\nGit відомі такі псевдопосилання:
\n\n", + "тягнути": "\n
\n- \n
\n\n
FETCH_HEADзаписується за допомогою git-fetch[1] або git-pull[1]. Він може посилатися на кілька ідентифікаторів об’єктів. Кожен ідентифікатор об’єкта анотується метаданими, що вказують, звідки його було отримано, та його статус отримання.- \n
\n\n
MERGE_HEADзаписується командою git-merge[1] під час вирішення конфліктів злиття. Він містить усі ідентифікатори комітів, які об’єднуються.Витягування branch означає виконання fetch та merge її. Див. також git-pull[1].
", "штовхати": "Надсилання branch означає отримання head ref гілки з віддаленого repository, з’ясування, чи є вона предком локального head ref гілки, і в цьому випадку поміщення всіх об’єктів, які є reachable з локального head ref та які відсутні у віддаленому репозиторії, до віддаленої object database та оновлення віддаленого head ref. Якщо віддалений head не є предком локального head, надсилання завершується невдачею.
", "досяжний": "Усі предки заданого commit називаються \"досяжними\" з цього коміту. У більш загальному випадку, один object є досяжним з іншого, якщо ми можемо досягти одного з іншого за допомогою chain, який йде після tags до будь-якого їхнього тегу, commits до їхніх батьківських об’єктів або дерев, та trees до дерев або blobs, які вони містять.
", "бітові карти досяжності": "Бітові карти досяжності зберігають інформацію про reachability вибраного набору комітів у пакетному файлі або індексі мультипаків (MIDX) для пришвидшення пошуку об’єктів. Бітові карти зберігаються у файлі \".bitmap\". Репозиторій може використовувати щонайбільше один файл бітових карт. Файл бітових карт може належати або до одного пакету, або до індексу мультипаків репозиторію (якщо він існує).
", "лисиця": "Щоб повторно застосувати серію змін з branch до іншої бази та скинути head цієї гілки до результату.
", - "посилання": "Ім’я, що вказує на ім’я об’єкта або інше посилання (останнє називається символічне посилання). Для зручності посилання іноді можна скорочувати, коли воно використовується як аргумент команди Git; див. linkgit:gitrevisions[7] для отримання детальної інформації. Посилання зберігаються в репозиторії.
\n\n\nПростір імен посилань є ієрархічним. Імена посилань повинні починатися з
\nrefs/або розташовуватися в корені ієрархії. Для останнього їх імена повинні відповідати таким правилам:\n", - "повторно заповнити": "\n
\n- \n
\nІм’я складається лише з символів верхнього регістру або символів підкреслення.
\n- \n
\nІм’я закінчується на \"
\n_HEAD\" або дорівнює \"HEAD\".\n\nУ корені ієрархії є деякі нерегулярні посилання, які не відповідають цим правилам. Наведений нижче список є вичерпним і не буде розширюватися в майбутньому:
\n- \n
\n\n
AUTO_MERGE- \n
\n\n
BISECT_EXPECTED_REV- \n
\n\n
NOTES_MERGE_PARTIAL- \n
\n\n
NOTES_MERGE_REF- \n
\n\n
MERGE_AUTOSTASH\n\nРізні підієрархії використовуються для різних цілей. Наприклад, ієрархія
\nrefs/heads/використовується для представлення локальних гілок, тоді як ієрархіяrefs/tags/використовується для представлення локальних тегів.Reflog показує локальну «історію» посилання. Іншими словами, він може повідомити вам, якою була третя остання ревізія в this репозиторії та який був поточний стан у this репозиторії вчора о 21:14. Див. linkgit:git-reflog[1] для отримання детальної інформації.
", - "специфікація посилання": "\"Refspec\" використовується fetch та push для опису відповідності між віддаленим ref та локальним посиланням. Див. linkgit:git-fetch[1] або linkgit:git-push[1] для отримання детальної інформації.
", + "посилання": "Ім’я, що вказує на ім’я об’єкта або інше посилання (останнє називається символічне посилання). Для зручності посилання іноді можна скорочувати, коли воно використовується як аргумент команди Git; див. gitrevisions[7] для отримання детальної інформації. Посилання зберігаються в репозиторії.
\n\n\nПростір імен посилань є ієрархічним. Імена посилань повинні починатися з
\nrefs/або розташовуватися в корені ієрархії. Для останнього їх імена повинні відповідати таким правилам:\n", + "повторно заповнити": "\n
\n- \n
\nІм’я складається лише з символів верхнього регістру або символів підкреслення.
\n- \n
\nІм’я закінчується на \"
\n_HEAD\" або дорівнює \"HEAD\".\n\nУ корені ієрархії є деякі нерегулярні посилання, які не відповідають цим правилам. Наведений нижче список є вичерпним і не буде розширюватися в майбутньому:
\n- \n
\n\n
AUTO_MERGE- \n
\n\n
BISECT_EXPECTED_REV- \n
\n\n
NOTES_MERGE_PARTIAL- \n
\n\n
NOTES_MERGE_REF- \n
\n\n
MERGE_AUTOSTASH\n\nРізні підієрархії використовуються для різних цілей. Наприклад, ієрархія
\nrefs/heads/використовується для представлення локальних гілок, тоді як ієрархіяrefs/tags/використовується для представлення локальних тегів.Reflog показує локальну «історію» посилання. Іншими словами, він може повідомити вам, якою була третя остання ревізія в this репозиторії та який був поточний стан у this репозиторії вчора о 21:14. Див. git-reflog[1] для отримання детальної інформації.
", + "специфікація посилання": "\"Refspec\" використовується fetch та push для опису відповідності між віддаленим ref та локальним посиланням. Див. git-fetch[1] або git-push[1] для отримання детальної інформації.
", "віддаленого сховища": "Об’єкт repository, який використовується для відстеження того самого проєкту, але знаходиться деінде. Щоб зв’язатися з віддаленими серверами, див. fetch або push.
", "гілка віддаленого відстеження": "Гілка ref, яка використовується для відстеження змін з іншого repository. Зазвичай вона виглядає як refs/remotes/foo/bar (що вказує на те, що вона відстежує гілку з назвою bar у віддаленому репозиторії з назвою foo) та відповідає правій частині налаштованого fetch refspec. Гілка з віддаленим відстеженням не повинна містити прямих модифікацій або локальних комітів.
", "сховище": "Колекція refs разом з object базою даних, що містить усі об’єкти, які є reachable з посилань, можливо, супроводжувані метаданими з одного або кількох porcelains. Репозиторій може спільно використовувати базу даних об’єктів з іншими репозиторіями через механізм alternates.
", @@ -73,15 +73,15 @@ "SCM": "Управління вихідним кодом (інструмент).
", "SHA-1": "\"Secure Hash Algorithm 1\"; криптографічна хеш-функція. У контексті Git використовується як синонім object name.
", "поверхневий клон": "Здебільшого синонім shallow repository, але ця фраза чіткіше вказує на те, що його було створено за допомогою команди
", - "неглибоке сховище": "gitclone--depth=....Неглибокий repository має неповну історію, деякі з commits якої parents знищені (іншими словами, Git має вдати, що ці коміти не мають батьківських комітів, навіть якщо вони записані в commit object). Це іноді корисно, коли вас цікавить лише недавня історія проекту, хоча реальна історія, записана в апстрімі, набагато більша. Неглибокий репозиторій створюється шляхом надання опції
", + "неглибоке сховище": "--depthдля linkgit:git-clone[1], а його історію пізніше можна поглибити за допомогою linkgit:git-fetch[1].Неглибокий repository має неповну історію, деякі з commits якої parents знищені (іншими словами, Git має вдати, що ці коміти не мають батьківських комітів, навіть якщо вони записані в commit object). Це іноді корисно, коли вас цікавить лише недавня історія проекту, хоча реальна історія, записана в апстрімі, набагато більша. Неглибокий репозиторій створюється шляхом надання опції
", "запис у сховищі": "--depthдля git-clone[1], а його історію пізніше можна поглибити за допомогою git-fetch[1].Об’єкт object використовується для тимчасового зберігання вмісту робочого каталогу dirty та індексу для подальшого використання.
", "підмодуль": "Об’єкт repository, що містить історію окремого проєкту всередині іншого репозиторію (останній називається superproject).
", "суперпроект": "Об’єкт repository, який посилається на репозиторії інших проектів у своєму робочому дереві як submodules. Суперпроект знає про назви (але не містить копій) об’єктів комітів підмодулів, що містяться в ньому.
", - "симреф": "Символічне посилання: замість того, щоб містити сам ідентифікатор SHA-1, воно має формат ref: refs/some/thing, і під час посилання воно рекурсивно dereferences переходить до цього посилання. HEAD є яскравим прикладом символічного посилання. Символьні посилання маніпулюють командою linkgit:git-symbolic-ref[1].
", + "симреф": "Символічне посилання: замість того, щоб містити сам ідентифікатор SHA-1, воно має формат ref: refs/some/thing, і під час посилання воно рекурсивно dereferences переходить до цього посилання. HEAD є яскравим прикладом символічного посилання. Символьні посилання маніпулюють командою git-symbolic-ref[1].
", "тег": "Об’єкт ref у просторі імен
", "об’єкт тегу": "refs/tags/, який вказує на об’єкт довільного типу (зазвичай тег вказує або на tag, або на commit об’єкт). На відміну від head, тег не оновлюється командоюcommit. Тег Git не має нічого спільного з тегом Lisp (який у контексті Git називався б object type). Тег найчастіше використовується для позначення певної точки в походженні комітів chain.Об’єкт object, що містить ref, що вказує на інший об’єкт, який може містити повідомлення, як і об’єкт commit. Він також може містити підпис (PGP), і в цьому випадку він називається \"підписаним об’єктом тегу\".
", "тематична гілка": "Звичайний Git branch, який використовується розробником для визначення концептуальної лінії розробки. Оскільки гілки дуже прості та недорогі, часто бажано мати кілька невеликих гілок, кожна з яких містить дуже чітко визначені концепції або невеликі інкрементальні, але пов’язані зміни.
", - "трейлер": "Метадані ключ-значення. Трейлери необов’язково знаходяться в кінці повідомлення коміту. В інших спільнотах можуть називатися \"футерами\" або \"тегами\". Див. linkgit:git-interpret-trailers[1].
", + "трейлер": "Метадані ключ-значення. Трейлери необов’язково знаходяться в кінці повідомлення коміту. В інших спільнотах можуть називатися \"футерами\" або \"тегами\". Див. git-interpret-trailers[1].
", "дерево": "Або working tree, або tree object разом із залежними об’єктами blob та tree (тобто збережене представлення робочого дерева).
", "деревоподібний об’єкт": "Об’єкт object, що містить список імен файлів та режимів, а також посилання на пов’язані блоб-об’єкти та/або деревоподібні об’єкти. tree еквівалентний directory.
", "деревоподібний (також деревоподібний)": "Об’єкт tree або object, який можна рекурсивно dereference перенести на об’єкт дерева. Розіменування об’єкта commit повертає об’єкт дерева, що відповідає верхньому directory об’єкта revision. Наступні об’єкти є деревоподібними: commit-подібний, об’єкт дерева, об’єкт tag, що вказує на об’єкт дерева, об’єкт tag, що вказує на об’єкт tag, що вказує на об’єкт дерева тощо.
", diff --git a/external/docs/data/glossary/zh_HANS-CN.json b/external/docs/data/glossary/zh_HANS-CN.json index c6124b01cb..8efefac22c 100644 --- a/external/docs/data/glossary/zh_HANS-CN.json +++ b/external/docs/data/glossary/zh_HANS-CN.json @@ -23,13 +23,13 @@ "脏（的工作区）(dirty)": "如果工作区包含的修改没有被提交到当前的分支，就被认为是 \"dirty（脏）\" 的。
", "坏合并（合并引入了父提交没有的修改）(evil merge)": "", "快速合并": "快速合并是合并的一种特殊类型，即你有一个版本而你正在“合并”另一个分支的修改，这些修改恰好是你的后续提交。在这种情况下，你不需要添加一个新的合并 提交而只是更新你的分支，使其指向与你要合并的分支相同的版本。这种情况会经常发生在一个远程远程跟踪分支的仓库。
", - "获取(fetch)": "获取一个分支意味着从远程仓库获取该分支的头引用，找出本地对象库中缺失的对象，并获取这些对象。另见 linkgit:git-fetch[1]。
", + "获取(fetch)": "获取一个分支意味着从远程仓库获取该分支的头引用，找出本地对象库中缺失的对象，并获取这些对象。另见 git-fetch[1]。
", "文件系统": "Linus Torvalds （林纳斯·本纳第克特·托瓦兹；Git的作者、Linux之父）最初将 Git 设计为用户空间文件系统，即用于保存文件和目录的基础结构。这确保了 Git 的效率和速度。
", "仓库（对于 arch 用户）(Git archive)": "与仓库 同义(对于arch用户)。
", - "gitfile（仓库链接文件）": "工作目录树根目录下的普通文件
", - "（提交）移植(grafts)": ".git，指向真正的仓库目录。正确用法参见 linkgit:git-worktree[1] 或 linkgit:git-submodule[1]。语法参见 linkgit:gitrepository-layout[5]。移植（Grafts）通过记录提交的虚假祖先信息，使两条原本不同的开发线连接在一起。这样你就可以让 Git 假装提交的一组父提交与创建提交 (commit) 时的记录不同。通过
\n.git/info/grafts文件进行配置。\n", + "gitfile（仓库链接文件）": "请注意，移植 (Grafts) 机制已经过时了，可能会导致在仓库之间转移对象的问题；参见 linkgit:git-replace[1] ，这是一个更灵活更强大的系统，可以做同样的事情。
\n工作目录树根目录下的普通文件
", + "（提交）移植(grafts)": ".git，指向真正的仓库目录。正确用法参见 git-worktree[1] 或 git-submodule[1]。语法参见 gitrepository-layout[5]。移植（Grafts）通过记录提交的虚假祖先信息，使两条原本不同的开发线连接在一起。这样你就可以让 Git 假装提交的一组父提交与创建提交 (commit) 时的记录不同。通过
\n.git/info/grafts文件进行配置。\n", "哈希（hash）": "请注意，移植 (Grafts) 机制已经过时了，可能会导致在仓库之间转移对象的问题；参见 git-replace[1] ，这是一个更灵活更强大的系统，可以做同样的事情。
\n在 Git 的上下文中，是对象名称的同义词。
", - "头/分支(head)": "一个命名引用到提交在分支的顶端。头部存储在
", + "头/分支(head)": "$GIT_DIR/refs/heads/目录下的一个文件中，除非使用打包的引用（参见 linkgit:git-pack-refs[1]。）一个命名引用到提交在分支的顶端。头部存储在
", "HEAD（头指针，亦即当前分支）": "$GIT_DIR/refs/heads/目录下的一个文件中，除非使用打包的引用（参见 git-pack-refs[1]。）当前分支。详细地讲，你的工作区通常是由 HEAD 所指的树的状态衍生出来的。HEAD 是对你的版本库中的一个头的引用，除非使用分离的 HEAD，这种情况下它直接引用一个任意的提交。
", "头引用": "头的同义词。
", "钩子": "在几个 Git 命令的正常执行过程中，会对可选的脚本进行调用，允许开发者添加功能或检查。通常情况下，钩子允许一个命令被预先验证并可能中止执行，并允许在操作完成后发出通知。钩子脚本可以在
", @@ -48,22 +48,22 @@ "覆盖 (overlay)": "$GIT_DIR/hooks/目录下找到，只需将文件名中的.sample后缀去掉即可启用。在早期版本的 Git 中，你必须将它们设置为可执行。只更新和添加文件到工作目录，但不删除它们，类似于 cp -R 会更新目标目录中的内容。这是检出中的默认模式，当从暂存区或树状标识中检出文件时。相反，非覆盖模式也会删除源文件中不存在的跟踪文件，类似于 rsync --delete。
", "包 (pack)": "一组被压缩成一个文件的对象（以节省空间或有效传输）。
", "包索引 (pack index)": "包中的对象的标识符和其他信息的列表，以协助有效地访问一个包的内容。
", - "路径规范 (pathspec)": "用来限制 Git 命令中的路径的模式。
\n\n\n在 \"git ls-files\"、\"git ls-tree\"、\"git add\"、\"git grep\"、\"git diff\"、\"git checkout\" 和许多其他命令的命令行中，路径规格被用来将操作范围限制在树或工作区的某个子集。 关于路径是相对于当前目录还是顶层，请参阅每个命令的文档。 路径规范的语法如下：
\n\n\n\n\n\n\n\n
\n- \n
\n任何路径都与自己匹配
\n- \n
\n到最后一个斜线的路径规范代表一个目录前缀。 该路径规范的范围只限于该子树。
\n- \n
\n路径规范的其余部分是路径名其余部分的模式。 相对于目录前缀的路径将使用fnmatch(3)（匹配函数）与该模式进行匹配；特别是，* 和 ? 可以 匹配目录分隔符。
\n\n\n例如，Documentation/*.jpg 将匹配 Documentation 子目录中的所有 .jpg 文件，包括 Documentation/chapter_1/figure_1.jpg。
\n\n\n以冒号
\n:开头的路径规范有特殊含义。 在简短的形式中，前面的冒号:后面是 0 个或更多的 “魔术签名(magic signature)”（可以选择以另一个冒号:结束），剩下的部分是与路径匹配的模式。 “魔术签名” 由ASCII符号组成，这些符号既不是字母数字、通配符、正则表达式特殊字符也不是冒号。 如果模式以不属于 “魔术签名” 符号集的字符开始，并且不是冒号，那么结束 “魔术签名” 的可选冒号就可以省略。\n\n在较长规范中，前面的冒号
\n:后面是一个开放的小括号 (，一个用逗号分隔的 0 个或多个 “魔术单词” 列表，以及一个封闭的小括号 )，其余部分是要与路径匹配的模式。\n\n一个只有冒号的路径规范意味着 “不使用路径规范”。这种形式不应该与其他路径规范结合。
\n\n", + "路径规范 (pathspec)": "\n\n\n\n\n
\n- 顶部 (top)
\n- \n
\n魔术词
\ntop（魔术签名：/）使模式从工作区的根目录开始匹配，即使你从子目录内运行命令。- 字面量 (literal)
\n- \n
\n模式中的通配符，如
\n*或 ? 被视为字面量字符。- 不敏感匹配 (icase)
\n- \n
\n不区分大小写的匹配。
\n- 通配符
\n- \n
\nGit 将模式视为适合 fnmatch(3)（匹配函数）使用 shell 的通配符模式（shell 所使用的简化了的正则表达式），带有FNM_PATHNAME 标志：模式中的通配符将不匹配路径名中的 /（即不对子目录或上级目录进行匹配）。例如，\"Documentation/*.html\" 匹配 \"Documentation/git.html\"，而不是 \"Documentation/ppc/ppc.html\" 或 \"tools/perf/Documentation/perf.html\"。
\n\n\n在与全路径名匹配的模式中，两个连续的星号（\"
\n**\"）可能有特殊含义：\n\n\n
\n- \n
\n\"
\n**\"在带斜杠目录之前，表示在所有目录中匹配。例如，\"**/foo\"匹配任何文件或目录的\"foo\"。\"**/foo/bar\"匹配任何文件或目录中直接位于目录\"foo\"之下的\"bar\"。- \n
\n路径后跟有 \"
\n/**\" 表示匹配这个目录里面的所有文件。例如，\"abc/**\" 匹配相对于.gitignore文件的位置中目录 \"abc \"内的所有文件，深度无限。- \n
\n一个斜杠后面是两个连续的星号再接上一个斜杠，匹配零个或多个目录。例如，\"
\na/**/b\" 匹配 \"a/b\"、\"a/x/b\"、\"a/x/y/b\"，等等，依此类推。- \n
\n其他连续的星号是无效的。
\n\n\n通配符魔术词 (glob) 与字面量魔术词 (literal) 是不相容的。
\n- 属性匹配
\n- \n
\n在
\nattr:之后是一个空格分隔的 “属性要求” 列表，所有这些都必须满足才能被认为是匹配的路径;这是在通常的非魔法路径规范模式匹配之外的。参见 linkgit:gitattributes[5]。\n\n以下包含了路径的每个属性要求：
\n\n\n\n
\n- \n
\n\"
\nATTR\" 表示要求设置ATTR属性。- \n
\n\"
\n-ATTR\" 要求属性ATTR没有被设置。- \n
\n\"
\nATTR=VALUE\" 要求将属性ATTR设置为字符串VALUE。- \n
\n\"
\n!ATTR\" 要求属性ATTR是未指定的。\n\n注意，当与树对象进行匹配时，属性仍然是从工作区中获得的，而不是从给定的树对象中获得。
\n- 排除匹配 (exclude)
\n- \n
\n当一个路径匹配了任何规则之外的 (non-exclude) 路径规范后，它将遍历所有的排除性路径规范（魔术签名：
\n!或其同义词^）。如果匹配，该路径将被忽略。 当没有规则之外路径规范时，排除法将应用于结果集，就像在没有任何路径规范的情况下调用。用来限制 Git 命令中的路径的模式。
\n\n\n在 \"git ls-files\"、\"git ls-tree\"、\"git add\"、\"git grep\"、\"git diff\"、\"git checkout\" 和许多其他命令的命令行中，路径规格被用来将操作范围限制在树或工作区的某个子集。 关于路径是相对于当前目录还是顶层，请参阅每个命令的文档。 路径规范的语法如下：
\n\n\n\n\n\n\n\n
\n- \n
\n任何路径都与自己匹配
\n- \n
\n到最后一个斜线的路径规范代表一个目录前缀。 该路径规范的范围只限于该子树。
\n- \n
\n路径规范的其余部分是路径名其余部分的模式。 相对于目录前缀的路径将使用fnmatch(3)（匹配函数）与该模式进行匹配；特别是，* 和 ? 可以 匹配目录分隔符。
\n\n\n例如，Documentation/*.jpg 将匹配 Documentation 子目录中的所有 .jpg 文件，包括 Documentation/chapter_1/figure_1.jpg。
\n\n\n以冒号
\n:开头的路径规范有特殊含义。 在简短的形式中，前面的冒号:后面是 0 个或更多的 “魔术签名(magic signature)”（可以选择以另一个冒号:结束），剩下的部分是与路径匹配的模式。 “魔术签名” 由ASCII符号组成，这些符号既不是字母数字、通配符、正则表达式特殊字符也不是冒号。 如果模式以不属于 “魔术签名” 符号集的字符开始，并且不是冒号，那么结束 “魔术签名” 的可选冒号就可以省略。\n\n在较长规范中，前面的冒号
\n:后面是一个开放的小括号 (，一个用逗号分隔的 0 个或多个 “魔术单词” 列表，以及一个封闭的小括号 )，其余部分是要与路径匹配的模式。\n\n一个只有冒号的路径规范意味着 “不使用路径规范”。这种形式不应该与其他路径规范结合。
\n\n", "父提交 (parent)": "\n\n\n\n\n
\n- 顶部 (top)
\n- \n
\n魔术词
\ntop（魔术签名：/）使模式从工作区的根目录开始匹配，即使你从子目录内运行命令。- 字面量 (literal)
\n- \n
\n模式中的通配符，如
\n*或 ? 被视为字面量字符。- 不敏感匹配 (icase)
\n- \n
\n不区分大小写的匹配。
\n- 通配符
\n- \n
\nGit 将模式视为适合 fnmatch(3)（匹配函数）使用 shell 的通配符模式（shell 所使用的简化了的正则表达式），带有FNM_PATHNAME 标志：模式中的通配符将不匹配路径名中的 /（即不对子目录或上级目录进行匹配）。例如，\"Documentation/*.html\" 匹配 \"Documentation/git.html\"，而不是 \"Documentation/ppc/ppc.html\" 或 \"tools/perf/Documentation/perf.html\"。
\n\n\n在与全路径名匹配的模式中，两个连续的星号（\"
\n**\"）可能有特殊含义：\n\n\n
\n- \n
\n\"
\n**\"在带斜杠目录之前，表示在所有目录中匹配。例如，\"**/foo\"匹配任何文件或目录的\"foo\"。\"**/foo/bar\"匹配任何文件或目录中直接位于目录\"foo\"之下的\"bar\"。- \n
\n路径后跟有 \"
\n/**\" 表示匹配这个目录里面的所有文件。例如，\"abc/**\" 匹配相对于.gitignore文件的位置中目录 \"abc \"内的所有文件，深度无限。- \n
\n一个斜杠后面是两个连续的星号再接上一个斜杠，匹配零个或多个目录。例如，\"
\na/**/b\" 匹配 \"a/b\"、\"a/x/b\"、\"a/x/y/b\"，等等，依此类推。- \n
\n其他连续的星号是无效的。
\n\n\n通配符魔术词 (glob) 与字面量魔术词 (literal) 是不相容的。
\n- 属性匹配
\n- \n
\n在
\nattr:之后是一个空格分隔的 “属性要求” 列表，所有这些都必须满足才能被认为是匹配的路径;这是在通常的非魔法路径规范模式匹配之外的。参见 gitattributes[5]。\n\n以下包含了路径的每个属性要求：
\n\n\n\n
\n- \n
\n\"
\nATTR\" 表示要求设置ATTR属性。- \n
\n\"
\n-ATTR\" 要求属性ATTR没有被设置。- \n
\n\"
\nATTR=VALUE\" 要求将属性ATTR设置为字符串VALUE。- \n
\n\"
\n!ATTR\" 要求属性ATTR是未指定的。\n\n注意，当与树对象进行匹配时，属性仍然是从工作区中获得的，而不是从给定的树对象中获得。
\n- 排除匹配 (exclude)
\n- \n
\n当一个路径匹配了任何规则之外的 (non-exclude) 路径规范后，它将遍历所有的排除性路径规范（魔术签名：
\n!或其同义词^）。如果匹配，该路径将被忽略。 当没有规则之外路径规范时，排除法将应用于结果集，就像在没有任何路径规范的情况下调用。一个提交对象包含一个开发中的逻辑前驱列表（可能是空的），即其父提交。
", "剥离 (peel)": "", - "挖掘 (pickaxe)": "术语挖掘指的是 diff 核心例程 (diffcore) 的一个选项，辅助选择增加或删除特定文本字符串的变化。通过
", + "挖掘 (pickaxe)": "--pickaxe-all选项，它可以用来查看引入或删除的全部变更集，例如某一行文字。参见 linkgit:git-diff[1]。术语挖掘指的是 diff 核心例程 (diffcore) 的一个选项，辅助选择增加或删除特定文本字符串的变化。通过
", "管件 (plumbing)": "--pickaxe-all选项，它可以用来查看引入或删除的全部变更集，例如某一行文字。参见 git-diff[1]。Git 核心的昵称。
", "瓷件 (porcelain)": "依靠Git 核心的程序和程序套件的昵称，是对Git核心上层封装。与管件相比，瓷件暴露了更多 SCM 接口。
", "工作区引用(per-worktree ref)": "相比于全局引用，它是对每个工作区的引用。 目前只有 HEAD 和任何以
", - "伪引用 (pseudoref)": "refs/bisect/开头的引用，但以后可能包括其他不寻常的引用。语义不同于普通引用的引用。这些引用可以通过正常的 Git 命令访问，但在某些情况下可能与正常引用的行为不同，例如linkgit:git-update-ref[1]。
\n\n\nGit 已知的伪引用如下：
\n\n", - "拉取 (pull)": "\n
\n- \n
\n\n
FETCH_HEAD由 linkgit:git-fetch[1] 或 linkgit:git-pull[1] 写入。它可以指向多个对象 ID。每个对象 ID 都有元数据注释，说明其取自何处以及取回状态。- \n
\nlinkgit:git-merge[1] 在解决合并冲突时会写入
\nMERGE_HEAD。它包含所有正在合并的提交 ID。拉取一个分支意味着获取一个分支并且合并这个分支。 另见 linkgit:git-pull[1]。
", + "伪引用 (pseudoref)": "语义不同于普通引用的引用。这些引用可以通过正常的 Git 命令访问，但在某些情况下可能与正常引用的行为不同，例如git-update-ref[1]。
\n\n\nGit 已知的伪引用如下：
\n\n", + "拉取 (pull)": "\n
\n- \n
\n\n
FETCH_HEAD由 git-fetch[1] 或 git-pull[1] 写入。它可以指向多个对象 ID。每个对象 ID 都有元数据注释，说明其取自何处以及取回状态。- \n
\ngit-merge[1] 在解决合并冲突时会写入
\nMERGE_HEAD。它包含所有正在合并的提交 ID。拉取一个分支意味着获取一个分支并且合并这个分支。 另见 git-pull[1]。
", "推送 (push)": "推送一个分支意味着从远程的仓库获取该分支的头引用，找出它是否是该分支的本地分支引用的一个祖先。在这种情况下，将所有从本地分支引用可达的对象，以及从远程仓库中丢失的对象，放入远程对象库，并更新远程分支引用。如果远程头/分支不是本地分支的祖先，则推送失败。
", "可达的 (reachable)": "一个给定的提交的所有祖先都被称为可以从该提交 “到达”。更一般地说，如果一个对象可以通过对象链从一个标签到达任意一个对象链标记的标签，那么该对象就是可达的，提交到它们的父提交或树，以及树到它们所包含的树或二进制对象。
", "可达性位图": "可达性位图存储了包文件或多包索引（MIDX）中选定的一组提交的可达性的信息，以加快对象搜索。 位图被存储在 \".bitmap\" 文件中。一个仓库最多可以有一个位图文件在使用。这个位图文件可以属于一个包，也可以属于仓库的多包索引（如果有的话）。
", "变基 (rebase)": "将分支的一系列修改重新应用于不同的分支上，并将头指针重置为该分支。
", - "引用 (ref)": "一个指向对象名称或另一个引用（后者被称为符号引用）的名称。 为方便起见，当作为 Git 命令的参数时，引用可以使用缩写；参见 linkgit:gitrevisions[7] 。 引用保存在仓库中。
\n\n\n引用名称空间是分层的。引用名称必须以
\nrefs/开头，或者位于层次结构的根目录中。对于后者，它们的名称必须遵循以下规则：\n", - "引用日志 (reflog)": "\n
\n- \n
\n名称仅由大写字母或下划线组成。
\n- \n
\n名称以\"
\n_HEAD\"结尾，或者等于\"HEAD\"。\n\n在层次结构根目录中存在一些不符合这些规则的非正规引用。以下列表详细得列出了所有情况并不会继续扩展：
\n- \n
\n\n
AUTO_MERGE- \n
\n\n
BISECT_EXPECTED_REV- \n
\n\n
NOTES_MERGE_PARTIAL- \n
\n\n
NOTES_MERGE_REF- \n
\n\n
MERGE_AUTOSTASH\n\n不同的子层次结构用于不同的目的。如
\nrefs/heads/层次用于代表本地分支，而refs/tags/层次结构用于表示本地标签。引用日志显示一个引用的本地 “历史”。 换句话说，它可以告诉你，在昨天下午 9:14，这个 仓库的最后三次修订是什么，以及 这个 仓库的当前状态是什么。 详情见 linkgit:git-reflog[1]。
", - "引用规范 (refspec)": "“引用规范” 是获取和推送用以描述远程引用和本地引用之间的映射关系。详细说明参见 linkgit:git-fetch[1] 或 linkgit:git-push[1]。
", + "引用 (ref)": "一个指向对象名称或另一个引用（后者被称为符号引用）的名称。 为方便起见，当作为 Git 命令的参数时，引用可以使用缩写；参见 gitrevisions[7] 。 引用保存在仓库中。
\n\n\n引用名称空间是分层的。引用名称必须以
\nrefs/开头，或者位于层次结构的根目录中。对于后者，它们的名称必须遵循以下规则：\n", + "引用日志 (reflog)": "\n
\n- \n
\n名称仅由大写字母或下划线组成。
\n- \n
\n名称以\"
\n_HEAD\"结尾，或者等于\"HEAD\"。\n\n在层次结构根目录中存在一些不符合这些规则的非正规引用。以下列表详细得列出了所有情况并不会继续扩展：
\n- \n
\n\n
AUTO_MERGE- \n
\n\n
BISECT_EXPECTED_REV- \n
\n\n
NOTES_MERGE_PARTIAL- \n
\n\n
NOTES_MERGE_REF- \n
\n\n
MERGE_AUTOSTASH\n\n不同的子层次结构用于不同的目的。如
\nrefs/heads/层次用于代表本地分支，而refs/tags/层次结构用于表示本地标签。引用日志显示一个引用的本地 “历史”。 换句话说，它可以告诉你，在昨天下午 9:14，这个 仓库的最后三次修订是什么，以及 这个 仓库的当前状态是什么。 详情见 git-reflog[1]。
", + "引用规范 (refspec)": "“引用规范” 是获取和推送用以描述远程引用和本地引用之间的映射关系。详细说明参见 git-fetch[1] 或 git-push[1]。
", "远程仓库 (remote repository)": "一个部署在其他地方但用于跟踪同一个项目的仓库。要与远程通信，请参阅获取或推送。
", "远程跟踪分支 (remote-tracking branch)": "一个用来跟踪另一个仓库变化的引用。它通常看起来像’refs/remotes/foo/bar'（表示它跟踪一个名为’foo’的远程中名为’bar’的分支），并对配置好的fetch引用规范右侧进行匹配。一个远程跟踪分支不应该由直接的修改或是本地的提交构成。
", "仓库 (repository)": "一个引用的集合和一个对象库的集合，包含了引用中所有的可达的对象，可能还有一个或多个瓷件元数据。一个仓库可以通过轮替对象库与其他存储库共享对象数据库。
", @@ -73,15 +73,15 @@ "SCM（源代码管理工具）": "源代码管理（工具）。
", "SHA-1": "“安全哈希算法 1”；一个加密哈希函数。 在 Git 的上下文中是对象名的同义词。
", "浅克隆 (shallow clone)": "大部分是指浅仓库，但它更明确地表明其是通过运行
", - "浅仓库 (shallow repository)": "gitclone--depth=...命令创建的。一个浅仓库不会记录完整的提交历史，其中一些提交的父提交被销毁了（换句话说，Git 被告知假装这些提交没有父提交，尽管在提交对象中有记录）。当你只对一个项目的近期历史感兴趣时，这是很有用的，尽管上游记录的真实历史要大得多。通过给 linkgit:git-clone[1]提供
", + "浅仓库 (shallow repository)": "--depth选项，可以创建一个浅层的仓库，之后可以用 linkgit:git-fetch[1] 深掘它的历史。一个浅仓库不会记录完整的提交历史，其中一些提交的父提交被销毁了（换句话说，Git 被告知假装这些提交没有父提交，尽管在提交对象中有记录）。当你只对一个项目的近期历史感兴趣时，这是很有用的，尽管上游记录的真实历史要大得多。通过给 git-clone[1]提供
", "贮藏项 (stash entry)": "--depth选项，可以创建一个浅层的仓库，之后可以用 git-fetch[1] 深掘它的历史。一个对象，用于临时存储脏工作目录的内容和索引，以便将来重新使用。
", "子模块 (submodule)": "一个仓库保存着另一个库内的独立项目的历史（后者被称为父工程）。
", "父工程 (superproject)": "一个仓库在其工作区中引用其他项目的仓库，作为子模块。 父工程包含子模块的提交对象的名称（但不持有其副本）。
", - "符号引用 (symref)": "符号引用：它本身不包含 SHA-1 ID，而是采用 ref: refs/some/thing 的格式，当被引用时，它会递归 解引用 到该引用。HEAD 就是符号引用的一个典型例子。符号引用可以通过 linkgit:git-symbolic-ref[1] 命令来操作。
", + "符号引用 (symref)": "符号引用：它本身不包含 SHA-1 ID，而是采用 ref: refs/some/thing 的格式，当被引用时，它会递归 解引用 到该引用。HEAD 就是符号引用的一个典型例子。符号引用可以通过 git-symbolic-ref[1] 命令来操作。
", "标签 (tag)": "在
", "标签对象 (tag object)": "refs/tags/命名空间下的一个引用，指向一个任意类型的对象（通常一个标签指向一个标签对象或者一个提交对象）。 与head标记相比，标签不会被commit命令更新。Git 的标签与 Lisp 的标签（在Git的上下文中称为对象类型）毫无关系。标签最常用的是标记祖先提交中的一个特定对象链。一个对象包含一个指向另一个对象的引用，它可以像提交对象那样包含一个消息。它也可以包含一个（PGP）签名，这种情况下 PGP 被称为： “有签名的标签对象” (signed tag object)。
", "主题分支 (topic branch)": "一个常规的 Git 分支，被开发者用来确定一个概念性的开发路线。由于新建一个分支通常需要很小的代价，所以通常开发中会包含几个小的分支，每个分支都有着非常明确的概念或小的增量但相关的变化。
", - "尾注": "键值元数据。尾注可选地位于提交消息的末尾。在其他社区中可能被称为 “页脚” 或 “标签”。参见 linkgit:git-interpret-trailers[1]。
", + "尾注": "键值元数据。尾注可选地位于提交消息的末尾。在其他社区中可能被称为 “页脚” 或 “标签”。参见 git-interpret-trailers[1]。
", "树/目录树 (tree)": "要么是一个工作区，要么是一个树对象连同附属的二进制文件对对象和对象树（即一个工作区的存储表示）。
", "树对象 (tree object)": "一个对象包含一个文件名和模式的列表，以及相关的二进制文件和/或对象树的引用。一个树等同于一个目录。
", "树状标识 [tree-ish (also treeish)]": "一个 目录树对象 或一个 object 可以递归 解引用 到一个目录树对象。解引用 提交对象 可以得到与 修订 的顶层 目录 相对应的目录树对象。以下都是树状对象：一个 提交号、一个树状对象、一个指向树状对象的 标签对象、一个指向树状对象的标签对象、一个指向目录树对象的标签对象，等等。
",