提交 276d17e3 编写于 作者: W wizardforcel

checkout => 检出

上级 369555f2
......@@ -69,7 +69,7 @@ git mv [-v] [-f] [-n] [-k] <source> ... <destination directory>
## BUGS
每次超级项目更新移动填充的子模块时(例如,当在移动之前和之后切换提交时),旧的子模块结账将保留在旧位置,并且空目录将出现在新位置。要在新位置再次填充子模块,用户必须在之后运行“git submodule update”。删除旧目录只有在使用gitfile时才是安全的,否则子模块的历史记录也将被删除。当实现递归子模块更新时,这两个步骤都将过时。
每次超级项目更新移动填充的子模块时(例如,当在移动之前和之后切换提交时),旧的子模块检出将保留在旧位置,并且空目录将出现在新位置。要在新位置再次填充子模块,用户必须在之后运行“git submodule update”。删除旧目录只有在使用gitfile时才是安全的,否则子模块的历史记录也将被删除。当实现递归子模块更新时,这两个步骤都将过时。
## GIT
......
......@@ -183,7 +183,7 @@ $ git checkout <branch>
--ignore-skip-worktree-bits
```
在稀疏结账模式中,`git checkout -- &lt;paths&gt;`将仅更新与&lt; paths&gt;匹配的条目。和$ GIT_DIR / info / sparse-checkout中的稀疏模式。此选项忽略稀疏模式并添加&lt; paths&gt;中的所有文件。
在稀疏检出模式中,`git checkout -- &lt;paths&gt;`将仅更新与&lt; paths&gt;匹配的条目。和$ GIT_DIR / info / sparse-checkout中的稀疏模式。此选项忽略稀疏模式并添加&lt; paths&gt;中的所有文件。
```
-m
......@@ -338,7 +338,7 @@ a---b---c---d branch 'master' (refers to commit 'd')
tag 'v2.0' (refers to commit 'b')
```
实际上,我们可以执行所有正常的Git操作。但是,让我们来看看当我们结账大师时会发生什么:
实际上,我们可以执行所有正常的Git操作。但是,让我们来看看当我们检出大师时会发生什么:
```
$ git checkout master
......
......@@ -903,7 +903,7 @@ Git的实现不会在某些字段中留下可用的值(例如JGit);通过从
如果为true,则当行结束转换处于活动状态时,使Git检查转换`CRLF`是否可逆。 Git将验证命令是直接还是间接修改工作树中的文件。例如,提交文件后检出同一文件应该会在工作树中生成原始文件。如果`core.autocrlf`的当前设置不是这种情况,Git将拒绝该文件。该变量可以设置为“警告”,在这种情况下,Git只会警告不可逆转换,但继续操作。
CRLF转换有可能破坏数据。启用时,Git会在提交期间将CRLF转换为LF,在结账时将LF转换为CRLF。 Git无法重新创建提交之前包含LF和CRLF混合的文件。对于文本文件,这是正确的做法:它校正行结尾,这样我们在存储库中只有LF行结尾。但对于意外归类为文本的二进制文件,转换可能会破坏数据。
CRLF转换有可能破坏数据。启用时,Git会在提交期间将CRLF转换为LF,在检出时将LF转换为CRLF。 Git无法重新创建提交之前包含LF和CRLF混合的文件。对于文本文件,这是正确的做法:它校正行结尾,这样我们在存储库中只有LF行结尾。但对于意外归类为文本的二进制文件,转换可能会破坏数据。
如果您提前识别出此类损坏,则可以通过在.gitattributes中明确设置转换类型来轻松解决此问题。提交后,您仍然在工作树中保留原始文件,此文件尚未损坏。你可以明确告诉Git这个文件是二进制文件,Git会适当地处理文件。
......@@ -1221,7 +1221,7 @@ CRLF转换有可能破坏数据。启用时,Git会在提交期间将CRLF转换
core.sparseCheckout
```
启用“稀疏结账”功能。有关详细信息,请参阅 [git-read-tree [1]](https://git-scm.com/docs/git-read-tree) 中的“稀疏结账”部分。
启用“稀疏检出”功能。有关详细信息,请参阅 [git-read-tree [1]](https://git-scm.com/docs/git-read-tree) 中的“稀疏检出”部分。
```
core.abbrev
......@@ -1381,13 +1381,13 @@ CRLF转换有可能破坏数据。启用时,Git会在提交期间将CRLF转换
当你运行 _git checkout&lt; something&gt;_ 并且只有一个遥控器,它可能隐含地退回检查和跟踪,例如_来源/&lt; something&gt;_ 。一旦你有一个带有_&lt; something&gt;的远程遥控器,这就会停止工作_参考。此设置允许设置首选远程的名称,该名称在消除歧义时应始终获胜。典型的用例是将其设置为`origin`
目前,当 _git checkout&lt; something&gt;时, [git-checkout [1]](https://git-scm.com/docs/git-checkout) 使用它。_ 将结账_&lt; something&gt;_ 分支在另一个遥控器上,而 [git-worktree [1]](https://git-scm.com/docs/git-worktree) 当 _git worktree add_ 指的是一个远程分支。此设置可能会在将来用于其他类似结帐的命令或功能。
目前,当 _git checkout&lt; something&gt;时, [git-checkout [1]](https://git-scm.com/docs/git-checkout) 使用它。_ 将检出_&lt; something&gt;_ 分支在另一个遥控器上,而 [git-worktree [1]](https://git-scm.com/docs/git-worktree) 当 _git worktree add_ 指的是一个远程分支。此设置可能会在将来用于其他类似结帐的命令或功能。
```
checkout.optimizeNewBranch
```
优化“git checkout -b&lt; new_branch&gt;”的性能使用稀疏结账时。设置为true时,git不会根据当前的稀疏结帐设置更新repo。这意味着它不会更新索引中的skip-worktree位,也不会在工作目录中添加/删除文件以反映当前的稀疏检出设置,也不会显示本地更改。
优化“git checkout -b&lt; new_branch&gt;”的性能使用稀疏检出时。设置为true时,git不会根据当前的稀疏结帐设置更新repo。这意味着它不会更新索引中的skip-worktree位,也不会在工作目录中添加/删除文件以反映当前的稀疏检出设置,也不会显示本地更改。
```
clean.requireForce
......
......@@ -118,7 +118,7 @@ $ git worktree add --track -b <branch> <path> <remote>/<branch>
--[no-]checkout
```
默认情况下,`add`检出`&lt;commit-ish&gt;`,但是,`--no-checkout`可用于抑制检出以进行自定义,例如配置稀疏检出。请参见 [git-read-tree [1]](https://git-scm.com/docs/git-read-tree) 中的“稀疏结账”。
默认情况下,`add`检出`&lt;commit-ish&gt;`,但是,`--no-checkout`可用于抑制检出以进行自定义,例如配置稀疏检出。请参见 [git-read-tree [1]](https://git-scm.com/docs/git-read-tree) 中的“稀疏检出”。
```
--[no-]guess-remote
......@@ -224,7 +224,7 @@ $ git config extensions.worktreeConfig true
* 永远不要共享`core.worktree`和`core.bare`
* 除非您确定始终对所有工作树使用稀疏结账,否则建议每个工作树使用`core.sparseCheckout`。
* 除非您确定始终对所有工作树使用稀疏检出,否则建议每个工作树使用`core.sparseCheckout`。
## 细节
......@@ -286,7 +286,7 @@ $ git worktree remove ../temp
## BUGS
一般的多次结账仍然是实验性的,对子模块的支持是不完整的。建议不要对超级项目进行多次检出。
一般的多次检出仍然是实验性的,对子模块的支持是不完整的。建议不要对超级项目进行多次检出。
## GIT
......
......@@ -74,7 +74,7 @@ git pull [<options>] [<repository> [<refspec>…​]]
此选项控制是否应该获取和更新所有已填充子模块的新提交(请参阅 [git-config [1]](https://git-scm.com/docs/git-config)[gitmodules [5]](https://git-scm.com/docs/gitmodules) )。
如果通过rebase完成结账,则本地子模块提交也会被重新设置。
如果通过rebase完成检出,则本地子模块提交也会被重新设置。
如果通过合并完成更新,则解析并检出子模块冲突。
......
......@@ -80,7 +80,7 @@ git submodule [--quiet] absorbgitdirs [--] [<path>…​]
update [--init] [--remote] [-N|--no-fetch] [--[no-]recommend-shallow] [-f|--force] [--checkout|--rebase|--merge] [--reference <repository>] [--depth <depth>] [--recursive] [--jobs <n>] [--] [<path>…​]
```
通过克隆缺失的子模块并更新子模块的工作树,更新已注册的子模块以匹配超级项目所期望的内容。 “更新”可以通过多种方式完成,具体取决于命令行选项和`submodule.&lt;name&gt;.update`配置变量的值。命令行选项优先于配置变量。如果两者都没有给出,则执行_结账_。从命令行以及通过`submodule.&lt;name&gt;.update`配置支持的_更新_程序是:
通过克隆缺失的子模块并更新子模块的工作树,更新已注册的子模块以匹配超级项目所期望的内容。 “更新”可以通过多种方式完成,具体取决于命令行选项和`submodule.&lt;name&gt;.update`配置变量的值。命令行选项优先于配置变量。如果两者都没有给出,则执行_检出_。从命令行以及通过`submodule.&lt;name&gt;.update`配置支持的_更新_程序是:
```
checkout
......
......@@ -58,7 +58,7 @@ pattern attr1 attr2 ...
在确定为路径分配了哪些属性时,Git会查询`$GIT_DIR/info/attributes`文件(具有最高优先级),`.gitattributes`文件与相关路径位于同一目录中,其父目录最多为工作树的顶层(包含`.gitattributes`的目录越远离有问题的路径,其优先级越低)。最后考虑全局和系统范围的文件(它们具有最低优先级)。
当工作树中缺少`.gitattributes`文件时,索引中的路径将用作后退。在结账过程中,使用索引中的`.gitattributes`,然后将工作树中的文件用作后备。
当工作树中缺少`.gitattributes`文件时,索引中的路径将用作后退。在检出过程中,使用索引中的`.gitattributes`,然后将工作树中的文件用作后备。
如果您希望仅影响单个存储库(即,将属性分配给特定于该存储库的一个用户工作流的文件),则应将属性放在`$GIT_DIR/info/attributes`文件中。应该由版本控制并分发到其他存储库的属性(即,所有用户感兴趣的属性)应该进入`.gitattributes`文件。应该影响单个用户的所有存储库的属性应该放在由`core.attributesFile`配置选项指定的文件中(参见 [git-config [1]](https://git-scm.com/docs/git-config) )。其默认值为$ XDG_CONFIG_HOME / git / attributes。如果$ XDG_CONFIG_HOME未设置或为空,则使用$ HOME / .config / git / attributes。系统中所有用户的属性应放在`$(prefix)/etc/gitattributes`文件中。
......@@ -182,7 +182,7 @@ weirdchars.txt text
如果`core.safecrlf`设置为“true”或“warn”,Git将验证当前设置`core.autocrlf`的转换是否可逆。对于“真实”,Git拒绝不可逆转的转换;对于“警告”,Git仅打印警告但接受不可逆转的转换。安全触发器可以防止对工作树中的文件进行此类转换,但也有一些例外情况。即使......
* _git add_ 本身不会触及工作树中的文件,下次结账就会,所以安全触发器;
* _git add_ 本身不会触及工作树中的文件,下次检出就会,所以安全触发器;
* _git apply_ 用补丁更新文本文件确实触摸了工作树中的文件,但操作是关于文本文件而CRLF转换是关于修复行结尾不一致的,所以安全性不会触发;
......@@ -200,7 +200,7 @@ Git将以ASCII或其中一个超集(例如UTF-8,ISO-8859-1,...)编码的
例如,Microsoft Visual Studio资源文件(`*.rc`)或PowerShell脚本文件(`*.ps1`)有时以UTF-16编码。如果将`*.ps1`声明为UTF-16文件并添加`foo.ps1`并启用`working-tree-encoding` Git客户端,则`foo.ps1`将在内部存储为UTF-8。没有`working-tree-encoding`支持的客户端将`foo.ps1`签出为UTF-8编码文件。这通常会给该文件的用户带来麻烦。
如果不支持`working-tree-encoding`属性的Git客户端添加新文件`bar.ps1`,则`bar.ps1`将在内部“按原样”存储(在此示例中可能为UTF-16)。具有`working-tree-encoding`支持的客户端将内部内容解释为UTF-8并尝试在结账时将其转换为UTF-16。该操作将失败并导致错误。
如果不支持`working-tree-encoding`属性的Git客户端添加新文件`bar.ps1`,则`bar.ps1`将在内部“按原样”存储(在此示例中可能为UTF-16)。具有`working-tree-encoding`支持的客户端将内部内容解释为UTF-8并尝试在检出时将其转换为UTF-16。该操作将失败并导致错误。
* 将内容重新编码为非UTF编码可能会导致错误,因为转换可能不是UTF-8往返安全。如果您怀疑您的编码不是往返安全,那么将其添加到`core.checkRoundtripEncoding`以使Git检查往返编码(参见 [git-config [1]](https://git-scm.com/docs/git-config) )。已知SHIFT-JIS(日语字符集)具有UTF-8的往返问题,默认情况下会进行检查。
......@@ -244,7 +244,7 @@ file foo.ps1
内容过滤的一个用途是将内容按摩成对于平台,文件系统和用户更方便使用的形状。对于这种操作模式,这里的关键短语是“更方便”而不是“将某些东西变为无法使用”。换句话说,目的是如果有人取消设置过滤器驱动程序定义,或者没有适当的过滤程序,则该项目仍应可用。
内容过滤的另一个用途是存储无法直接在存储库中使用的内容(例如,引用存储在Git外部的真实内容的UUID,或加密内容),并在结账时将其转换为可用形式(例如,下载外部内容,或解密加密内容)。
内容过滤的另一个用途是存储无法直接在存储库中使用的内容(例如,引用存储在Git外部的真实内容的UUID,或加密内容),并在检出时将其转换为可用形式(例如,下载外部内容,或解密加密内容)。
这两个过滤器的行为不同,默认情况下,过滤器被视为前者,将内容按摩为更方便的形状。配置中缺少过滤器驱动程序定义,或者以非零状态退出的过滤器驱动程序不是错误,而是使过滤器成为无操作通路。
......
......@@ -88,9 +88,9 @@ Git附带的示例`prepare-commit-msg`挂钩删除了在提交模板的注释部
这个钩子由 [git-rebase [1]](https://git-scm.com/docs/git-rebase) 调用,可以用来防止分支被重新绑定。可以用一个或两个参数调用钩子。第一个参数是分支系列的上游。第二个参数是重新分支的分支,在重新定位当前分支时不会设置。
### 后结账
### 后检出
更新工作树后运行 [git-checkout [1]](https://git-scm.com/docs/git-checkout) 时会调用此挂钩。钩子被赋予三个参数:前一个HEAD的ref,新HEAD的ref(可能已经或可能没有改变),以及一个标志,指示结账是否是分支结账(更改分支,标志= 1)或文件签出(从索引中检索文件,标志= 0)。这个钩子不会影响`git checkout`的结果。
更新工作树后运行 [git-checkout [1]](https://git-scm.com/docs/git-checkout) 时会调用此挂钩。钩子被赋予三个参数:前一个HEAD的ref,新HEAD的ref(可能已经或可能没有改变),以及一个标志,指示检出是否是分支检出(更改分支,标志= 1)或文件签出(从索引中检索文件,标志= 0)。这个钩子不会影响`git checkout`的结果。
它也在 [git-clone [1]](https://git-scm.com/docs/git-clone) 之后运行,除非使用`--no-checkout``-n`)选项。给钩子的第一个参数是null-ref,第二个是新HEAD的ref,而标志总是1.同样对于`git worktree add`,除非使用`--no-checkout`
......@@ -196,7 +196,7 @@ _更新后_挂钩可以判断推送的磁头是什么,但是它不知道它们
标准输出和标准错误输出都转发到另一端的`git send-pack`,因此您只需为用户输入`echo`消息即可。
### 一键结账
### 一键检出
[git-receive-pack [1]](https://git-scm.com/docs/git-receive-pack)`git push`做出反应并更新其存储库中的引用时,以及当push尝试更新当前已检出的分支时,将调用此挂钩并且`receive.denyCurrentBranch`配置变量设置为`updateInstead`。如果工作树和远程存储库的索引与当前检出的提交有任何差异,则默认拒绝这样的推送;当工作树和索引都与当前提交匹配时,它们会更新以匹配新推送的分支提示。此挂钩用于覆盖默认行为。
......
......@@ -34,7 +34,7 @@ $ GIT_WORK_DIR / .gitmodules
submodule.<name>.update
```
定义命名子模块的默认更新过程,即超级项目中“git submodule update”命令如何更新子模块。这仅由`git submodule init`用于初始化同名的配置变量。这里允许的值是_结账_, _rebase_ ,_合并_或_无_。有关其含义,请参阅 [git-submodule [1]](https://git-scm.com/docs/git-submodule) 中 _update_ 命令的说明。请注意,出于安全原因,此处有意忽略_!命令_表单。
定义命名子模块的默认更新过程,即超级项目中“git submodule update”命令如何更新子模块。这仅由`git submodule init`用于初始化同名的配置变量。这里允许的值是_检出_, _rebase_ ,_合并_或_无_。有关其含义,请参阅 [git-submodule [1]](https://git-scm.com/docs/git-submodule) 中 _update_ 命令的说明。请注意,出于安全原因,此处有意忽略_!命令_表单。
```
submodule.<name>.branch
......
......@@ -194,7 +194,7 @@ git read-tree [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>]
当 _git read-tree_ 的这种形式成功返回时,您可以通过运行`git diff-index --cached $M`来查看您所做的哪些“本地更改”。请注意,这不一定与`git diff-index --cached $H`在这样的两个树合并之前产生的内容相匹配。这是因为案例18和19 ---如果你已经有$ M的变化(例如,你可能通过电子邮件以补丁形式提取),`git diff-index --cached $H`会告诉你这个合并之前的变化,但在两树合并后它不会显示在`git diff-index --cached $M`输出中。
案例3有点棘手,需要解释。逻辑上,此规则的结果应该是在用户暂停路径删除然后切换到新分支时删除路径。然而,这将阻止初始结账发生,因此仅当索引的内容为空时才修改规则以使用M(新树)。否则,只要$ H和$ M相同,就会保留路径的删除。
案例3有点棘手,需要解释。逻辑上,此规则的结果应该是在用户暂停路径删除然后切换到新分支时删除路径。然而,这将阻止初始检出发生,因此仅当索引的内容为空时才修改规则以使用M(新树)。否则,只要$ H和$ M相同,就会保留路径的删除。
### 三向合并
......@@ -271,7 +271,7 @@ $ echo "Merge with Linus" | \
## SPARSE CHECKOUT
“稀疏结账”允许稀疏地填充工作目录。它使用skip-worktree位(参见 [git-update-index [1]](https://git-scm.com/docs/git-update-index) )告诉Git工作目录中的文件是否值得查看。
“稀疏检出”允许稀疏地填充工作目录。它使用skip-worktree位(参见 [git-update-index [1]](https://git-scm.com/docs/git-update-index) )告诉Git工作目录中的文件是否值得查看。
_git read-tree_ 和其他基于合并的命令( _git merge_ , _git checkout_ ...)可以帮助维护skip-worktree位图和工作目录更新。 `$GIT_DIR/info/sparse-checkout`用于定义跳过工作树参考位图。当 _git read-tree_ 需要更新工作目录时,它会根据此文件重置索引中的skip-worktree位,该文件使用与.gitignore文件相同的语法。如果条目与此文件中的模式匹配,则不会在该条目上设置skip-worktree。否则,将设置skip-worktree。
......@@ -284,13 +284,13 @@ _git read-tree_ 和其他基于合并的命令( _git merge_ , _git checkout_
!unwanted
```
另一个棘手的问题是,当您不再需要稀疏结账时,完全重新填充工作目录。您不能只禁用“稀疏结账”,因为skip-worktree位仍在索引中,并且您的工作目录仍然是稀疏填充的。您应该使用`$GIT_DIR/info/sparse-checkout`文件内容重新填充工作目录,如下所示:
另一个棘手的问题是,当您不再需要稀疏检出时,完全重新填充工作目录。您不能只禁用“稀疏检出”,因为skip-worktree位仍在索引中,并且您的工作目录仍然是稀疏填充的。您应该使用`$GIT_DIR/info/sparse-checkout`文件内容重新填充工作目录,如下所示:
```
/*
```
然后你可以禁用稀疏结账。默认情况下, _git read-tree_ 和类似命令中的稀疏结账支持被禁用。您需要打开`core.sparseCheckout`才能获得稀疏的结帐支持。
然后你可以禁用稀疏检出。默认情况下, _git read-tree_ 和类似命令中的稀疏检出支持被禁用。您需要打开`core.sparseCheckout`才能获得稀疏的结帐支持。
## 也可以看看
......
......@@ -778,9 +778,9 @@ _rev-list_ 是一个非常重要的Git命令,因为它提供了构建和遍历
形式 _--filter = blob:limit =&lt; n&gt; [kmg]_ 省略大于n个字节或单位的blob。 n可能为零。后缀k,m和g可用于命名KiB,MiB或GiB中的单位。例如, _blob:limit = 1k_ 与 _blob相同:limit = 1024_ 。
形式 _--filter =稀疏:oid =&lt; blob-ish&gt;_ 使用包含在blob(或blob-expression)_&lt; blob-ish&gt;中的稀疏检验规范。_ 省略在请求的refs上进行稀疏结账时不需要的blob。
形式 _--filter =稀疏:oid =&lt; blob-ish&gt;_ 使用包含在blob(或blob-expression)_&lt; blob-ish&gt;中的稀疏检验规范。_ 省略在请求的refs上进行稀疏检出时不需要的blob。
形式 _--filter = sparse:path =&lt; path&gt;_ 类似地使用&lt; path&gt;中包含的稀疏结账规范。
形式 _--filter = sparse:path =&lt; path&gt;_ 类似地使用&lt; path&gt;中包含的稀疏检出规范。
形式 _- 过滤器=树:&lt;深度&gt;_ 省略了从根树的深度&gt; =&lt; depth&gt;的所有斑点和树木。 (如果对象位于所遍历的提交的多个深度处,则为最小深度)。 &lt; depth&gt; = 0将不包含任何树或blob,除非在命令行中显式包含(或使用--stdin时的标准输入)。 &lt; depth&gt; = 1将仅包括由&lt; commit&gt;可到达的提交直接引用的树和blob。或明确给定的对象。 &lt; depth&gt; = 2类似于&lt; depth&gt; = 1,同时还包括从明确给定的提交或树中移除一个级别的树和blob。
......
......@@ -254,7 +254,7 @@ _git update-index_ 处理文件的方式可以使用各种选项进行修改:
## 使用--CACHEINFO或--INFO-ONLY
`--cacheinfo`用于注册不在当前工作目录中的文件。这对于最小结账合并非常有用。
`--cacheinfo`用于注册不在当前工作目录中的文件。这对于最小检出合并非常有用。
假装你在模式和sha1的路径上有一个文件,说:
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册