。

文件添加、状态检查、创建注释和查看历史记录。

与其他Git版本库交互#xff08;pull、push#xff09;。

解决合并冲突。

创建分支列表、列表切换和合并。

创建标签。

搭建Git环境和创建Git版本库init、clone。

文件添加、状态检查、创建注释和查看历史记录。

与其他Git版本库交互pull、push。

解决合并冲突。

创建分支列表、列表切换和合并。

创建标签。

1、版本控制与Git

版本控制系统有时也称修订控制是一种用户可以根据时间追溯项目文件存放于版本库中修改历史和属性的工具它还可以帮助团队成员协作开发。

当前流行的版本控制系统可以为每个开发人员提供专属的沙箱防止他们的工作发生冲突同时采用冲突合并和同步机制实现以非阻塞的方式进行高效协作。

像Git这类分布式版本控制系统为每个用户提供专属于其自己的项目历史副本、版本库的副本。

Git系统如此高效的原因有以下几个

首先几乎所有操作都是在用户本机上执行而且非常灵活其次你可以使用多种方式建立版本仓库。

版本仓库对于开发来说意味着每个开发人员都有整个项目文件的独立工作区也称工作目录。

Git采用的分支模型支持本地分支而且分支的发布也非常灵活用户可以使用分支进行内容切换还可以在开发过程中将不同工作放置于相互隔离的沙箱中有可能构建出独立、灵活的主题分支工作流。

事实上版本库的整个变更历史都是可以访问的用户可以撤销或者回退更改过的内容到最后一个工作版本等。

当每个修改被提交之后用户的修改提交记录也被记录下来因此提交代码修改的用户也就很容易被定位。

你还可以比较文件的不同版本将代码回退到某个用户提交bug报告之前的版本甚至可以知道哪个版本的变更导致了上述bug。

其实Git主要是通过reflog命令来跟踪分支的变更记录信息并实现回退和覆盖目的的。

Git有一个独特的功能是它支持显式访问暂存区以便创建注释对项目进行新的修订。

这为用户管理工作区和确定将来的注释信息带来了更多灵活性。

所有这些灵活、强大的特性都是要付出代价的。

虽然掌握Git的基本使用非常简单但是精通Git的使用并不是那么容易。

让我们先来回顾一下Git的基本使用。

2、Git简易示例

让我们通过两个开发人员在一个简单项目上使用Git进行协作开发来一步一步地构建一个简单示例。

2.1、创建版本库

某公司准备研发一款新产品。

该产品主要的用途是从特定区间内随机获取若干个整数。

该公司指派了两名开发人员负责这个新项目他们的名字分别是Alice和Bob。

两名远程办公的开发人员经过和公司领导协商之后决定使用C语言开发一套命令行应用来完成该产品的研发并且使用Git

2.5.0http://git-scm.com/进行程序代码版本控制管理。

该产品的用途主要是用来进行过程演示的而且也非常简单。

程序代码的细节并不是重点我们关注的是如何管理代码变更。

2.2、创建Git版本库

Alice在项目启动时请求管理员Carol为她创建一个新的版本库以方便团队协作。

命令行示例遵循的是UNIX系统风格命令行前面的提示信息由“用户名主机名/文件是什么。

上述风格在UNIX环境中很常见在Linux系统下也是如此。

carolserver

random.git你还可以使用工具来管理Git的版本库例如Gitolite在服务端创建一个版本库也许看上去会稍有不同。

通常情况下是使用git

init不带“–bare”参数命令创建版本库然后根据特定的URL地址将其推送到服务端执行上述操作之后服务端会自动创建一个公共版本库。

或者也可以使用带Web接口工具的网站创建该版本库例如GitHub、Bitbucket和GitLab可以托管或内部部署。

2.3、克隆版本库并添加注释

因为这是他在本项目中首次使用Git因此他在自己的版本库根目录下建立了对应的/.gitconfig文件该文件主要是用来帮助他标记日志文件中特定的注释信息

[user]name

random$Bob注意到Git系统提示说这是一个空的版本库还没有代码文件所以他开始编写代码了。

他打开了文本编辑器为本项目创建了第一版代码程序

#include

}一般来说和大部分原始程序实现类似该程序还非常简陋。

不过这是一个很好的开端。

在提交代码之前Bob希望这个程序可以通过编译并能够运行

bobhostB

random.cBob使用“status”命令来确保先前的所有修改都没什么问题

bobhostB

a.outGit系统显示了警告信息因为它不知道该如何处理a.out文件它既没有在跟踪列表中也没有在忽略列表中。

它是编译过程中生成的可执行体不应该存放于版本库中。

Bob可以暂时不用理会这个提示信息。

