Git操作——学习笔记

一，git简介

1.1git介绍和安装

git介绍

Git是一个免费的、开源的分布式版本控制系统，可以快速高效地处理从小型到大型的各种项目。
Git易于学习，占地面积小，性能极快。它具有廉价的本地库，方便的暂存区域和多个工作流分支等特性。

其性能优于Subversion、CVS、Perforce和ClearCase等版本控制工具

git安装

Git高速下载地址：https://npm.taobao.org/mirrors/git-for-windows/

1.点击next

2.Git安装目录名，不用修改，直接点击下一步。

3. 选择git文件默认的编辑器，点击Next即可

4.选择Git初始化分支的名称，默认为master，想修改选择下面按钮输入想改的名字即可，按需选择后点击Next(根据自身情况选择，一般为默认)

5.根据情况选择使用git的方式，第一个选项, 只从Git Bash命令行工具 使用Git。第二个选项, 从命令行或者第三方软件 使用Git。第三个选项，在命令提示符中使用Git和可选的Unix工具。之后点击Next

6.选择https的传输后端。让Git使用哪个SSL/TLs库来进行HTTPS连接，第一个选项，使用OpenSSL库，服务器cer证书将使用ca包中.crtw文件进行验证通过，默认选这个。 第二个选项，使用本机Windows安全通道库，服务器证书将在Windows证书存储中进行验证。这个选项还允许您通过Active Directory域服务使用您的公司内部根CA证书，选择完成后点击Next

7.配置结束行转换方式，Git应该如何处理文本文件中的行结尾，第一个选项，下拉是转换Windows风格，提交转换为iunix风格，在windows这是推荐默认的设置。第二个选项，下拉时不改变，提交转换为iunix风格。对于跨平台项目，这是Unix上的推荐设置。最后一个选项，下拉和提交都不进行任何转换，对于跨平台项目(“核心项目”)，不推荐选择此选项。

8.配置终端模拟器为使用Git Bash，第一个选项，Git Biash将使用MinTTY作为终端模拟器，它拥有一个可调整大小的窗口，非矩形的选择和Unicode字体。Windows控制台程序(如交互式Python)必须通过winpty’启动才能在MinTTY中工作，默认选择这个更灵活。第二个选项，使用Windows的默认控制台（cmd.exe）,它可以在Win32控制台程序中工作，如交互式Python或node。is，但有一个非常有限的默认滚动回滚，需要配置为使用Unicode字体，以便正确显示非ascil字符，在Windows 10之前，它的窗口不能自由调整大小，它只允许矩形文本选择

9.选择git下拉默认行为，第一个选项，默认(快进或合并)。这是“git pull”的标准行为:尽可能快进当前分支到一个被捕获的分支，否则创建合并提交。第二个选项，将当前分支改为获取的分支。如果没有要重基的本地提交，这相当于快进。 第三个选项，仅仅快进， 快进到获取的分支。如果不可能，就失败。

10.选择git凭证小助手，Credential helper是帮我们保存凭证（用户密码）他有很多存储模式如：cache，store，manager和osxkeychain，这里根据自己需要选择。

11.配置额外特性选项，第一个选项，启用文件系统缓存,文件系统数据将被大量读取，并缓存到内存中以用于某些操作(“core。fscache"设置为"true")。这提供了显著的性能提升。第二个选项，支持符号链接，启用符号链接(需要SeCreateSymboliclink权限)。请注意，现有存储库不受此设置的影响

12.启用实验配置选项，第一个选项，启用对伪控制台的实验性支持,(新)这允许在Git Bash窗口中运行原生控制台程序，如Node或Python，而不使用winpty，但它仍然有已知的bug，第二个选项，启用了实验性的内置文件系统监视器（新！）自动运行一个内置的文件系统监视程序，以加速包含许多文件的Worktree中的常见操作，如git status git add、“git commit”等。一般用不到 可不勾选，直接点Install即可

1.2版本控制工具

集中式版本控制工具：

CVS、SVIN(Subversion)(使用已经不是很多了)、VSS…
集中化的版本控制系统诸如CVS、SVN等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这己成为版本控制系统的标准做法。这种做法带来了许多好处，每个人都可以在一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限，并且管理一个集中化的版本控制系统，要远比在各个客户端上维护本地数据库来得轻松容易。
事分两面，有好有坏。这么做显而易见的缺点是中央服务器的单点故障。如果服务器宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。

分布式版本控制工具

Git、Mercurial、Bazaar、Darcs…
像Git这种分布式版本控制工具，客户端提取的不是最新版本的文件快照，而是把代码仓库完整地镜像下来（本地库）。这样任何一处协同工作用的文件发生故障，事后都可以用其他客户端的本地仓库进行恢复。因为每个客户端的每一次文件提取操作，实际上都是一次对整个文件仓库的完整备份。

分布式的版本控制系统出现之后解决了集中式版本控制系统的缺陷：
1.服务器断网的情况下也可以进行开发（因为版本控制是在本地进行的）
2.每个客户端保存的也都是整个完整的项目（包含历史记录，更加安全）

个人理解，分布式的是将整个库放在了所有节点上（包括自己的电脑），服务器挂了，找另一个服务器推送上去就可以恢复版本，而集中式由于客户端保存的都是最新版本，服务器挂了，没有一个客户端有完整的项目

1.3 git工作机制

工作区 => git add => 暂存区 => git commit => 本地库 => git push => 远程库

<