《Git学习指南》——2.3 Git的协作功能

简介: 现在,我们已经有了一个存放项目文件的工作区,以及一个存放项目历史的版本库。在一个像CVS和Subversion这样传统的集中式版本系统中,尽管每个开发者也都有属于他/她自己的工作区,但所有人都共享了一个通用的版本库。

本节书摘来自异步社区《Git学习指南》一书中的第2章,第2.3节,作者: 【德】René Preißel(普莱贝尔) , Bjørn Stachmann(斯拉赫曼)著,更多章节内容可以访问云栖社区“异步社区”公众号查看

2.3 Git的协作功能

现在,我们已经有了一个存放项目文件的工作区,以及一个存放项目历史的版本库。在一个像CVS和Subversion这样传统的集中式版本系统中,尽管每个开发者也都有属于他/她自己的工作区,但所有人都共享了一个通用的版本库。而在Git中,每个开发者拥有的是一个属于他/她自己的、自带独立版本库的工作区,因此这已经是一个不依赖于中央服务器的、完整的版本控制系统了。开发者们可以通过交换各自版本库中的提交来实现项目合作。下面我们就来做个试验,先创建一个新的工作区,以便我们模拟第二位开发者的活动。

2.3.1 克隆版本库
我们的这位新开发者首先要有一个属于他/她自己的版本库副本(也称为克隆体)。该副本中包含了所有的原始信息与整个项目的历史信息。下面。我们用clone命令来创建一个克隆体。

> git clone /projects/first-steps /projects/first-steps-clone
Cloning into first-steps-clone... 
done.

现在,该项目结构如图2.4所示。

screenshot

图2.4 样例项目与它的克隆体

2.3.2 从另一版本库中获取修改
下面,我们来修改一下first-steps/foo.txt文件,并执行以下操作来创建一次新提交。

> cd /projects/first-steps 
> git add foo.txt 
> git commit --message "A change in the original."

现在,新的提交已经被存入了我们原来的first-steps版本库中,但其克隆版本库(first-stepsclone)中依然缺失这次提交。为了让你更好地理解这一情况,我们来看一下first-steps的日志。

> git log --oneline 
a662055 A change in the original. 
7ac0f38 Some changes. 
2f43cd0 Sample project imported.

在接下来的步骤中,我们再来修改克隆版本库中的first-steps-clone/bar.html文件,并执行以下操作。

> cd /projects/first-steps-clone 
> git add bar.html 
> git commit --message "A change in the clone." 
> git log --oneline 
1fcc06a A change in the clone. 
7ac0f38 Some changes. 
2f43cd0 Sample project imported.

现在,我们在两个版本库中各做了一次新的提交。接下来,我们要用pull命令将原版本库中的新提交传递给它的克隆体。由于之前我们在创建克隆版本库时,原版本库的路径就已经被存储在了它的克隆体中,因此pull命令知道该从哪里去取回新的提交。

> cd /projects/first-steps-clone 

> git pull 

remote: Counting objects: 5, done. 
remote: Compressing objects: 100% (2/2), done. 
remote: Total 3 (delta 0), reused 0 (delta 0) 
Unpacking objects: 100% (3/3), done. 
From /projects/first-steps
   7ac0f38..a662055 master -> origin/master 
Merge made by recursive.  
foo.txt |      2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

如上所示,pull命令从原版本库中取回了新的修改,将它们与克隆体中的本地修改进行了对比,并在工作区中合并了两边的修改,创建了一次新的提交。这个过程就是所谓的合并(merge)。

请注意!合并过程在某些情况下可能会带来冲突。一旦遇到了这种情况,Git中就不能进行自动化的版本合并了。在这种情况下,我们就必须要手动清理一些文件,然后再确认要提交哪些修改。

在拉回(pull)、合并(merge)的过程完成之后,我们可以用一个新的log命令来查看结果。这次是日志的图形化版本。

> git log --graph 
9e7d7b9 Merge branch ’master’ of /projects/first-steps 
* 
|\ 
| * a662055 A change in the original. 
* | 1fcc06a A change in the clone. 
|/ 
* 7ac0f38 Some changes. 
* 2f43cd0 Sample project imported.

这一次,历史记录不再是一条直线了。在上面的日志中,我们可以很清晰地看到并行开发的过程(即中间的两次提交),以及之后用于合并分支的那次合并提交(即顶部的那次提交)。

2.3.3 从任意版本库中取回修改
在没有参数的情况下,pull命令只在克隆版本库中能发挥作用,因为只有该克隆体中有默认的原版本库的连接。当我们执行pull操作时,也可以用参数来指定任意版本库的路径,以便从某一特定开发分支中提取相关修改。

现在,让我们将克隆体中的修改pull到原版本库中吧。

> cd /projects/first-steps 
> git pull /projects/first-steps-clone master 
remote: Counting objects: 8, done. 
remote: Compressing objects: 100% (4/4), done. 
remote: Total 5 (delta 0), reused 0 (delta 0) 
Unpacking objects: 100% (5/5), done. 
From /projects/first-steps-clone
 * branch           master →  FETCH_HEAD
