Git入门指引

本文面向初次接触版本控制系统的Git用户,旨在介绍一些关于版本控制和Git的简单概念。

文中并不涉及过多的Git实际操作,文末推荐更多的Git学习资源。

导言

Git是目前最先进的版本控制系统,拥有最多的用户数量并管理着数量庞大的实际软件项目。风靡全球的Github更是让Git版本控制系统名声大震。本文以“版本控制系统”为切入点,介绍相关概念和简单的Git用法。

什么是版本控制系统?

如果对“版本控制”没有概念,那真是没法用Git。

所以我们来看一个例子:假设大四毕业生小张在写毕业论文,写好初稿后经常删改,甚至还会在第二天把前一天删掉的东西找回来。如果他动点脑子,就不会只在一个文档中改来改去,而会在文件夹中有:

毕业论文_初稿.doc
毕业论文_修改1.doc
毕业论文_修改2.doc
毕业论文_修改3.doc
毕业论文_完整版1.doc
毕业论文_完整版2.doc
毕业论文_完整版3.doc
毕业论文_最终版1.doc
毕业论文_最终版2.doc
……

看起来是不是很郁闷啊?小张当然也郁闷了,因为自己总是改不好,所以他把自己的论文发给女朋友(是学霸),求帮忙;与此同时他自己也在继续修改。第二天就有了:

毕业论文_最终版3.doc
毕业论文_女友版1.doc

他女友毕竟是学霸,当然给他的论文做了比较大的修改,此时小张虽然看到了希望,但还要纠结着做一件事情:把上面两个版本的论文合并成:

毕业论文_死也不改版.doc

等合并好,已是凌晨三点半。小张无比怨念:这样子真是没法和女友开心的玩耍了呢!

怎么办?

小张想,如果能有个什么东西来帮忙控制一下这该死的版本,那真是谢天谢地了!就像这样:

版本修改人说明日期
初稿小张这是初稿Day1
修改1小张修改目录Day2
修改2小张合并段落Day3
……………………
最终版2小张xxxDay7
死也不改版女友balabalaDay8

这样就不用手动控制那么多版本啦!

所以,所谓“版本控制系统”,就是来解决这类问题的。

Git又是什么?

没错,Git就是一个版本控制软件。在进行软件开发时,一个团队的人靠使用Git,就能轻松管理好项目版本,做好项目的追踪和辅助进度控制。确切的讲,Git是一款分布式版本控制系统。这个“分布式”,要和“集中式”放在一起理解。

所谓“集中式版本控制”,就好比这一个团队中,版本库都集中在一台服务器上,每个开发者都要从服务器上获取最新的版本库后才能进行开发,开发完了再把新的版本提交回去。

而“分布式版本控制”,则是这个团队中每个人的电脑上都会有一份完整的版本库,这样,你工作的时候,就不需要联网了,因为版本库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库,那多个人如何协作呢?比方说你在自己电脑上改了文件A,你的同事也在他的电脑上改了文件A,这时,你们俩之间只需把各自的修改推送给对方,就可以互相看到对方的修改了。

和集中式版本控制系统相比,分布式版本控制系统的安全性要高很多,因为每个人电脑里都有完整的版本库,某一个人的电脑坏掉了不要紧,随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题,所有人都没法干活了。

在实际使用分布式版本控制系统的时候,其实很少在两人之间的电脑上推送版本库的修改,因为可能你们俩不在一个局域网内,两台电脑互相访问不了,也可能今天你的同事病了,他的电脑压根没有开机。因此,分布式版本控制系统通常也有一台充当“中央服务器”的电脑,但这个服务器的作用仅仅是用来方便“交换”大家的修改,没有它大家也一样干活,只是交换修改不方便而已。

版本库是咋回事?

版本,不是文件的版本么?这个版本库是什么意思?

如果能意识到控制的是文件的版本,那就离理解版本库只差一步了(最关键的一步)。

程序要记录项目的版本号,最简单的方法就是把版本相关的信息放在某文件里,持续写入文件便视为版本更新。所以,当我们在一个目录中运行命令:

$ git init
# Git初始化的命令,用于新建版本库

这个目录中就会默认产生一个新目录:

.git/

没错,这就是我们刚刚新建的版本库,它将默认记录当前目录(直接包含.git的这个目录,下文中叫做“项目目录”)中任何文件的改动。如果把这个版本库删除了,这里面记录的文件版本就都没有了,项目目录中的文件当前是什么样子,那就一直是什么样子,没法恢复到以前的版本了。如果想让Git忽视项目目录中的什么文件(比如程序缓存等),可以在.gitignore中写清楚那些文件。

那么,Git怎么用?

在实际应用中,Git有非常多的用法,而本文是面向Git完全初学者,所以我们要从最基本的开始做。
比如,在刚才建好的版本库中,A新建了README文件,并在里面写了东西。写好后他想给项目做个版本,就需要这样:

$ git add README
$ git commit -m "add README"

第一个命令是告诉Git要追踪什么文件,第二个命令是进行提交,并对此次提交做个简答说明。当然,今后他再对README做什么修改,都可以这样做。Git会自动为此次提交生成一个16进制的版本号。

如果此时他查看本地的版本库,就会发现最新的一次提交是在刚才,提交说明为:add README

然后,他要把项目的版本库更新到Github上,当然这时候项目本身已经在Github上建立好了。他只需要:

$ git push origin master

这行命令应该这样理解:A已经在本地把项目最新的版本做好了,他要发到Github上,以便团队里其他人都能收到这个新的版本,于是他运行git push;push的目的地是origin,这其实是个名字,意义为该项目在Github上的地址;推送的是本地的master分支。

这个时候,Github上项目的版本号与A本地的最新版本号一致。

分支是版本控制里面的一个概念:在项目做大了之后,如果要在原基础上进行扩展开发,最好新建一个分支,以免影响原项目的正常维护,新的分支开发结束后再与原来的项目分支合并;而在一个项目刚开始的时候,大家一般会在同一个分支下进行开发.这是一种相对安全便捷的开发方式。

此时,小组里成员B对项目其他文件做了一些更改,同样也在本地做了一次提交,然后也想推到Github上面。他运行了git push origin master命令,结果发现提交被拒绝。这要做如何解释?

仔细想想,最开始的时候,A和B是在同一个版本号上做不同的更改,这就会分别衍生出两个不同的版本号。A先把自己的版本推到Github上,此时Github上的版本库与B本地版本库相比,差异很大,主要在于B这里没有A的版本记录,如果B这时把自己的版本强制同步到Github上,就会把A的版本覆盖掉,这就出问题了。

所以B进行了如下操作:

$ git pull

这样子,B先把Github上的版本库和自己的版本库做一个合并,这个合并的意义在于:B通过Github,把A刚才添加的版本加了进来,此时B本地的版本库是整个项目最新的,包括项目之前的版本、刚刚A添加的版本和B自己添加的版本。

这之后,B再次运行git push origin master,成功地把自己的版本推到了Github上。如果A想要推送新的版本,也要像B之前这样折腾一番才行。

还能再给力点么?

当然可以!

这里有两个在线代码托管平台:

还有一些优秀的Git在线资料:

最后还有一本不错的中文书籍:

不过,本文就要到此为止了,因为再往下写就会涉及更多更深的Git操作实践,而这些内容在上面给出的资料中已经整理好。

最后

本文的目的在于解决身边乃至更多开发者同时入门版本控制和Git时候遇到的困惑,希望能对各位初学者起到积极的作用。

如果您有更好的意见或建议,欢迎与我讨论:)

    原文作者:a0z
    原文地址: https://segmentfault.com/a/1190000000514886
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