Git 使用指南之初识
在日常项目开发中,我们肯定会或多或少地听说或者使用过 版本管理工具。之前我刚好有幸参与过公司项目版本管理—–SVN 版本控制系统的搭建与管理,再加上项目组日常项目开发使用 SVN,也就没有花费太多精力去学习其它版本管理工具。
初次接触 Git 还是因为常常会从 GitHub clone 一些大佬们开源的深度学习项目以供学习和借鉴,但对 Git 的使用仅限于:git clone XYZ(脸红)。而随着身边越来越多的人开始使用 Git,以及学习和工作需要,才发现:这年头不会点 Git 是真不行啊…
版权说明: 本文思路以及内容主要来自廖雪峰老师的 Git 教程 (强烈推荐膜拜原文),并结合个人使用所作,只作为学习记录使用。如内容有侵权请联系删除,禁止转载!
更多 Git 相关内容,请关注博主 Git 博文系列:
之五 >>> Git 使用指南之 WorkFlow (工作流)
Git 简介
和 SVN 类似,Git 也是用于版本控制。Git 是时下最流行的分布式版本控制系统,没有之一。
何为版本控制?
我们一直在说版本控制,那么究竟什么是版本控制?
其实说到版本控制,我总会想到大学毕业写论文时的场景,你电脑上的毕业论文一定也出现过和我一样的场景:
以上就是使用最原始的方式进行版本控制,可以发现 存在着显著缺点:
- 当保留所有版本文件时,需要为每个版本保存一个文件…
- 当文档需要多人协同操作时,需要将文件打包发来发去,拿到后还需要修改整合…
- 容易丢失,被删除意味着永远失去…
为了解决以上版本控制存在问题,应运而生了一批版本控制系统或工具:VSS、CVS、SVN、Git 等,其中 Git 已经成为当前最流行的分布式版本控制系统。通过使用这些版本控制工具,你就结束了手动管理多个 “版本” 的史前时代,进入到版本控制的新世纪。
通过以上样例的解读,下面我们给出关于版本控制更加严格的解读:
版本控制是指对软件开发过程中各种程序代码、配置文件、以及说明文档等文件变更的管理。
通俗来说 >>>
版本控制最主要的功能就是追踪文件的变更。它将什么时候、什么人更改了文件的什么内容等信息忠实地了记录下来。每一次文件的改变,文件的版本号都将增加。这些功能均由版本控制系统帮忙维护。
除了记录版本变更外,版本控制的另一个重要功能是并行开发。软件开发往往是多人协同作业,版本控制可以有效地解决版本的同步以及不同开发者之间的开发通信问题,提高协同开发的效率。
Example >>>
例如使用 Git 版本控制工具我们可以清晰、便捷的管理文档的不同版本,如下图所示:
Git 的诞生
我们知道,Linux 是开源的代名词,Linux 的系统日益壮大是靠全世界热心的志愿者共同参与的,这么多人在世界各地为 Linux 编写代码,那 Linus(Linux 项目发起者) 的代码是如何管理整合的呢?
事实是,起初世界各地的志愿者把源代码文件发给 Linus,然后由 Linus 本人通过手工方式合并代码!
你也许会想,为什么 Linus 不把 Linux 代码放到现有的版本控制系统里呢?不是有 CVS、SVN 这些免费的版本控制系统吗?因为 Linus 坚定地反对 CVS 和 SVN,这些集中式的版本控制系统不但速度慢,而且必须联网才能使用。有一些商用的版本控制系统,虽然比 CVS、SVN 好用,但那是付费的,这和 Linux 的开源精神不符。
不过,随着 Linux 系统的不断发展,代码库之大让 Linus 很难继续通过手工方式管理了,社区的弟兄们也对这种方式表达了强烈不满,于是 Linus 选择了一个商业的版本控制系统 BitKeeper,BitKeeper 的东家 BitMover 公司出于人道主义精神,授权 Linux 社区免费使用这个版本控制系统。
没几年,这种安定团结的大好局面就被打破了。原因是 Linux 社区牛人聚集,不免沾染了一些梁山好汉的江湖习气。开发 Samba 的 Andrew 试图破解 BitKeeper 的协议(这么干的其实也不只他一个),被 BitMover 公司发现了(监控工作做得不错!),于是 BitMover 公司怒了,要收回 Linux 社区的免费使用权。
Linus 可以向 BitMover 公司道个歉,保证以后严格管教弟兄们…… 嗯,这是不可能的。实际情况是这样的:Linus 花了两周时间自己用 C 写了一个分布式版本控制系统,这就是 Git!一个月之内,Linux 系统的源码已经由 Git 管理了!牛是怎么定义的呢?大家可以体会一下。
Git 迅速成为最流行的分布式版本控制系统 。尤其是 GitHub 的上线,它为开源项目免费提供 Git 存储,无数开源项目开始迁移至 GitHub。
GitHub 是一个基于 Git 的远程文件托管平台。Git 本身完全可以做到版本控制,但其所有内容以及版本记录只能保存在本机。如果想要将文件内容以及版本记录同时保存在免费远程服务器,则需要结合 GitHub 来使用。
集中式 VS 分布式
Linus 一直痛恨的 CVS、SVN 都是集中式的版本控制系统,而 Git 是分布式版本控制系统,集中式和分布式版本控制系统有什么区别呢?
集中式版本控制系统
先说集中式版本控制系统,都有一个单一的集中管理的中央服务器,保存所有的项目版本库。而协同工作的人们首先都需要通过客户端连到这台中央服务器取出最新的文档版本进行修改,修改完成后需要提交更新给中央服务器完成服务器上的修改。 多年以来,这已成为版本控制系统的标准做法。
集中式版本控制系统缺点在于:中央服务器的单点故障。
如果中央服务器宕机一小时,那么在这一小时内,谁都无法提交更新,也就无法协同工作。 如果中心数据库所在的磁盘发生损坏,又没有做恰当备份,毫无疑问你将丢失所有数据————包括项目的整个变更历史,只剩下人们在各自机器上保留的单独快照。
只要整个项目的历史记录被保存在单一位置,就有丢失所有历史更新记录的风险。
分布式版本控制系统
那分布式版本控制系统与集中式版本控制系统有何不同呢?
首先,分布式版本控制系统根本没有“中央服务器”,每个人的电脑上都是一个完整的版本库。这也导致和集中式版本控制系统相比,分布式版本控制系统的安全性要高很多,因为每个人电脑里都有完整的版本库,某一个人的电脑坏掉了不要紧,随便从其他人那里复制一个就可以了。
既然每个人电脑上都有一个完整的版本库,那多个人如何协作呢?当然可以相互之间进行推送,但在实际使用分布式版本控制系统时通常也有一台充当“中央服务器”的角色(服务器),但这个服务器的作用仅仅是用来方便 “交换” 大家的修改,没有它大家也一样干活,只是交换修改不方便而已。
当然,Git 的优势不单是分布式这么简单,后面我们还会看到 Git 极其强大的分支管理,把 SVN 等远远抛在了后面。
Git Setup
最早 Git 是在 Linux 上开发的,很长一段时间内,Git 也只能在 Linux 和 Unix 系统上跑。
目前,Git 已经为 Linux、Unix、Mac 和 Windows 等多平台提供了支持。这一部分我们来看如何在不同平台下完成 Git 的安装:
Setup For Linux
Linux 平台下,Centos && Ubuntu OS 中 Git 的安装过程。
- Centos
- Ubuntu
- Others Linux OS
Centos Setup Methods
Centos 中提供了两种 Git 的安装方法:
- YUM Method
- Source Code Method(Recommended)
YUM Method For Centos Git Setup
Cnetos 中采用 yum 的方法进行 Git 安装的详细过程如下:
推荐使用源码方式进行 Centos 下 Git 的安装,这是由于 Git 的安装版本完全取决于 yum 源中支持的 Git 版本(一般要比最新发布 Git 版本低),你可以选择直接跳至下一部分。
1 -> 检测系统是否安装有 Git
1 | git |
如果系统已安装 Git,你可以使用 git --version
查看相应的安装版本,确定是否需要重新安装 Git(一般 Centos 系统 Git 版本较低,以 Centos7 为例为:git version 1.8.3.1)。这里我们给出 GitHub 上的 Git 版本发布界面,你可以查看最新的 Git 版本。
如果未安装有合适版本 Git,则继续执行下面步骤:
2 -> Git 安装
登陆待安装服务器,输入如下命令进行下载安装:
1 | yum install git |
接着服务器会询问是否进行安装,输入 y,然后等待安装完成即可(接上):
1 | # 日志信息如下: |
3 -> 验证安装是否成功
输入命令: git --version
,查看安装好的 Git 版本,验证是否安装成功:
1 | [root@node3 ~]# git --version |
接下来来看,Centos 中采用 源码包 的方法进行 Git 安装的详细过程:
Source Code Method For Centos Git Setup(Recommended)
我们会发现,使用 yum 安装之后 Git 版本和当前最新版本之间仍然差很多版本号(Git 版本号不太好控制,取决于系统中 yum 源中最新 Git 版本),那么如何解决这个问题?
除了使用 yum 安装,还可以使用 Git 源码进行编译安装,我们可以根据需要下载相应版本的 Git 源码包进行安装(源码下载请前往:Git 版本发布界面)。下面我将给出 Centos7 下如何通过源码安装 Git v2.20.0:
安装前我们首先需要移除系统原有 Git:
1 | [root@node3 Download]# yum remove git |
1 -> 在目录 Download 中下载相应 Git 版本源码包:
1 | [root@node3 Download]# wget https://github.com/git/git/archive/v2.20.0.tar.gz |
2 -> 解压 v2.20.0.tar.gz 安装包:
1 | [root@node3 Download]# tar -zxvf v2.20.0.tar.gz |
3 -> 准备编译环境,否则后续安装可能发生 Error:
1 | [root@node3 Download]# yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel gcc perl-ExtUtils-MakeMaker |
4 -> 进入解压文件目录 git-2.20.0,然后进行 Git 源码的配置、编译以及安装命令,耐心等待即可:
1 | [root@node3 Download]# cd git-2.20.0 |
5 -> 配置环境变量:
1 | 打开系统配置文件:/etc/profile |
6 -> 验证安装是否成功:
1 | [root@node3 Download]# git --version |
Ubuntu Setup Methods
较新版本的 Debian 或 Ubuntu Linux 系统一般都自带较高版本的 Git。如果没有,直接可通过下列命令就可以完成 Git 的安装:
1 | sudo apt-get install git |
老一点的 Debian 或 Ubuntu Linux,要把命令改为:
1 | sudo apt-get install git-core |
这是由于:有个软件也叫 GIT(GNU Interactive Tools),结果 Git 就只能叫 git-core 了。由于 Git 名气实在太大,后来就把 GNU Interactive Tools 改成 gnuit,git-core 正式改为 git。
Other Linux OS Setup Methods
其它版本 Linux
可以统一采用源码安装,具体安装方法不一一列出,使用时请自行百度。
Setup For Windows
这一部分我们来看 Win 平台下如何安装和配置 Git(未提到安装页面选择默认即可):
Setup Tips
1 -> 从 Git 官网下载一个 Git For Windows 安装包(官网下载地址,这里我们再提供一个 国内下载站点):
2 -> 双击安装程序,进入欢迎界面阅读协议,然后点击 【 Next 】:
3 -> 选择 Git 安装位置,点击 【 Next 】:
4 -> 选择安装组件:推荐使用默认选项,然后点击 【 Next 】:
- 图标组件(Additional icons):选择是否创建快速启动图标和桌面快捷方式
- 桌面浏览(Windows Explorer integration)使用 Git Bash 方式、Shell 方式
- 是否关联 Git 配置文件:该配置文件主要显示文本编辑器样式
- 是否关联 Shell 脚本文件:是否关联 Bash 命令执行脚本文件
- 使用 TrueType 编码:在命令行中是否使用 TrueType 编码,该编码是微软和苹果公司制定的通用编码
5 -> 在开始菜单创建快捷方式,然后点击 【 Next 】:
6 -> 选择默认的 Git 编辑器(默认 VIM),然后点击 【 Next 】:
7 -> 设置环境,设置命令行工具(默认配置即可),然后点击 【 Next 】:
- Git自带:使用 Git 自带的 Git Bash 命令行工具;
- 系统自带以及第三方软件:使用 windows 系统以及第三方软件命令行工具;
- Git 自带和 Unix Tools:注意,这样会将 windows 中的 find.exe 和 sort.exe 工具覆盖,如果不懂这些尽量不要选择。
8 -> 选择换行格式,然后点击 【 Next 】:
- 检查出 Windows 格式转换为 Unix 格式:将 Windows 格式的换行转为 Unix 格式的换行再进行提交;
- 检查出原来格式转换为 Unix 格式:不管什么格式的,一律转换为 Unix 格式的换行再进行提交;
- 不进行格式转换:不进行转换,检查出什么格式就提交什么格式。
9 -> 配置 Git bash 终端仿真器(默认即可),然后点击 【 Next 】:
- 使用 MinTTY 终端
- 使用 Windows 默认的命令行
需要注意的是 >>> MinTTY 终端不支持交互操作,如 Python && Node!!!但可以使用 winpty program(python/node)
运行。
10 -> 性能配置,是否启用文件系统缓存(默认即可),然后点击 【 install 】 等待安装完成即可:
Git EnvsVar Config
有时安装完成以后可能在 Windows CMD 中无法正常使用 Git,可以将 GIT_HOME/bin
添加到系统环境变量 path 中,就可以在 CMD 中正常使用 Git了。
Git Bash Here
上面我们已经完成了 Git 的安装以及配置过程,这里我们可以尝试在 Windows 下打开 Git Bash 来看一下:
是不是不同于我们熟悉的 Linux shell 或者 Windows CMD?!!下面给出一种 Git 控制台美化方法:
Git 控制台格式以及字体美化 >>
详细优化过程如下:
1 -> 下载必要的配置文件:
1 | ## Git 控制台中 clone 美化配置仓库: |
2 -> 配置 Linux Shell 样式以及 YaHei 字体
Linux Shell 样式配置方法如下(操作文件见 Git-Bash 目录):
1 | 将 git-completion.bash 配置文件 copy 当前用户主目录; |
自此,关闭 Git Bash 再重新打开,你会发现其格式已经变为我们熟悉的 Linux Shell 样式:
有一个 Yahei 和 Consolas 的混合字体,相当漂亮,很适合在 Windows 平台下编程使用,我们之前已经从 GitHub 上 clone 了下来。
关于 Yahei 字体的配置使用方法,可见 YaHei-Consolas-Hybrid-1.12
目录中 README.md
说明文件。
后面的同学别睡了,正文开始 ……
Git 的安装、配置、优化完成之后,下面正式开始进行 Git 的学习以及使用:
初识 Git Repository
前面我们一直在提 Git 分布式系统中的每一个节点(用户设备)都是一个完整的版本库。那什么是版本库呢?!!版本库又名版本仓库(Repository)。
Repository 可以简单理解成一个目录,这个目录里面的所有文件都可以被 Git 管理起来。什么时候、什么人更改了目录下文件的什么内容等信息都能被 Git 忠实地跟踪以及记录下来。以便 Git 任何时刻都可以追踪历史,或者在将来某个时刻可以“还原”。
使用前,你需要明确(重要!重要!重要!):
所有的版本控制系统,其实 只能跟踪文本文件的改动,比如TXT文件,网页,所有的程序代码等等,Git 也不例外。
版本控制系统可以告诉你文本文件每次的变更,比如在第 5 行加了一个单词 “Linux”,在第 8 行删了一个单词 “Windows”。
而图片、视频这些二进制文件,虽然也能由版本控制系统管理,但没法跟踪文件的变化,只能把二进制文件每次改动串起来,也就是只知道图片从 100KB 改成了 120KB,但到底改了啥,版本控制系统不知道,也没法知道。最初我使用过一个毕设论文示例其实是不恰当的,Microsoft Word 格式是二进制格式,因此 Git 是没法直接跟踪 Word 文件的改动的。
注意,上面我说的是
没法直接
,并不是不能!需要使用第三方转化软件的协助 ,才可以进行版本控制。
还有一个很重要的问题就是 文本的编码问题。强烈建议使用标准的 UTF-8 编码,所有语言使用同一种编码,既没有冲突,又被所有平台所支持。
Config User && E-Mail
版本仓库用户以及邮箱设置 –>>>
我们知道,Git 是分布式版本控制系统,所以每个机器都必须自报家门:你的名字和 Email 地址。也就是说在使用之前我们还需要为 Git 中的版本仓库设置用户以及邮箱。
通常我们会面临一种场景:公司工作时,我们一般会参与多个项目开发,而向不同的项目提交变更时,一般请求情况下提供的用户都是同一个,而我们为了方便可能会使用 全局设置 对 Git 进行统一的配置;但当我们处于学习变更自己的学习项目时,我们可能更多地不希望使用公司公用的用户以及邮箱配置,这就涉及到为特定的仓库(项目)进行 单独设置。
模拟场景:
- 公司参与多个项目:A、B、C、D,用于提交的公司用户名是:”staff_ming”,会使用 Git 全局配置;
- 个人学习项目:E,用于提交的个人学习用户名是:”Pilot_ming”,会为项目 E 进行单独配置。
全局配置步骤
1)Git Bash 控制台执行:
1 | git config --global user.name "staff_ming" |
2)可在当前用户目录下生成一个 .gitconfig
配置文件,可以查看文件内容中的配置信息:
1 | [user] |
注意 git config
命令的 --global
参数表示:当前机器上所有的 Git 版本仓库都会使用这个配置。
单独配置项目步骤
1)Git Bash 中进入项目所在目录(后续学习后你会知道 Git 管理下的项目目录会产生一个 .git 目录),执行:
1 | git config user.name "Pilot_ming" |
2)可在当前项目目录下的 .git
目录中生成一个 config 配置文件,可以查看当前仓库的配置信息。
用户名和邮箱配置之后,简单进行以下 Git 的实操。系列博文实操部分测试均在 Windows10 下完成,Linux 平台下同理。
Manage A New Project
假设要新建一个 GitTest 的项目,要使用 Git 进行管理,你有两方面的工作要做:
- 创建 GitTest 版本库 –>>> GitTestProject;
- 添加文件到版本库进行版本管理
1 –> How To Create Git Repo
事实上,创建一个全新的 Git 版本库(由 Git 进行版本管理的项目目录)非常简单:
1)创建版本库目录(项目目录):
1 | Windows 系统下,为了避免遇到各种莫名其妙的问题,请确保目录名(包括父目录)不包含中文。 |
2)初始化版本库:
1 | git init 命令可以将当前目录变成 Git 可以管理的版本库: |
注意:初始化后,会在当前目录自动创建 .git
目录(意味着 Git 来跟踪管理版本库的),该文件是 Git 中最重要的文件夹,因为 Git 相关文件以及版本都将保存 .git
中,.git
受损 Git 版本仓库就会被破坏掉。
如何添加文件到版本库中进行版本管理? –>>>
2 –> How To Add A File To Repo For Vers Management
来看一下,一个简单的文本文件如何能够被 Git 版本库管理:
1 | 1. 在版本库 GitTestProject 中创建一个用于 Git 管理的新文档:readme.txt,内容如下 |
注意:git commit
命令之后的 -m
参数表示的是:本次向 Git 版本库提交的说明(变更注释)。强烈建议添加变更说明!!!不加 -m
参数 Git 会跳转进入 VIM。
初次使用 git add 命令可能会产生:
Warning: LF will be replaced by CRLF in **
的警告信息,更多请参看:Warning:LF && CRLF 部分。
事实上,我们更多的时候是需要在非空目录(既有项目)下使用 Git 管理,这也是可以的。
Manage A Existing Project
|==============================================================
既存项目目录结构说明:
GitTestProject 版本库包含:Server 目录、Client 目录、以及 readme.txt 说明文档。
Server 目录下包含一个名为:service.py 的文件,内容为:
1 | # This is a Test! |
Client 目录“看作”是一个空目录(仅包含一个名为 .gitignore
的占位文件,见后文说明)。
readme.txt 文件内容为:
1 | Git is a version control system. |
==============================================================|
假设要使用 Git 管理一个既存的、名为 GitTestProject 的项目,你有两方面的工作要做:
- 初始化 GitTestProject 为版本库;
- 添加项目目录中的文件到版本库开启版本管理
1 –> 初始化项目目录(GitTestProject)为版本库
1 | 进入项目目录 |
2 –> 添加项目目录中的文件到版本库开启版本管理
非空目录下创建 Git 版本库,git init
之后版本库目录下的文件其实并没有被 Git 管理,想要将其填加到版本库的话可以:
1 | git add + dir(目录)会将 dir 以及其下所有文件添加到 Git 版本库: |
补充:git add .
可以将当前目录下所有文件添加到版本库。
注意,项目中的空文件夹(空目录)不会被管理!!!解决方法:可以在相应目录添加
.gitkeep
或者.gitignore
占位文件(不起其它作用)。
==================================
恭喜你,通过 Git 的安装、配置以及简单测试说明,相信你已经对 Git 版本控制有了一定的理解了,后续博文将带你更进一步掌握 Git 版本控制的使用~
Warning:LF && CRLF
初次安装好 Git 之后,使用 git add 命令时,可能会产生警告 Warning: LF will be replaced by CRLF in **<file>
这是由于文本中存在换行符引发的,LF && CRLF 事实上都是换行符(一行文本的结束)。
1 –> LF(Line Feed)&& CRLF(Carriage Return)
LF 代表:“换行”,是 Linux 和 Unix 系统的换行符。CRLF 代表:“回车”,是 Windows 系统的换行符。
2 –> Git 换行符自动转换功能
不同操作系统下换行符规则的差异,给跨平台的协作的项目带来了问题,文件中到底是使用哪个规则呢?Git 中为了解决这个问题,提供了一个 ”换行符自动转换” 的功能,并且这个功能是默认处于”自动模式“即开启状态的。
换行符自动转换功能 会自动将文本(代码)里当前操作系统不相同的换行的方式,转换成当前系统的换行方式(即 LF
和 CRLF
之间的转换)。这样,当提交代码的时候,即使没有修改过某个文件,也被 Git 认为你修改过了,从而提示 LF will be replaced by CRLF in **
。
3 –> 解决办法
使用如下命令可以将 Git 的换行符自动转换功能关闭掉(不推荐):
实际编程中,Warning 级别的警告是可以忽略的,当然你可以选择将自动转换功能关掉(强迫症~),但这里 不推荐关闭!!!
1 | 仅对当前版本库生效 |
选择策略 >>>
如果可以保证你的项目(代码,文档)不会跨平台,你可以设置关掉自动转换的功能。
否则,如果你和你的合作者用不同的系统进行工作时,关掉这个自动转换的功能可能会导致文档显示异常,此时不建议关闭。
install_url
to use ShareThis. Please set it in _config.yml
.