Updating a662055..9e7d7b9 
Fast-forward  
bar.html |    2 +-  
1 files changed, 1 insertions(+), 1 deletions(-)

2.3.4 创建共享版本库
除了可以用pull命令从其他版本库中取回相关提交外,我们也可以用push命令将提交传送给其他版本库。只不过,push命令只适用于那些没有开发者在上面开展具体工作的版本库。最好的方法就是创建一个不带工作区的版本库,我们称之为裸版本库(bare repository)。你可以使用clone命令的--bare选项来创建一个裸版本库。裸版本库通常可被用来充当开发者们传递提交(使用push命令)的汇聚点,以便其他人可以从中拉回他们所做的修改。下面我们来看一个裸版本库(见图2.5)。

screenshot

图2.5 裸版本库(一个没有工作区的版本库)

> git clone --bare /projects/first-steps 
                       /projects/first-steps-bare.git
Cloning into bare repository first-steps-bare.git... 
done.

2.3.5 用push命令上载修改
为了演示push命令的使用,我们需要再次修改一下firststeps/foo.txt文件,并执行以下操作来创建一次新的提交。

> cd /projects/first-steps 
> git add foo.txt 
> git commit --message "More changes in the original."

接下来,我们就可以用push命令向共享版本库传送该提交了(见图2.6)。该指令的参数要求与pull命令相同,我们需要指定目标版本库的路径及其分支。

> git push /projects/first-steps-bare.git master 
Counting objects: 5, done. 
Delta compression using up to 2 threads. 
Compressing objects: 100% (2/2), done. 
Writing objects: 100% (3/3), 293 bytes, done. 
Total 3 (delta 0), reused 0 (delta 0) 
Unpacking objects: 100% (3/3), done. 
To /projects/first-steps-bare.git/ 
    9e7d7b9..7e7e589 master -> master

screenshot

图2.6 经由共享版本库来进行版本共享

2.3.6 Pull命令:取回修改
现在,为了让克隆版本库也得到相应的修改,我们需要在执行pull命令时配置参数指向共享版本库的路径参数。

> cd /projects/first-steps-clone 

> git pull /projects/first-steps-bare.git master 

remote: Counting objects: 5, done. 
remote: Compressing objects: 100% (2/2), done. 
remote: Total 3 (delta 0), reused 0 (delta 0) 
Unpacking objects: 100% (3/3), done. 
From ../first-steps-bare 
 * branch      master      -> FETCH_HEAD 
Updating 9e7d7b9..7e7e589 
Fast-forward 
 foo.txt |    2 +- 
 1 files changed, 1 insertions(+), 1 deletions(-)

请注意!如果另一个开发者在我们之前已经做过一次push操作,此次push命令就会被拒绝传送提交。这时候,我们必须要先做一次pull操作,将其他人新上载的更新取回,并在本地合并。

相关文章
|
20天前
|
项目管理 开发工具 git
Python面试题:Git版本控制与协作开发
【4月更文挑战第19天】本文聚焦于Python面试中Git版本控制与协作开发的考察点,涵盖Git基础、协作流程及实战示例。面试者需理解仓库、提交、分支等核心概念,掌握常用命令,熟悉主干开发和GitFlow策略。在协作开发中,要掌握Pull Request工作流,有效处理合并冲突,并善用标签与里程碑。注意避免混淆工作区、忽视代码审查和直接在远程分支上工作等常见错误。通过实例展示了如何在GitFlow策略下合并分支和解决冲突,强调持续学习与实践以提升Git技能。
25 1
|
4月前
|
存储 前端开发 开发工具
前端开发中的Git版本控制:构建可靠的协作和代码管理
前端开发中的Git版本控制:构建可靠的协作和代码管理
51 0
|
17天前
|
存储 项目管理 开发工具
Git 版本控制:构建高效协作和开发流程的最佳实践
版本控制是软件开发的核心,促进团队协作与项目管理。通过制定明确的分支命名策略,遵循一致的代码提交规范,如指明提交类型和简短描述,增强了历史记录的可读性,可以清晰地组织和理解项目的结构与进展。
20 0
Git 版本控制:构建高效协作和开发流程的最佳实践
|
7月前
|
Shell 开发工具 git
[笔记]Git 介绍以及入门基本功能(一)
[笔记]Git 介绍以及入门基本功能
|
3月前
|
存储 开发工具 git
Git工作流程:如何在团队中协作?
Git工作流程:如何在团队中协作?
|
5月前
|
存储 前端开发 Linux
前端开发中的Git版本控制:构建可靠的协作和代码管理
前端开发中的Git版本控制:构建可靠的协作和代码管理
56 1
|
7月前
|
Shell 开发工具 git
[笔记]Git 介绍以及入门基本功能(二)
[笔记]Git 介绍以及入门基本功能(二)
|
9月前
|
JavaScript Linux BI
对于git功能的探索与研究(三)
对于git功能的探索与研究(三)
73 0
|
9月前
|
缓存 开发工具 git
对于git功能的探索与研究(二)
对于git功能的探索与研究(二)
50 0
|
9月前
|
Linux Shell 开发工具
对于git功能的探索与研究(一)
对于git功能的探索与研究
53 0

相关实验场景

更多