Git详细介绍-入门到实战万字篇（上）Git入门

本文主要介绍关于git,服务器,自动化测试,软件测试的知识点，对【Git详细介绍 -入门到实战万字篇（上）】和【Git入门】有兴趣的朋友可以看下由【软件测试自动化测试】投稿的技术文章，希望该技术和经验能帮到你解决你所遇的自动化测试相关技术问题。

Git入门

目录

1、Git介绍

一、什么是版本控制系统？

二、我们为什么要用版本控制？

三、版本管理系统的演变

2、Git与SVN的区别

一、SVN和Git的优缺点

二、集中式版本管理系统和分布式版本管理系统

三、Git在项目协作开发是解决的问题

3、Git的安装

一 、Git的下载

二 、Git在Windows下的详细安装

三、验证Git是否安装成功

重点：配套学习资料和视频教学

---

1、Git介绍

要像了解Git，首先需要我们了解一下VCS——版本控制系统（version control system）

一、什么是版本控制系统？

版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。版本控制系统不仅可以应用于软件源代码的文本文件，而且可以对任何类型的文件进行版本控制。
有了它你就可以将某个文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态，你可以比较文件的变化细节，查出最后是谁修改了哪个地方。也就是无论文件最后被修改成什么样子，你都可以轻松恢复到原先的样子，但是额外增加的工作量却微乎其微。

二、我们为什么要用版本控制？

世界上无数大大小小的开发项目都在使用各种各样的版本控制系统，原因在于它的优点对于一个项目开发来说是无比重要。
比如一个最简单的开发团队，也许就两三个人，他们共同完成一个软件的开发。每个人都在修改、添加、删除着自己本地硬盘上的代码，当他们把这些代码汇总起来时，麻烦出现了。到底谁改了哪些文件，具体是文件里的哪部分被改动过？A的修改会不会把B的修改覆盖掉？汇总的工作变得很危险，需要非常小心，一旦出错后果不堪设想。显然此时，效率将会是无比的低下，如果某个地方出错，可能整个汇总工作就要重来一遍。这只是两三人的小团队，如果是几十人几百人的大团队呢？那将会是噩梦。
如果这个团队采用了版本控制。那么版本控制软件在每次提交的时候都会主动合并所有人的修改并解决可能发生的冲突。每个人手里一直都是汇总好的代码。当开发进行到一定阶段，可以直接拿去测试，不需要再有额外的工作来浪费时间。

三、版本管理系统的演变

1、本地版本控制系统
许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。 这么做唯一的好处就是简单，但是特别容易犯错。 有时候会混淆所在的工作目录，一不小心会写错文件或者覆盖意想外的文件。
为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异。

本地版本控制系统

这代主要实现了基本的代码版本管理，但缺点是无法让多人同时对一个版本库进行修改。这个也和当时软件规模不够大有关，也没有这样的需求。
2、集中化版本控制系统
接下来人们又遇到一个问题，如何让在不同系统上的开发者协同工作？ 于是，集中化的版本控制系统（Centralized Version Control Systems，简称 CVCS）应运而生。 这类系统，诸如 CVS、Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。 多年以来，这已成为版本控制系统的标准做法。

集中化版本控制系统

这种做法带来了许多好处，特别是相较于老式的本地 VCS 来说。 现在，每个人都可以在一定程度上看到项目中的其他人正在做些什么。 而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。
事分两面，有好有坏。 这么做最显而易见的缺点是中央服务器的单点故障。 如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。 如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问你将丢失所有数据——包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。 本地版本控制系统也存在类似问题，只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。
3、分布式版本控制系统
于是分布式版本控制系统（Distributed Version Control System，简称 DVCS）面世了。 在这类系统中，像 Git、Mercurial、Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。

分布式版本控制系统
许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。 你可以根据需要设定不同的协作流程，比如层次模型式的工作流，而这在以前的集中式系统中是无法实现的。

2、Git与SVN的区别 一、SVN和Git的优缺点