现在向服务端提交commit该代码文件

在完成项目的初始版本之后Bob准备发布它们提交到服务器供团队其他成员访问。

他将自己的工作成果推送到了服务端

bobhostB

https://git.company.com/random*

[new

simpleGit会根据用户的网络速度显示诸如clone、push和fetch操作的具体进度。

2.5、查看历史版本

因为这是Alice第一次在她的个人电脑上使用Git因此她必须告诉Git系统如何识别她提交的注释

alicehostA

alicecompany.com现在Alice需要建立专属于她自己的版本库实例

alicehostA

random.c.git目录下包含Alice的版本库的拷贝克隆并且这些文件是以Git内部格式存在的同时还包含一些针对版本库的管理信息。

alicehostA

2b953b4e80abfb77bdcd94e74dedeeebf6aba870

Author:

implementation在最底层实现中Git历史版本识别是通过一个SHA-1哈希码实现的例如2b953b4e80。

Git支持多种形式的版本查询其中就包括SHA-1码精确匹配最少提供4个字符。

当Alice决定浏览一遍代码时她突然发现了一个严重的问题随机数生成部分一直都没有初始化她经过一个快速测试发现程序生成的结果都是同一个数。

幸运的是她并不需要修改main()内部的代码只需要在顶部加入相应的#include引用即可

#include

atoi(argv[1]);srand(time(NULL));int

result

}改完代码之后她运行了几次程序来确认程序真的可以生成随机数。

一切似乎都进行得很顺利。

她使用git

alicehostA

random.c不必感到大惊小怪。

Git知道random.c文件被修改了。

然后Alice使用git

alicehostA

https://git.company.com/random3b16f17..db23d0e

master

Bob接下来的工作是重构工作区文件太多所以他决定将所有源代码文件移动到“src/”子目录下

bobhostA

(100%)现在他为了确保目录重构之后使用“diff”命令输出结果的差异不至于太大将Git系统配置为始终执行重命名和拷贝的检测

bobhostB

copiesBob觉得是时候为项目添加一个合适的Makefile配置文件以及一个README帮助文件了

bobhostA

READMEBob将“random.c”文件的名字改为“rand.c”

bobhostA

src/rand.c上述操作当然也需要修改Makefile文件

bobhostA

https://git.company.com/random!

[rejected]

details.但是Alice同时也在这个项目中工作而且她已经向服务端推送了自己的代码。

Git系统现在不允许Bob推送他对项目代码的变更因为Alice已经推送了一些内容到master分支上系统会保护她提交的变更。

Bob使用“pull”命令将服务端版本库的内容与自己的版本库同步像命令行提示信息建议的那样

bobhostB

insertions()执行“pull”命令之后Git系统会将服务端版本库中的变更下载到Bob本机然后自动将它们和Bob本机版本库的变更合并最后把合并后的变更提交到本机版本库中。

bobhostB

ba5807e44d75285244e1d2eacb1c10cbc5cf3935

Merge:

https://git.company.com/random合并后的提交也完成了。

Git系统可以直接将Alice提交的变更与Bob移动或重命名后的文件合并是不是很神奇呢

Bob检查编译因为自动合并之后并不能绝对保证代码没问题了一下变更合并后的代码准备将合并变更后的代码推送到服务端

bobhostB

https://git.company.com/randomdb23d0e..ba5807e

master

Alice和Bob认为项目可以进行更大范围的发布了。

Bob创建了一个标签tag以便日后他们方便地访问/引用发布过的预览版本。

他为此使用了一个带注释的标签当然大家一般采用的替代性方案是使用带数字签名的标签该标签通常会包含一个PGP数字签名以后的验证需要用到它

bobhostB

https://git.company.com/random当然v0.1版的标签如果只放在Bob本地的版本库中是没有什么意义的。

接下来他将刚创建的标签推送到服务端

bobhostB

v0.1Alice为了获得这个标签更新了她的版本库然后开始了她的日常工作

alicehostA

https://git.company.com/randomf4d9753..be08dee

master

Alice认为将生成伪随机数功能修改成一个单独的子程序是个好主意。

这样一来初始化和生成随机数的功能都独立封装起来了将来需求变更的时候更容易实现一些。

她决定给程序添加一个init_rand()函数

void

同时Bob在与rand()函数相关的开发文档中发现它是用来生成简单的伪随机数的标准函数可能并不能满足实际需要

bobhostB

up-to-date.他决定在提交代码变更的注释中添加对此问题的备注说明

bobhostB

https://git.company.com/randomba5807e..8c4ceca

master

master因此当Alice准备推送她的变更到服务端时Git系统拒绝了该操作

