修正补充
This commit is contained in:
@ -52,11 +52,11 @@ git remote rename <old-name> <new-name>
|
||||
|
||||
Git 被设计为给每个开发者提供完全隔离的开发环境。也就是说信息并不是自动地在仓库之间传递。开发者需要手动将上游提交拉取到本地,或手动将本地提交推送到中央仓库中去。`git remote` 命令正是将 URL 传递给这些「共享」命令的快捷方式。
|
||||
|
||||
#### 名为origin的远程连接
|
||||
#### 名为 origin 的远程连接
|
||||
|
||||
当你用 `git clone` 克隆仓库时,它自动创建了一个名为 origin 的远程连接,指向被克隆的仓库。当开发者创建中央仓库的本地副本时非常有用,因为它提供了拉取上游更改和发布本地提交的快捷方式。这也是为什么大多数基于 Git 的项目将它们的中央仓库取名为 origin。
|
||||
|
||||
#### 仓库的URL
|
||||
#### 仓库的 URL
|
||||
|
||||
Git 支持多种方式来引用一个远程仓库。其中两种最简单的方式便是 HTTP 和 SSH 协议。HTTP 是允许匿名、只读访问仓库的简易方式。比如:
|
||||
|
||||
|
||||
@ -80,7 +80,7 @@ rebase 的主要目的是为了保持一个线性的项目历史。比如说,
|
||||
|
||||
rebase 是将上游更改合并进本地仓库的通常方法。你每次想查看上游进展时,用 `git merge` 拉取上游更新会导致一个多余的合并提交。在另一方面,rebase 就好像是说「我想将我的更改建立在其他人的进展之上」。
|
||||
|
||||
#### 不要rebase公共历史
|
||||
#### 不要 rebase 公共历史
|
||||
|
||||
和我们讨论过的 `git commit --amend` 和 `git reset` 一样,你永远不应该 rebase 那些已经推送到公共仓库的提交。rebase 会用新的提交替换旧的提交,你的项目历史会像突然消失了一样。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user