Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
OpenDocCN
git-doc-zh
提交
a7c95613
G
git-doc-zh
项目概览
OpenDocCN
/
git-doc-zh
通知
0
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
G
git-doc-zh
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
前往新版Gitcode,体验更适合开发者的 AI 搜索 >>
未验证
提交
a7c95613
编写于
6月 19, 2019
作者:
飞
飞龙
提交者:
GitHub
6月 19, 2019
浏览文件
操作
浏览文件
下载
差异文件
Merge pull request #9 from Mrhuangyi/master
文档校对
上级
8fa20983
d1943817
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
26 addition
and
26 deletion
+26
-26
docs/22.md
docs/22.md
+26
-26
未找到文件。
docs/22.md
浏览文件 @
a7c95613
...
...
@@ -18,11 +18,11 @@ git pull [<options>] [<repository> [<refspec>…]]
更确切地说, _git pull_ 使用给定参数运行 _git fetch_ 并调用 _git merge_ 将检索到的分支头合并到当前分支中。使用
`--rebase`
,它运行 _git rebase_ 而不是 _git merge_ 。
<
库
>
应该是传递给
[
git-fetch [1]
](
https://git-scm.com/docs/git-fetch
)
的
远程存储库的名称。
<
的Refspec
>
可以命名任意远程引用(例如,标记的名称),
甚至是具有相应远程跟踪分支的引用集合(例如,refs / heads /
*:refs / remotes / origin / *
),但通常它是远程存储库中分支的名称。
<
库
>
应该是传递给
[
git-fetch [1]
](
https://git-scm.com/docs/git-fetch
)
的
一个远程存储库的名称。
<
的Refspec
>
可以命名任意远程引用(例如,标签的名称),或者
甚至是具有相应远程跟踪分支的引用集合(例如,refs / heads /
*:refs / remotes / origin / *
),但通常它是远程存储库中分支的名称。
<
repository
>
的默认值和
<
branch
>
从
[
git-branch [1]
](
https://git-scm.com/docs/git-branch
)
`--track`
设置的当前分支的“远程”和“合并”配置中读取。
<
repository
>
和
<
branch
>
的默认值
从
[
git-branch [1]
](
https://git-scm.com/docs/git-branch
)
`--track`
设置的当前分支的“远程”和“合并”配置中读取。
假设存在以下历史记录
,
当前分支为“
`master`
”:
假设存在以下历史记录
并且
当前分支为“
`master`
”:
```
A---B---C master on origin
...
...
@@ -32,7 +32,7 @@ git pull [<options>] [<repository> [<refspec>…]]
origin/master in your repository
```
然后“
`git pull`
”将从远程
`master`
分支获取并重放更改,因为它偏离本地
`master`
(即
`E`
),直到它在
`master`
之上的当前提交(
`C`
)
并将结果记录在新提交中,同时记录两个父提交的名称以及描述更改的用户的日志消息。
因为它偏离本地
`master`
(即
`E`
),所以“
`git pull`
”将从远程
`master`
分支获取并重放相应的更改,直到它的当前提交(
`C`
)在
`master`
上面
并将结果记录在新提交中,同时记录两个父提交的名称以及描述更改的用户的日志消息。
```
A---B---C origin/master
...
...
@@ -42,7 +42,7 @@ git pull [<options>] [<repository> [<refspec>…]]
有关详细信息,请参阅
[
git-merge [1]
](
https://git-scm.com/docs/git-merge
)
,包括如何呈现和处理冲突。
在Git 1.7.0或更高版本中,要取消
冲突的合并,请使用
`git reset --merge`
。
**警告**
:在旧版本的Git中,不鼓励使用未提交的更改运行 _git pull_ :尽管可能,它会使您处于可能难以退出的状态冲突
在Git 1.7.0或更高版本中,要取消
一个有冲突的合并,请使用
`git reset --merge`
。
**警告**
:在旧版本的Git中,不鼓励使用未提交的更改运行 _git pull_ :尽管或许可行,但它可能会使您处于难以退出的冲突状态
如果任何远程更改与本地未提交的更改重叠,则将自动取消合并并且不更改工作树。通过
[
git-stash [1]
](
https://git-scm.com/docs/git-stash
)
拉动或存放它们之前,通常最好在工作顺序中进行任何局部更改。
...
...
@@ -134,7 +134,7 @@ git pull [<options>] [<repository> [<refspec>…]]
--gpg-sign[=<keyid>]
```
GPG签署生成的合并提交。
`keyid`
参数是可选的
,默认为提交者标识;如果
指定,它必须粘在没有空格的选项上。
GPG签署生成的合并提交。
`keyid`
参数是可选的
并且默认为提交者标识;如果具体
指定,它必须粘在没有空格的选项上。
```
--log[=<n>]
...
...
@@ -156,9 +156,9 @@ GPG签署生成的合并提交。 `keyid`参数是可选的,默认为提交者
--no-signoff
```
在提交日志消息的末尾由提交者
添加逐行
签名。签收的含义取决于项目,但它通常证明提交者有权在同一许可下提交此作品并同意开发者原产地证书(参见
[
http://developercertificate.org/
](
http://developercertificate.org/
)
] 欲获得更多信息)。
在提交日志消息的末尾由提交者
逐行添加
签名。签收的含义取决于项目,但它通常证明提交者有权在同一许可下提交此作品并同意开发者原产地证书(参见
[
http://developercertificate.org/
](
http://developercertificate.org/
)
] 欲获得更多信息)。
使用--no-signoff时不要添加
Sign-off-by
行。
使用--no-signoff时不要添加
类似Sign-off-by的短
行。
```
--stat
...
...
@@ -250,7 +250,7 @@ GPG签署生成的合并提交。 `keyid`参数是可选的,默认为提交者
如果为false,则将当前分支合并到上游分支中。
当
`interactive`
时,启用rebase的交互模式。
当
为
`interactive`
时,启用rebase的交互模式。
如果要使
`git pull`
始终使用
`--rebase`
而不是合并,请参见
[
git-config [1]
](
https://git-scm.com/docs/git-config
)
中的
`pull.rebase`
,
`branch.<name>.rebase`
和
`branch.autoSetupRebase`
。
...
...
@@ -336,9 +336,9 @@ GPG签署生成的合并提交。 `keyid`参数是可选的,默认为提交者
默认情况下,Git将向服务器报告可从所有本地引用访问的提交,以查找公共提交以尝试减少要接收的包文件的大小。如果指定,Git将仅报告从给定提示可到达的提交。当用户知道哪个本地ref可能与正在获取的上游引用有共同提交时,这对于加速提取是有用的。
可以多次指定此选项;如果是这样,Git将报告从任何给定提交可到达
的提交。
此选项可以多次被指定;如果是这样,Git将报告从任何给定的提交中可访问
的提交。
此选项的参数可以是ref的名称,ref或者提交的(可能缩写的)SHA-1上的glob。指定glob等效于多次指定此选项,每个匹配
的ref名称一个
。
此选项的参数可以是ref的名称,ref或者提交的(可能缩写的)SHA-1上的glob。指定glob等效于多次指定此选项,每个匹配
对应的一个ref名称
。
另请参见
[
git-config [1]
](
https://git-scm.com/docs/git-config
)
中记录的
`fetch.negotiationAlgorithm`
配置变量。
...
...
@@ -376,7 +376,7 @@ GPG签署生成的合并提交。 `keyid`参数是可选的,默认为提交者
--update-head-ok
```
默认情况下 _git fetch_ 拒绝更新与当前分支对应的头部。此标志禁用检查。这纯粹是为 _git pull_
内部使用与 _git fetch_ 进行通信,除非你实现
自己的瓷器,否则你不应该使用它。
默认情况下 _git fetch_ 拒绝更新与当前分支对应的头部。此标志禁用检查。这纯粹是为 _git pull_
与 _git fetch_ 内部使用时进行通信,除非你实现你
自己的瓷器,否则你不应该使用它。
```
--upload-pack <upload-pack>
...
...
@@ -424,7 +424,7 @@ GPG签署生成的合并提交。 `keyid`参数是可选的,默认为提交者
<repository>
```
“远程”存储库,它是获取或拉取操作的源。该参数可以是URL(参见下面的
[
GIT URL
](
#URLS
)
部分)或
遥控器
的名称(参见下面的
[
REMOTES
](
#REMOTES
)
部分)。
“远程”存储库,它是获取或拉取操作的源。该参数可以是URL(参见下面的
[
GIT URL
](
#URLS
)
部分)或
remote
的名称(参见下面的
[
REMOTES
](
#REMOTES
)
部分)。
```
<refspec>
...
...
@@ -446,19 +446,19 @@ GPG签署生成的合并提交。 `keyid`参数是可选的,默认为提交者
与使用
[
git-push [1]
](
https://git-scm.com/docs/git-push
)
进行推送不同,没有任何配置可以修改这些规则,也没有类似于
`pre-receive`
挂钩的
`pre-fetch`
挂钩。
与使用
[
git-push [1]
](
https://git-scm.com/docs/git-push
)
推送一样,可以通过向refspec添加可选的前导
`+`
(或使用
`--force`
来覆盖上面描述的关于不允许作为更新的所有规则。 ]命令行选项)
。唯一的例外是没有任何强制将使
`refs/heads/*`
命名空间接受非提交对象。
与使用
[
git-push [1]
](
https://git-scm.com/docs/git-push
)
推送一样,可以通过向refspec添加可选的前导
`+`
(或使用
`--force`
命令行选项)来覆盖上面描述的关于不允许作为更新的所有规则。
。唯一的例外是没有任何强制将使
`refs/heads/*`
命名空间接受非提交对象。
| 注意 | 当你想要获取的远程分支被认为是经常倒带和重新定位时,预计它的新提示将不会是其上一个提示的后代(如上次提取时存储在远程跟踪分支中)。您可能希望使用
`+`
符号来指示此类分支将需要非快进更新。无法确定或声明具有此行为的存储库中的分支可用;拉动用户只需知道这是分支的预期使用模式。 |
| 注意 |
列出多个
<
refspec
>
之间存在差异直接在 _git pull_ 命令行上,并在您的配置中为
<
repository
>
提供多个`remote.
<
repository
>
.fetch
`条目并运行 _git pull_ 命令,没有任何明确的< refspec>参数。在命令行中明确列出的< refspec>在获取后始终合并到当前分支中。换句话说,如果列出多个远程引用, _git pull_ 将创建一个Octopus合并。另一方面,如果你没有列出任何明确的< refspec>在命令行上的参数, _git pull_ 将获取它在`
remote.
<
repository
>
.fetch`配置中找到的所有
<
refspec
>
s并仅合并第一个
<
refspec
>
找到了
当前的分支。这是因为很少使用远程参考设备制作八达通,而通过提取一个以上来一次跟踪多个远程磁头通常很有用。 |
| 注意 |
在 _git pull_ 命令行上直接列出多个
<
refspec
>和在您的配置中为<
repository
>
提供多个`remote.
<
repository
>
.fetch
`条目并运行 _git pull_ 命令,没有任何明确的< refspec>参数之间存在差异。在命令行中明确列出的< refspec>在获取后始终合并到当前分支中。换句话说,如果你列出多个远程引用, _git pull_ 将创建一个Octopus合并。另一方面,如果你没有列出任何明确的< refspec>在命令行上的参数, _git pull_ 将获取它在`
remote.
<
repository
>
.fetch`配置中找到的所有
<
refspec
>
s并仅合并第一个找到的
<
refspec
>
到
当前的分支。这是因为很少使用远程参考设备制作八达通,而通过提取一个以上来一次跟踪多个远程磁头通常很有用。 |
## GIT网址
通常,URL包含有关传输协议,远程服务器的地址以及存储库路径的信息。根据传输协议,可能缺少某些信息。
Git支持ssh,git,http和https协议(此外,ftp和ftps可用于获取,但这是低效的并且已弃用;请勿使用它)。
Git支持ssh,git,http和https协议(此外,ftp和ftps可用于获取,但这是低效的并且已
被
弃用;请勿使用它)。
本机传输(即git:// URL)不进行身份验证,
应在不安全的网络上
谨慎使用。
本机传输(即git:// URL)不进行身份验证,
在不安全的网络上应当
谨慎使用。
可以使用以下语法:
...
...
@@ -474,7 +474,7 @@ Git支持ssh,git,http和https协议(此外,ftp和ftps可用于获取,
*
[用户@] host.xz:路径/到/ repo.git /
只有在第一个冒号之前没有斜杠时才会识别此语法。这有助于区分包含冒号的本地路径。例如,本地路径
`foo:bar`
可以指定为绝对路径或
`./foo:bar`
,以避免被误解为ssh url。
只有在第一个冒号之前没有斜杠时才会识别此语法。这有助于区分包含冒号的本地路径。例如,本地路径
`foo:bar`
可以指定为绝对路径或
`./foo:bar`
,以避免被误解为
一个
ssh url。
ssh和git协议还支持〜用户名扩展:
...
...
@@ -545,7 +545,7 @@ ssh和git协议还支持〜用户名扩展:
### 在配置文件中命名为remote
您可以选择使用
[
git-remote [1]
](
https://git-scm.com/docs/git-remote
)
,
[
git-config [1]
](
https://git-scm.com/docs/git-config
)
提供之前配置的遥控器的名称,甚至可以手动编辑
`$GIT_DIR/config`
文件。此远程的URL将用于访问存储库。如果未在命令行上提供refspec,则默认情况下将使用此远程的refspec。配置文件中的条目如下所示:
您可以选择使用
[
git-remote [1]
](
https://git-scm.com/docs/git-remote
)
,
[
git-config [1]
](
https://git-scm.com/docs/git-config
)
提供之前配置的遥控器的名称,甚至可以手动编辑
`$GIT_DIR/config`
文件。此远程的URL将用于访问存储库。如果
你
未在命令行上提供refspec,则默认情况下将使用此远程的refspec。配置文件中的条目如下所示:
```
[remote "<name>"]
...
...
@@ -579,7 +579,7 @@ _git push_ 使用`Push:`行, _git pull_ 和 _git fetch_ 使用`Pull:`系。可
`<url>`
是必需的;
`#<head>`
是可选的。
根据操作,如果您没有在命令行上提供一个refitpec,git将使用以下refspec
之一
。
`<branch>`
是
`$GIT_DIR/branches`
中此文件的名称,
`<head>`
默认为
`master`
。
根据操作,如果您没有在命令行上提供一个refitpec,git将使用以下refspec
中的一个
。
`<branch>`
是
`$GIT_DIR/branches`
中此文件的名称,
`<head>`
默认为
`master`
。
git fetch使用:
...
...
@@ -615,7 +615,7 @@ _递归_策略可以采用以下选项:
ours
```
这个选项通过支持_我们的_版本来强制
冲突的帅哥
干净地自动解决。来自与我们方不冲突的其他树的更改将反映到合并结果中。对于二进制文件,整个内容都来自我们这边。
这个选项通过支持_我们的_版本来强制
大块的冲突
干净地自动解决。来自与我们方不冲突的其他树的更改将反映到合并结果中。对于二进制文件,整个内容都来自我们这边。
这不应该与_我们的_合并策略混淆,后者甚至不会查看其他树包含的内容。它丢弃了另一棵树所做的一切,声明_我们的_历史记录中包含了所有发生的事情。
...
...
@@ -745,7 +745,7 @@ globbing refspec必须具有非空RHS(即必须存储在远程跟踪分支中
## 例子
*
更新克隆的存储库的远程跟踪分支,然后将其中一个合并到当前分支中:
*
更新
你
克隆的存储库的远程跟踪分支,然后将其中一个合并到当前分支中:
```
$ git pull
...
...
@@ -767,11 +767,11 @@ globbing refspec必须具有非空RHS(即必须存储在远程跟踪分支中
$ git merge origin/next
```
如果您尝试拉
动
导致复杂冲突并且想要重新开始,则可以使用 _git reset_ 进行恢复。
如果您尝试拉
取后
导致复杂冲突并且想要重新开始,则可以使用 _git reset_ 进行恢复。
## 安全
提取和推送协议的目的不是为了防止一方窃取不打算共享的其他存储库中的数据。如果您需要保护私有数据免受恶意对等方的攻击,那么最佳选择是将其存储在另一个存储库中。这适用于客户端和服务器。特别是,服务器上的命名空间对读访问控制无效;您应该只将命名空间的读访问权授予您信任的客户端,并具有对整个存储库的读访问权限。
设计
提取和推送协议的目的不是为了防止一方窃取不打算共享的其他存储库中的数据。如果您需要保护私有数据免受恶意对等方的攻击,那么最佳选择是将其存储在另一个存储库中。这适用于客户端和服务器。特别是,服务器上的命名空间对读访问控制无效;您应该只将命名空间的读访问权授予您信任的客户端,并具有对整个存储库的读访问权限。
已知的攻击向量如下:
...
...
@@ -781,7 +781,7 @@ globbing refspec必须具有非空RHS(即必须存储在远程跟踪分支中
## BUGS
使用--recurse-submodules只能在已检出的子模块中获取新的提交。例如,
上游在超级项目的刚刚提取的提交中添加了一个新的子模块,子模块本身无法获取,因此无法在以后检查该子模块而无需再次进行提取。预计将在未来的Git版本中
修复。
使用--recurse-submodules只能在已检出的子模块中获取新的提交。例如,
当上游在超级项目的刚刚提取的提交中添加了一个新的子模块,子模块本身无法获取,因此无法在以后检查该子模块而无需再次进行提取。这预计将在未来的Git版本中被
修复。
## 也可以看看
...
...
@@ -789,4 +789,4 @@ globbing refspec必须具有非空RHS(即必须存储在远程跟踪分支中
## GIT
部分
[
git [1]
](
https://git-scm.com/docs/git
)
套件
\ No newline at end of file
部分
[
git [1]
](
https://git-scm.com/docs/git
)
套件
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录