alicehostA

https://git.company.com/random!

[rejected]

[...]Bob一定是推送了不少变更到服务端。

Alice需要再次从服务端的版本库上下载最新版本的项目文件然后亲自把自己的变更和Bob的变更合并

alicehostA

https://git.company.com/randomba5807e..8c4ceca

master

result.该合并操作并没有像上次那样被顺利执行。

Git系统无法自动合并Alice和Bob两人提交的变更。

显然文件变更之间有冲突。

Alice决定用文本编辑器打开文件“src/rand.c”一探究竟她也可以使用图形化的合并工具查看代码差异

HEAD

generator8c4ceca59d7402fb24a672c624b7ad816cf04e08

int

max)Git系统中现在既有Alice提交的代码变更在HEAD和

之间。

我们希望的结果是将两人的代码融为一体。

Git系统无法自动合并它们因为这些代码块并不是独立的。

Alice的init_rand()函数可以简单地插入Bob添加的代码注释之前。

执行上述操作之后结果如下

alicehostA

max;这样冲突应该就可以解决了。

Alice重新编译运行了一下程序然后提交了这一变更

alicehostA

https://git.company.com/random8c4ceca..493e222

master

Bob打算给项目添加一个和版权声明有关的COPYRIGHT文件当然还打算添加一个记录软件新特性的文件不过还没有创建所以他使用批处理命令添加了工作区中的所有文件到版本库中

bobhostB

COPYRIGHT~因为Bob没有配置的忽略模式因此作为备份文件的“COPYRIGHT”也被提交到了版本库。

接下来我们移除该文件

bobhostB

百无聊赖之际Bob决定调整一下文件rand.c的代码缩进格式使之符合统一的命名规范。

bobhostB

deletions(-)样式调整的变更太多了对于如此小的文件来说在合并时可能会出问题。

Bob冷静了一下然后撤销了对文件rand.c的样式调整

bobhostB

-s如果你不记得如何回退一个特定类型的变更或者更新某个已提交的变更使用不带“-a”参数的命令“git

commit”执行“git

status”命令不带“-s”参数后的输出结果会包含如下所示的帮助信息

bobhostB

Alice注意到代码中取模运算返回给定区间内随机数的分布并不是均匀的因为大部分情况下返回的都是较小的数。

她打算修复这个问题。

为了将相关的开发工作和代码中的其他变更隔离她决定在自己的版本库中创建一个新分支然后切换到该分支

alicehostA

better-random”命令创建一个新分支然后使用命令切换到该分支之外她还可以首先使用“git

branch

better-random”命令创建一个新分支然后使用“git

checkout

她决定使用RAND_MAX常量控制rand()函数生成随机数的范围。

相关的代码修改如下

alicehostA

*argv[])她提交了上述代码变更然后将它们推送到了服务端她知道上述推送操作可以顺利执行因为这些操作都是在她的私有分支上进行的

alicehostA

better-random通过上述信息可以知道Git系统希望Alice为她新创建的分支它采用的推送策略是simple模式在远程版本库中添加对应的上游分支这样可以让分支推送到远程分支的目标更明确。

alicehostA

https://git.company.com/random*

[new

better-random如果她希望更直观地管理她自己的分支结构并且只对自己可见那么她需要配置好与服务端的相关映射或者使用诸如Gitolite之类Git版本库管理软件来管理自己的分支。

2.13、合并分支无冲突

与此同时在默认的主分支下Bob打算推送自己给项目添加COPYRIGHT文件的变更

bobhostB

https://git.company.com/random!

[rejected]

[…]出现上述错误提示是因为Alice当时正在忙着将初始化生成随机数的部分代码封装为一个子程序解决合并冲突她首先向服务端版本库推送了自己的变更

bobhostB

https://git.company.com/random8c4ceca..493e222

master

deletion(-)Git系统可以轻松地将Alice推送的变更合并但是现在出现了一个新分支。

接下来我们来看看具体细节。

为了节省篇幅下文只显示和该新分支“better-

bobhostB

bb71a804f9686c4bada861b3fcd3cfb5600d2a47

Author:

rescaling有趣的是Bob希望从服务端获取Alice创建的新分支然后合并到自己的版本库的默认分支下该新分支在远程版本库上已经存在

bobhostB

Bob意识到何时将该特性添加到主分支中应该由Alice来做决定。

他打算撤销上述合并操作。

因为这些变更还没有发布因此只需要简单地将自己的本地主分支回退到上一次提交的变更状态即可

bobhostB

random本示例演示了使用日志引用reflog机制实现变更回退操作。

另外一种解决方案是使用“HEAD^”代替“{1}”这样也可以实现同样的效果。