1、目标
- 了解Git基本概念
- 能够概述git工作流程
- 熟悉Git代码托管服务
- 能够使用Git常用命令
- 能够使用idea操作git
- 了解Git标签
- 了解SSH协议传输数据? ??
?2、概述
2.1
、开发中的实际场景
- 场景一：备份
小明负责的模块就要完成了，就在即将
Release
之前的一瞬间，电脑突然蓝屏，硬盘光荣牺牲！几
个月来的努力付之东流
- 场景二：代码还原
这个项目中需要一个很复杂的功能，老王摸索了一个星期终于有眉目了，可是这被改得面目全非的
代码已经回不到从前了。什么地方能买到哆啦
A
梦的时光机啊？
- 场景三：协同开发
刚和小强先后从文件服务器上下载了同一个文件：
Analysis.java
。小刚在
Analysis.java
文件中的第
30
行声明了一个方法，叫
count()
，先保存到了文件服务器上；小强在
Analysis.java
文件中的第
50
行声明了一个方法，叫
sum()
，也随后保存到了文件服务器上，于是，
count()
方法就只存在于小刚
的记忆中了
- 场景四：多版本同步开发不同期上线
老许是一位项目经理，根据产品经理的要求，需要同步开发多个功能，但是会在不同的时间节点上
线，针对同一工程和项目，应该怎么解决这个问题？
- 场景五：追溯问题代码的编写人和编写时间！
老王是另一位项目经理，每次因为项目进度挨骂之后，他都不知道该扣哪个程序员的工资！就拿这
次来说吧，有个
Bug
调试了
30
多个小时才知道是因为相关属性没有在应用初始化时赋值！可是二
胖、王东、刘流和正经牛都不承认是自己干的！
2.2
、版本控制器的方式
1. 集中式版本控制工具
集中式版本控制工具，版本库是集中存放在一台中央服务器的，
team
里每个人
work
时从中央服务
器下载代码，是必须联网才能工作，局域网或互联网。个人修改后然后提交到中央版本库
(
有一些肯
定是不能提交的，比如
.idea
，每个人的
idea
配置都不一样
)
。
缺点：如果中央服务器挂了，就不能提交代码
举例：
SVN
和
CVS
2.?分布式版本控制工具
分布式版本控制系统没有
“
中央服务器
”
，每个人的电脑上都是一个完整的版本库，这样工作的时
候，无需要联网了，因为版本库就在你自己的电脑上。多人协作只需要各自的修改推送给对方，就
能互相看到对方的修改了。
举例：
Git
2.3
、
SVN
SVN
是一个开放源代码的版本控制系统，是
Apache Subversion
的缩写。
SVN
是集中式的管理。
SVN
必须有一
个服务器版本库就放在一个中央服务器，所有开发人员都是与服务器进行交互的。
优点：具有很强的权限控制，细化到每一个用户
(
读写
...)
缺点：严重依赖中央服务器
?
2.4、Git
Git
是分布式的
,Git
不需要有中心服务器，我们每台电脑拥有的东西都是一样的。我们使用
Git
并且有个
中心服务器，仅仅是为了方便交换大家的修改，但是这个服务器的地位和我们每个人的
PC
是一样的。我们可以
把它当做一个开发者的
pc
就可以就是为了大家代码容易交流不关机用的。没有它大家一样可以工作，只不过
“
交换
”
修改不方便而已。
git
是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。
Git
是
Linus Torvalds
为了帮助管理
Linux
内核开发而开发的一个开放源码的版本控制软件。
同生活中的许多伟大事物一样，
Git
诞生于一个极富纷争大举创新的年代。
Linux
内核开源项目有着为数众
多的参与者。 绝大多数的
Linux
内核维护工作都花在了提交补丁和保存归档的繁琐事务上（
1991
－
2002
年
间）。 到
2002
年，整个项目组开始启用一个专有的分布式版本控制系统
BitKeeper
来管理和维护代
码。
到了
2005
年，开发
BitKeeper
的商业公司同
Linux
内核开源社区的合作关系结束，他们收回了
Linux
内核社区免费使用
BitKeeper
的权力。 这就迫使
Linux
开源社区（特别是
Linux
的缔造者
Linus Torvalds
）基于使用
BitKeeper
时的经验教训，开发出自己的版本系统。 他们对新的系统制订了
若干目标：
速度
简单的设计
对非线性开发模式的强力支持（允许成千上万个并行开发的分支）
完全分布式
有能力高效管理类似
Linux
内核一样的超大规模项目（速度和数据量）
Clone
：克隆，就是将远程仓库复制到本地
,
多用于第一次获取项目
Push
：推送，就是将本地仓库代码上传到远程仓库
Pull
：拉取，就是将远程仓库代码下载到本地仓库 ，
Push
之前先
Pull
拉取，更新代码
commit
：提交，将工作区代码提交到本地仓库 ，
Push
之前先提交到本地仓库
?
2.5
、
Git
工作流程图
?基本概念：
1.
远程仓库 ： 在局域网
(
本地
)
或互联网上
(
远程
)
的一个主机，存放代码库的主机或平台，比如
gitee.com(
码云
)
2.
本地仓库：
在本地主机上的一个代码库，可以独立存在，也可以与远程仓库进行关联
凡是一个文件夹，包含
.git
隐藏文件夹（
git
工作目录），说明此文件目录使用
git
版本管理。
.git
文件
目录中存储了很多配置信息、日志信息和文件版本信息、工作区、暂存区信息等。
.git
文件夹中有
很多文件，其中有一个
index
文件就是暂存区，也可以叫做
stage
。暂存区是一个临时保存修改文件
的地方
?
3.
工作区：对任何文件的修订
(
增删改
)
，都先放在工作区，工作区不与任何仓库分支进行关联
4.
暂存区：把修订的文件，从工作区经过
add
（添加）后与某一个仓库分支进行关联，只要进入缓存
区的文件才能
commit(
提交
)
到本地仓库。
5.
分支：代码存放在仓库，默认是主分支
(master)
，可以在主分支基础上创建很多子分支，比如
develop
（开发）、
bugfix
（
bug
修复）等。
Git基本命令
1
．
clone
（克隆）
:
从远程仓库中克隆代码到本地仓库
fetch (
抓取
)
： 从远程库，抓取到本地仓库，不进行任何的合并动作，一般操作比较少。
2
．
checkout
（检出）
:
从本地仓库中检出一个仓库分支然后进行修订
3
．
add
（添加）
:
在提交前先将代码提交到暂存区
4
．
commit
（提交）
:
提交到本地仓库。本地仓库中保存修改的各个历史版本
5 . pull (
拉取
)
： 从远程库拉到本地库，自动进行合并
(merge)
，然后放到到工作区，相当于
fetch+merge
6
．
push
（推送）
:
修改完成后，需要和团队成员共享代码时，将代码推送到远程仓库
2.6
、工作目录下的状态
Git
工作目录下的文件存在两种状态：
untracked
未跟踪（未被纳入版本控制）
tracked
已跟踪（被纳入版本控制）
Unmodified
未修改状态
Modified
已修改状态
(
已经在提交在本地仓库但是进行了修改
)
Staged
已暂存状态
这些文件的状态会随着我们执行
Git
的命令而发生变化
3、Git远程仓库
3.1
、 常用的托管服务
[
远程仓库
]
前面我们已经知道了
Git
中存在两种类型的仓库，即本地仓库和远程仓库。那么我们如何搭建
Git
远
程仓库呢？我们可以借助互联网上提供的一些代码托管服务来实现，其中比较常用的有
GitHub
、码
云、
GitLab
等。
gitHub
（
地址：
https://github.com/
）是一个面向开源及私有软件项目的托管平台，因为只
支持
Git
作为唯一的版本库格式进行托管，故名
gitHub
码云（地址：
https://gitee.com/
）是国内的一个代码托管平台，由于服务器在国内，所以相
比于
GitHub
，码云速度会更快
GitLab
（地址：
https://about.gitlab.com/
）是一个用于仓库管理系统的开源项目，使用
Git
作为代码管理工具，并在此基础上搭建起来的
web
服务
,
一般用于在企业、学校等内部网络搭
建
git
私服
。
3.2
、 注册码云
要想使用码云的相关服务，需要注册账号（地址：
https://gitee.com/signup
）