图解远程版本库开发周期 —— Git 学习笔记 22

拼搏现实的明天。 2022-04-14 05:53 192阅读 0赞

# 图解远程版本库开发周期 #

### 文章目录 ###

*  图解远程版本库开发周期
 *   *  克隆版本库
     *  快进推送
     *  非快进推送
     *  fetch 命令
     *  merge 命令
     *  push 命令
     *  参考资料

## 克隆版本库 ##

假设服务器上有一个简单的版本库：

![在这里插入图片描述][20181125111854342.png]  
最近的 2 次提交用 A 和 B 表示。

这时候，你把这个版本库克隆到了本地：

![在这里插入图片描述][2018112511194540.png]

克隆之后，我们看看这个克隆到本地的版本库都有些什么：

*  原始版本库中的所有提交都复制到克隆版本库。
 *  克隆版本库中有一个名为 `origin/master`的**远程追踪分支（ remote-tracking branch）**。
 *  在克隆版本库中， `origin/master`分支指向原始版本库中 master 指向的提交，也就是 B。
 *  克隆版本库中创建了一个新的**本地追踪分支（ local-tracking branch）**，称为 master 分支。这个 master 分支指向 `origin/master`指向的提交，也就是 B。

克隆后，Git 会选择新的 master 分支作为当前分支，并自动检出它。因此，除非切换分支，否则克隆后所做的任何修改都会影响 master 分支。

在图中，原始版本库和派生的克隆版本库中的开发分支都由深灰色作为背景色，而远程追踪分支则用浅灰色作为背景色。在 Git 的实现中，深灰色背景的分支属于 `refs/heads/` 命名空间，浅灰色背景的分支属于 `refs/remotes/`命名空间。

请注意，本地追踪分支和远程追踪分支都是**私有**的，并只存在于各自的版本库中。

## 快进推送 ##

在本地的 `master`分支工作的时候，本地的 `master` 会向前移动，而 **`origin/master` 是不可以移动的**。正如下图所示，你的开发使 `master` 分支变长了：在提交 B 的基础上多出 2 个新的提交 —— X 和 Y。

![在这里插入图片描述][20181125112233890.png]

在你开发期间，如果原始版本库没有任何变化，那么你可以很容易地把 X 和 Y 推送到上游：Git 会把你的提交传输到版本库，并把它们添加到 B 的后边，然后 Git 会对 master 分支执行一种特殊的合并操作 —— 快进（fast-forward），快进本质上是一个简单的线性历史记录推进操作。如下图所示：

![在这里插入图片描述][20181125112256684.png]

## 非快进推送 ##

但是，在你开发期间，任何其他有权访问原始版本库的开发人员可能已经做了进一步开发，并把他的修改推送到该版本库。如下图：

![在这里插入图片描述][20181125112316964.png]

在这种情况下，我们说版本库的历史记录在提交 B 处分叉（diverged 或 forked）了。当你尝试推送，Git 会拒绝并用一条错误消息告诉你有关的冲突，例如：

$ git push
        To /tmp/Depot/public_html
         ! [rejected]        master -> master (non-fast forward)
        error: failed to push some refs to '/tmp/Depot/public_html'

那么，什么是你真正想要做的？你是想覆盖其他人员的开发工作，还是想要合并两组历史记录？

> **提示**
> 
> 如果你想覆盖所有其他变化，也是可以的。只要在你的 `git push` 中使用 `-f`选项即可。不过我建议你不要这么做。

## fetch 命令 ##

更多的时候，你不想覆盖别人的提交，只是想添加你自己的修改。在这种情况下，你必须在推送之前在你的版本库中合并两组历史记录。这时候，就该 `fetch` 命令大显身手了。

要让 Git 合并两组历史记录，那么这两组历史记录**必须存在于同一个版本库的两个不同分支上**。现在你的提交 X 和 Y 本身就在你的版本库里，为了把 Origin 中的提交 C 和 D 纳入你的版本库，你可以用 `git fetch`命令进行抓取。这个命令会访问远程仓库，从中拉取所有你还没有的数据。

![在这里插入图片描述][20181125112355462.png]

注意，引入 C 和 D 这组历史记录并不能改变由 X 和 Y 代表的历史记录。所以，你没有必要担心 fetch 之后会覆盖你的工作成果。fetch 之后，这两组历史记录同时存在于你的版本库中，形成一幅比较复杂的图，简单来说就是在 B 处分叉了。你的历史记录由 master 分支代表，远程历史记录则由 origin/master 远程追踪分支代表。

## merge 命令 ##

既然这两组历史记录已经存在于一个版本库中了，那就整合它们吧。

> **提示**
> 
> 你不能把 master 分支合并到 origin/master 分支，因为 origin/master 是远程引用，远程引用是只读的。 虽然可以 git checkout 到某个远程引用，但是 Git 并不会将 HEAD 引用指向该远程引用。因此，你永远不能通过 commit 命令来更新远程引用。Git 将这些远程引用作为记录远程服务器上各分支最后已知位置状态的书签来管理。

所以，我们要做的就是把 origin/master 分支合并到 master 分支。

git merge origin/master

![在这里插入图片描述][20181125112414453.png]

假设合并过程很顺利，没有任何冲突，现在，你的版本库已经包含了 origin 版本库和你的版本库中的最新变更。但是反过来是不成立的：origin 版本库里依然没有你的变更。

## push 命令 ##

为了让其他人员共享你的变更，你可以用 git push 命令把合并后的历史记录从你的master 分支上推送回 origin 版本库。推送后如下图所示：

![在这里插入图片描述][20181125112431335.png]

最后，你可以看到 origin 版本库已经更新了你的开发，你的版本库和 origin 版本库已经完全更新并再次同步了。

【End】

## 参考资料 ##

《Git 版本控制管理（第2版）（人民邮电出版社）》

[20181125111854342.png]: /images/20220414/536e259fd3914afea2e718d558df1758.png
[2018112511194540.png]: /images/20220414/b97b5ab87f0346c89cdc797d8df2c088.png
[20181125112233890.png]: /images/20220414/705996b938984ad6ab9cad5da93643cf.png
[20181125112256684.png]: /images/20220414/dda0b18e6310484ab2a63a527c066041.png
[20181125112316964.png]: /images/20220414/68d2532e82b5448eb346337a3ff7652e.png
[20181125112355462.png]: /images/20220414/b373136fd5334acd80f6e10abd83d10c.png
[20181125112414453.png]: /images/20220414/13643d874a04483db1ac3d38bfc932e6.png
[20181125112431335.png]: /images/20220414/2abe1e292e284f0ab660e25eeed53442.png