目录
前言
Git 是一个开源的分布式版本控制系统,用以有效、高速的处理从很小到非常大的项目版本管理。
一、Git 的诞生
这部分内容在 CSDN的 Git技能树学习 处转发过来的。
1、什么是 “版本控制”
版本控制是一种记录一个或若干文件内容变化,以便将来查阅特定版本修订情况的系统。在 GIT CODE
中,我们对保存着软件源代码的文件作版本控制,但实际上,你可以对任何类型的文件进行版本控制。
2、版本控制系统发展史
版本控制系统发展可以分为三个阶段:
- 本地版本控制系统
- 集中式版本控制系统
- 分布式版本控制系统
⑴、本地版本控制系统
许多人习惯用复制整个项目目录的方式来保存不同的版本,或许还会改名加上备份时间以示区别。 这么做唯一的好处就是简单,但是特别容易犯错。 有时候会混淆所在的工作目录,一不小心会写错文件或者覆盖意想外的文件。
为了解决这个问题,人们很久以前就开发了许多种本地版本控制系统,大多都是采用某种简单的数据库来记录文件的历次更新差异。
其中最流行的一种叫做 RCS
,现今许多计算机系统上都还看得到它的踪影。 RCS
的工作原理是在硬盘上保存补丁集(补丁是指文件修订前后的变化);通过应用所有的补丁,可以重新计算出各个版本的文件内容。
⑵、集中式版本控制系统
接下来人们又遇到一个问题,如何让在不同系统上的开发者协同工作? 于是,集中化的版本控制系统(Centralized Version Control Systems,简称 CVCS)
应运而生。 这类系统,诸如 CVS
、Subversion
以及 Perforce
等,都有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新。多年以来,这已成为版本控制系统的标准做法。
这种做法带来了许多好处,特别是相较于老式的本地 VCS
来说。 现在,每个人都可以在一定程度上看到项目中的其他人正在做些什么。 而管理员也可以轻松掌控每个开发者的权限,并且管理一个 CVCS
要远比在各个客户端上维护本地数据库来得轻松容易。
但这么做也有一个显而易见的缺点,那就是是中央服务器的单点故障。
- 如果宕机一小时,那么在这一小时内,谁都无法提交更新,也就无法协同工作
- 如果中心数据库所在的磁盘发生损坏,又没有做恰当备份,毫无疑问你将丢失所有数据——包括项目的整个变更历史,只剩下人们在各自机器上保留的单独快照。
本地版本控制系统也存在类似问题,只要整个项目的历史记录被保存在单一位置,就有丢失所有历史更新记录的风险。
⑶、分布式版本控制系统
于是分布式版本控制系统(Distributed Version Control System
,简称 DVCS
)面世了。 在这类系统中,像 Git
、Mercurial
、Bazaar
以及 Darcs
等,客户端并不只提取最新版本的文件快照, 而是把代码仓库完整地镜像下来,包括完整的历史记录。 这么一来,任何一处协同工作用的服务器发生故障,事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作,实际上都是一次对代码仓库的完整备份。
不仅如此,许多这类系统都可以指定和若干不同的远端代码仓库进行交互。这样一来,你就可以在同一个项目中,分别和不同工作小组的人相互协作。 你可以根据需要设定不同的协作流程,比如层次模型式的工作流,而这在以前的集中式系统中是无法实现的。
3、Git 诞生的背景
Linus
在1991
年创建了开源的 Linux
,从此,Linux
系统不断发展,已经成为最大的服务器系统软件了。在1991
-2002
年期间,世界各地的志愿者把源代码文件通过 diff
的方式发给 Linus
,然后由 Linus
本人通过手工方式合并代码。
你也许会想,为什么 Linus
不把 Linux
代码放到版本控制系统里呢?不是有 CVS
、SVN
这些免费的版本控制系统吗?因为 Linus
坚定地反对CVS
和SVN
,这些集中式的版本控制系统不但速度慢,而且必须联网才能使用。有一些商用的版本控制系统,虽然比CVS
、SVN
好用,但那是付费的,和 Linux
的开源精神不符。
4、Linus 两周完成 Git
到 2002
年,Linux
系统已经发展了十年了,代码库之大让 Linus
很难继续通过手工方式管理了,整个项目组开始启用一个专有的分布式版本控制系统 BitKeeper
来管理和维护代码,BitKeeper
的东家 BitMover
公司也免费授权 Linux
社区使用这个版本控制系统。后来 BitMover
公司发现社区有人试图破解 BitKeeper
的协议,于是 BitMover
公司收了回 Linux
社区的免费使用权。
这就迫使 Linux
开源社区(特别是 Linux
的缔造者 Linus Torvalds
)基于使用 BitKeeper
时的经验教训,开发出自己的版本系统。 他们对新的系统制订了若干目标:
- 速度
- 简单的设计
- 对非线性开发模式的强力支持(允许成千上万个并行开发的分支)
- 完全分布式
- 有能力高效管理类似 Linux 内核一样的超大规模项目(速度和数据量)
于是,Linus
花了两周时间自己用 C
写了一个分布式版本控制系统,这就是 Git
!一个月之内,Linux
系统的源码已经由 Git
管理了!
5、Git 的发展壮大
自 2005
年诞生以来,Git
日臻成熟完善,在高度易用的同时,仍然保留着初期设定的目标。它的速度飞快,极其适合管理大项目,有着令人难以置信的非线性分支管理系统。Git
迅速成为最流行的分布式版本控制系统,尤其是 2008
年,GitHub
网站上线了,它为开源项目免费提供 Git
存储,无数开源项目开始迁移至 GitHub
,包括jQuery
,PHP
,Ruby
等等。
二、Git 的使用
Git 两大特点:
-
版本控制
:可以解决多人同时开发的代码问题,也可以解决找回历史代码的问题。 -
分布式
:Git
是分布式版本控制系统,同一个Git
仓库,可以分布到不同的机器上。首先找一台电脑充当服务器的角色,每天24小时开机,其他每个人都从这个服务器仓库克隆一份到自己的电脑上,并且各自把各自的提交推送到服务器仓库里,也从服务器仓库中拉取别人的提交。可以自已搭建这台服务器,也可以使用GitHub
网站。
1、Git 安装
2、Git配置
⑴、配置秘钥
针对不同代码托管平台配置不同的秘钥,进入 .ssh目录
打开cmd或者Git Bash 执行下面的命令:
- Windows:
C:\Users\Admin\.ssh
目录 - Mac:
~/.ssh
目录
ssh-keygen -t rsa -C "邮箱" -f "[公私钥文件名]"
ssh-keygen -t rsa -C "邮箱" -f "id_rsa_github"
ssh-keygen -t rsa -C "邮箱" -f "id_rsa_gitee"
执行结果:
Admin@DESKTOP-CSH3FGN MINGW64 ~/.ssh
$ ls
id_rsa id_rsa_github id_rsa_gitee known_hosts
id_rsa.pub id_rsa_github.pub id_rsa_gitee.pub
Admin@DESKTOP-CSH3FGN MINGW64 ~/.ssh
然后针对不同托管平台把相对应的 .pub
公钥文件内容复制到个人中心中配置公钥的地方。如果同一平台有不同的邮箱,生成时修改下文件名去区分。
Admin@DESKTOP-CSH3FGN MINGW64 ~/.ssh
$ ssh -T git@gitee.com
Hi 云三木! You've successfully authenticated, but GITEE.COM does not provide shell access.
Admin@DESKTOP-CSH3FGN MINGW64 ~/.ssh
注意:该命令仅限于文件名为id_rsa的密钥,因为系统默认只读取id_rsa。
为了让 ssh
识别新的私钥,可以使用 ssh-agent
手动添加私钥(该方法仅限当前窗口有效,打开新的窗口则ssh连接失败。):
ssh-agent bash
ssh-add ~/.ssh/id_rsa2
该方法仅限当前窗口有效,打开新的窗口则ssh连接失败。
为了解决多个秘钥的问题,在 .ssh目录
下新建 config
文件,并写入以下内容:
#gitee
Host gitee.com
HostName gitee.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa_gitee
#github
Host github.com
HostName github.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa_github
Admin@DESKTOP-CSH3FGN MINGW64 ~/.ssh
$ ssh -T git@gitee.com
Hi cloud3wood! You've successfully authenticated, but GITEE.COM does not provide shell access.
Admin@DESKTOP-CSH3FGN MINGW64 ~/.ssh
$ ssh -T git@github.com
Hi 云三木! You've successfully authenticated, but GitHub.COM does not provide shell access.
⑵、配置用户名和邮箱
Git
提供了一个叫做 git config
的工具,专门用来配置或读取相应的工作环境变量。
这些环境变量,决定了 Git
在各个环节的具体工作方式和行为。这些变量可以存放在以下三个不同的地方:
/etc/gitconfig 文件
:系统中对所有用户都普遍适用的配置。若使用git config
时用--system
选项,读写的就是这个文件。~/.gitconfig 文件
:用户目录下的配置文件只适用于该用户。若使用git config
时用--global
选项,读写的就是这个文件。当前项目的 Git 目录中的配置文件
(也就是工作目录中的.git/config 文件
):这里的配置仅仅针对当前项目有效。若使用git config
时用--local
选项,读写的就是这个文件。
每一个级别的配置都会覆盖上层的相同配置,所以 .git/config
里的配置会覆盖 /etc/gitconfig
中的同名变量。
在 Windows
系统上,Git
会找寻用户主目录下的 .gitconfig
文件。主目录即 $HOME
变量指定的目录,一般都是 C:\Documents and Settings\$USER
。
此外,Git
还会尝试找寻 /etc/gitconfig
文件,只不过看当初 Git
装在什么目录,就以此作为根目录来定位。
上面我们知道 Git
共有三个级别的 .gitconfig 文件
,对应的参数分别是:
--system
:全局唯一配置;--global
:当前系统账户配置;--local
:当前仓库目录配置;
这三个级别都分别配置了用户信息,当 git commit
时,会依次从 local
、global
、system
里读取用户信息。
git config --global user.name "输入你的用户名"
git config --global user.email "输入你的邮箱"
如果需要配置多个用户名和邮箱,可以在当前仓库下单独配置:
git config user.name "输入你的用户名"
git config user.email "输入你的邮箱"
3、Git 工作流程
- 克隆 Git 资源作为工作目录。
- 在克隆的资源上添加或修改文件。
- 如果其他人修改了,你可以更新资源。
- 在提交前查看修改。
- 提交修改。
- 在修改完成后,如果发现错误,可以撤回提交并再次修改并提交。
4、Git 工作区、暂存区和版本库
Git 思维框架的三个重要概念:
工作区(Workspace)
:从 Git 版本库解包出来的实际可编辑的文件,放在磁盘上供我们使用或修改,即我们能直接看到的项目目录。暂存区(Index/Stage)
:是一个文件,实际位于.git/index
,所以把暂存区也叫做索引(Index)
,保存了下次将要提交的文件列表信息。版本库(repository)
:就是我们项目目录下的.git
目录中的内容,是 Git 用来保存项目的元数据和对象数据库的地方。 这是 Git 中最重要的部分,从其它计算机克隆仓库时,复制的就是这里的数据。
上面是本地代码操作流程,正常流程我们还需要提交到 远程仓库(remote repository)
:
5、Git文件的四种状态
- Untracked: 未跟踪,此文件在文件夹中,但并没有加入到git库,不参与版本控制,通过git add 状态变为Staged。
- Unmodify: 文件已经入库,未修改,即版本库中的文件快照内容与文件夹中完全一致。这种类型的文件有两种去处,如果它被修改,而变为Modified。如果使用git rm移出版本库,则成为Untracked文件。
- Modified: 文件已修改,仅仅是修改,并没有进行其他的操作。这个文件也有两个去处,通过git add可进入暂存staged状态,使用git checkout 则丢弃修改过,返回到unmodify状态,这个git checkout即从库中取出文件,覆盖当前修改。
- Staged: 暂存状态。执行git commit则将修改同步到库中,这时库中的文件和本地文件又变为一致,文件为Unmodify状态。执行git reset HEAD filename取消暂存,文件状态为Modified。
6、Git 基本操作
Git 常用的是以下六个命令:git clone
、git push
、git add
、git commit
、git checkout
、git pull
。
⑴、创建仓库
- 1、在代码托管平台创建远程仓库;
- 2、复制刚刚创建的远程仓库地址,克隆岛本地,执行一下命令:
git clone <repo> <directory> 参数: repo:Git 仓库。 directory:本地目录。
⑵、正常提交流程
修改文件后的提交步骤:
- 1、添加修改后的文件到暂存区。
git add [file1] [file2] ... # 添加一个或多个文件到暂存区 git add [dir] # 添加指定目录到暂存区,包括子目录 git add . # 添加当前目录下的所有文件到暂存区
- 2、将暂存区内容添加到仓库中。
git commit -m [message] # 提交暂存区到本地仓库中 git commit [file1] [file2] ... -m [message] # 提交暂存区的指定文件到仓库区 参数: [message] 可以是一些备注信息 git commit -am [message] -a 参数设置修改文件后不需要执行 git add 命令,直接来提交
- 3、推送到远端
git push <远程主机名> <本地分支名>:<远程分支名> # 如果本地分支名与远程分支名相同,则可以省略冒号 git push <远程主机名> <本地分支名> 例: git push origin master 相当于 git push origin master:master