（一）SVN优缺点
优点：
1、 管理方便，逻辑明确，符合一般人思维习惯。
2、 易于管理，集中式服务器更能保证安全性。
3、 代码一致性非常高。
4、 适合开发人数不多的项目开发。
缺点：
1、 服务器压力太大，数据库容量暴增。
2、 如果不能连接到服务器上，基本上不可以工作，看上面第二步，如果服务器不能连接上，就不能提交，还原，对比等等。
3、 不适合开源开发（开发人数非常非常多，但是Google app engine就是用svn的）。但是一般集中式管理的有非常明确的权限管理机制（例如分支访问限制），可以实现分层管理，从而很好的解决开发人数众多的问题。
（二）Git优缺点
优点：
1、适合分布式开发，强调个体。
2、公共服务器压力和数据量都不会太大。
3、速度快、灵活。
4、任意两个开发者之间可以很容易的解决冲突。
5、离线工作。
缺点：
1、学习周期相对而言比较长。
2、不符合常规思维。
3、代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。

二、集中式版本管理系统和分布式版本管理系统

（一）集中式版本管理系统
Subversion属于集中式版本控制系统
集中式的版本控制系统都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。

集中式的版本管理系统结构图

Subversion的特点概括起来主要由以下几条：

每个版本库有唯一的URL（官方地址），每个用户都从这个地址获取代码和数据；获取代码的更新，也只能连接到这个唯一的版本库，同步以取得最新数据；提交必须有网络连接（非本地版本库）；提交需要授权，如果没有写权限，提交会失败；提交并非每次都能够成功。如果有其他人先于你提交，会提示“改动基于过时的版本，先更新再提交”… 诸如此类；冲突解决是一个提交速度的竞赛：手快者，先提交，平安无事；手慢者，后提交，可能遇到麻烦的冲突解决。

好处：

每个人都可以一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限。

缺点：

中央服务器的单点故障。若是宕机一小时，那么在这一小时内，谁都无法提交更新、还原、对比等，也就无法协同工作。如果中央服务器的磁盘发生故障，并且没做过备份或者备份得不够及时的话，还会有丢失数据的风险。最坏的情况是彻底丢失整个项目的所有历史更改记录，被客户端提取出来的某些快照数据除外，但这样的话依然是个问题，你不能保证所有的数据都已经有人提取出来。Subversion原理上只关心文件内容的具体差异。每次记录有哪些文件作了更新，以及都更新了哪些行的什么内容。有很多人认为，集中式的版本控制系统在速度上和性能上是不足的。后来基于集中式的版本控制系统的不足，开发了分布式的版本控制系统。

（二）分布式版本管理系统

分布式版本管理系统结构图

Git是一个分布式的版本控制系统和集中式的控制系统很大的一个差异是，分布式的版本控制系统的服务端和客户端都有完整的一套版本库。那脱离服务端，客户端照样可以管理版本的。并且查看历史以及版本比较等这种版本之间的相关操作，都不需要去访问服务器，也就是说分布式的控制系统比集中式的控制系统更能提高版本管理的效率。Git记录版本历史只关心文件数据的整体是否发生变化。Git 不保存文件内容前后变化的差异数据。实际上，Git 更像是把变化的文件作快照后，记录在一个微型的文件系统中。每次提交更新时，它会纵览一遍所有文件的指纹信息并对文件作一快照，然后保存一个指向这次快照的索引。为提高性能，若文件没有变化，Git 不会再次保存，而只对上次保存的快照作一连接。在分布式版本控制系统中，客户端并不只提取最新版本的文件快照，而是把原始的代码仓库完整地镜像下来。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。你可以根据需要设定不同的协作流程。另外，因为Git在本地磁盘上就保存着所有有关当前项目的历史更新，并且Git中的绝大多数操作都只需要访问本地文件和资源，不用连网，所以处理起来速度飞快。用SVN的话，没有网络或者断开VPN你就无法做任何事情。但用Git的话，就算你在飞机或者火车上，都可以非常愉快地频繁提交更新，等到了有网络的时候再上传到远程的镜像仓库。 三、Git在项目协作开发是解决的问题 多人协作，出现代码冲突 （版本控制工具）多人协作，在代码整合期间引发BUG（回滚）多人协作，领导要看项目 （版本历史）多人协作，用户身份的控制（权限管理）项目版本的发布问题 （标志&里程碑管理）

总结一下：

当研发成本比较低，协作开发人数不多，开发人员对于版本管理的水平参差不齐的时候，或者对于代码的安全性要求更高一点的时候，适合用SVN。而对于很多人参与开发，代码量比较大，或者高频次协作，跨公司，跨地域合作的情况下，更适合用Git。 3、Git的安装

本文讲解Windows下Git的安装

一 、 Git的下载

进入官方地址：https://git-scm.com/download/win

二 、Git在Windows下的详细安装

2.1. 运行Git安装文件

Step 1 Information（信息）

说明：Please read the following important information before continuing继续之前，请阅读以下重要信息

Step 2 Select Destination Location
选择安装位置

Step 3 Select Components
选择组件
关于Git GUI Here。目前我都是使用Git Bash来进行操作。使用Git GUI确实可以得到更好的UI体验，不过个人认为会减低效率。并且初学者还是先搞懂Git的常用指令之后，再使用Git GUI才会有更好的理解。

说明：(1)Additional icons: 附加图标(2)On the Desktop:在桌面上(3)Windows Explorer integration Windows:资源管理器集成鼠标右键菜单Git Bash HereGit GUI Here(4)Git LFS (Large File Support):大文件支持(5)Associate .git/* configuration files with the default text editor:将 .git 配置文件与默认文本编辑器相关联(6)Associate .sh files to be run with Bash:将.sh文件关联到Bash运行(7)Use a TrueType font in all console windows:在所有控制台窗口中使用TrueType字体(8)Check daily for Git for Windows updates:每天检查Git是否有Windows更新

Step 4 Select Strat Menu Folder
创建开始菜单目录（开始菜单目录名设置）

Don't create a Start Menu folder
不创建“开始”菜单文件夹，不勾选。
Step 5 Choosing the default editor used by Git
选择Git使用的默认编辑器

说明：Use the Nano editor by default:默认使用 Nano 编辑器Use Vim (The ubiquitous text editor) as Git's default editor:使用 Vim 作为 Git 的默认编辑器Use Notepad++ as Git's default editor:使用 Notepad++ 作为 Git 的默认编辑器Use Visual Studio Code as Git's default editor:使用 Visual Studio Code 作为 Git 的默认编辑器Use Sublime Text as Git's default editor:使用 Sublime Text 作为 Git 的默认编辑器

可选操作根据自己习惯。
Step 6 Adjusting your PATH environment
配置PATH环境

说明：(1)Use Git from Git Bash only描述：This is the safest choice as your PATH will not be modified at all.You will only be able to use the Git command line tools form Git Bash.翻译：这是最安全的选择，因为您的PATH根本不会被修改。您只能使用 Git Bash 的 Git 命令行工具。(2)Use Git from the Windows Command Prompt描述：This option is considered safe as it only adds some minimal Git wrappers to your PATH to avoid cluttering your environment with optional Unix tools . You will be able to use Git from both Git Bash and the Windows Command Prompt.翻译：这个选项被认为是安全的，因为它只向PATH添加一些最小的 Git包，以避免使用可选的Unix工具混淆环境。 您将能够从 Git Bash 和 Windows 命令提示符中使用 Git。（也就是在Windows的命令行cmd中也可以运行git命令，操作上带来方便）(3)Use Git and optional Unix tools from the Windows Command Prompt从Windows命令提示符使用Git和可选的Unix工具Both Git and the optional Unix tools will be added to you PATHGit和可选的Unix工具都将添加到您计算机的 PATH 中Warning:This will override Windows tools like "find and sort".Only use this option if you understand the implications.警告：这将覆盖Windows工具，如 “ find 和 sort ”。只有在了解其含义后才使用此选项。

选择默认第二项：会自动配置好git命令的环境变量。
第一项简述：直接安装，不会配置git命令的环境变量，需要手动配置环境变量。
第三项：基本没用。
Step 7 Choosing HTTPS transport backend
选择HTTPS传输后端，也就是使用哪个加密库来加密http传输的信息，默认是使用openssl，一般都是使用默认设置。

说明：(1)Use the OpenSSL library使用 OpenSSL 库Server certificates will be validated using the ca-bundle.crt file.服务器证书将使用ca-bundle.crt文件进行验证。(2)Use the native Windows Secure Channel library使用本地 Windows 安全通道库Server certificates will be validated using Windows Certificate Stores.This option also allows you to use your company's internal Root CA certificates distributed e.g. via Active Directory Domain Services.服务器证书将使用Windows证书存储验证。此选项还允许您使用公司的内部根CA证书，例如， 通过Active Directory Domain Services 。

Step 8 Configuring the line ending conversions
选择提交的时候换行格式

说明：(1)Checkout Windows-style,commit Unix-style line endings翻译：检查出windows格式转换为unix格式：将windows格式的换行转为unix格式的换行再进行提交。(2)Checkout as-is , commit Unix-style line endings**翻译：检查出原来格式转为unix格式：不管什么格式的，一律转为unix格式的换行再进行提交。(3)Checkout as-is,commit as-is不进行格式转换 : 不进行转换，检查出什么，就提交什么。

也就是提交代码时使用哪种风格，使用默认设置即可。
Step 9 Configuring the terminal emulator to use with Git Bash
使用哪个软件作为git的终端程序，默认使用minTTY，还属于比较好用的终端，直接使用默认设置

说明：(1)Use MinTTY (the default terminal of MSYS2)描述：Git Bash will use MinTTY as terminal emulator,which sports a resizable window,non-rectangular selections and a Unicode font. Windows console programs (such as interactive Python) must be launched via 'winpty' to work in MinTTY.翻译：Git Bash将使用MinTTY作为终端模拟器，该模拟器具有可调整大小的窗口，非矩形选区和Unicode字体。 Windows控制台程序（如交互式Python）必须通过'winpty'启动才能在MinTTY中运行。(2)Use Windows' default console window描述：Git will use the default console window of Windows ("cmd.exe"),which works well with Win32 console programs such as interactive Python or node.js , but has a very limited default scroll-back,needs to be configured to use aUnicode font in order to display non-ASCII characters correctly,and prior to Windows 10 its windows was not freely resizable and it only allowed rectangular text selections.翻译：Git将使用Windows的默认控制台窗口（“cmd.exe”），该窗口可以与Win32控制台程序（如交互式Python或node.js）一起使用，但默认的回滚非常有限，需要配置为使用unicode 字体以正确显示非ASCII字符，并且在Windows 10之前，其窗口不能自由调整大小，并且只允许矩形文本选择。

Step 10 Configuring extra options
配置额外的选项，如是否开启文件缓存之类的辅助功能，默认选择即可

说明：(1)Enable file system caching启用文件系统缓存描述：File system data will be read in bulk and cached in memory for certain operations ("core.fscache" is set to "true"). This provides a significant performance boost.翻译：文件系统数据将被批量读取并缓存在内存中用于某些操作（“core.fscache”设置为“true”）。 这提供了显着的性能提升。(2)Enable Git Credential Manager启用Git凭证管理器描述：The Git Credential Manager for Windows provides secure Git credential storage for Windows,most notably multi-factor authentication support for Visual Studio Team Services and GitHub. (requires .NET framework v4.5.1 or or later).翻译：Windows的Git凭证管理器为Windows提供安全的Git凭证存储，最显着的是对Visual Studio Team Services和GitHub的多因素身份验证支持。 （需要.NET Framework v4.5.1或更高版本）。(3)Enable symbolic links启用符号链接描述：Enable symbolic links (requires the SeCreateSymbolicLink permission).Please note that existing repositories are unaffected by this setting.翻译：启用符号链接（需要SeCreateSymbolicLink权限）。请注意，现有存储库不受此设置的影响。

Step 11 Installing
安装

Step 12 Completing the Git Setup Wizard
完成Git安装向导

三、验证Git是否安装成功

进入cmd和Git客户端，输入git --version，查看版本信息，出现证明安装成功

在桌面右键，显示Git GUI Here和Git Bash Here。

重点：配套学习资料和视频教学

那么在这里我也精心准备了上述大纲的详细资料在下方链接如下

本文《Git详细介绍 -入门到实战万字篇（上）》版权归软件测试自动化测试所有，引用Git详细介绍 -入门到实战万字篇（上）需遵循CC 4.0 BY-SA版权协议。