二十、Git使用教程（1）

1 概述

Git（读音为/gɪt/）是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。

1.1 版本控制器的方式

a、集中式版本控制工具
	集中式版本控制工具，版本库是集中存放在中央服务器的，team里每个人work时从中央服务器下载代码，是必须联网才能工作，局域网或互联网。个人修改后然后提交到中央版本库。
	举例：SVN和CVS
b、分布式版本控制工具
	分布式版本控制系统没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样工作的时候，无需要联网了，因为版本库就在你自己的电脑上。多人协作只需要各自的修改推送给对方，就能互相看到对方的修改了。
	举例：Git

1.1.1 SVN

SVN是一个开放源代码的版本控制系统，是Apache Subversion的缩写。SVN是集中式的管理。SVN必须有一个服务器版本库就放在一个中央服务器，所有开发人员都是与服务器进行交互的。
优点：具有很强的权限控制
缺点：严重依赖中央服务器

1.1.2 Git

Git是分布式的,Git不需要有中心服务器，我们每台电脑拥有的东西都是一样的。我们使用Git并且有个中心服务器，仅仅是为了方便交换大家的修改，但是这个服务器的地位和我们每个人的PC是一样的。我们可以把它当做一个开发者的pc就可以就是为了大家代码容易交流不关机用的。没有它大家一样可以工作，只不过“交换”修改不方便而已。
简单的设计：
对非线性开发模式的强力支持（允许成千上万个并行开发的分支）
完全分布式：
有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）

1.1.3 Git的安装

官网下载git，安装git.exe
初始化git
设置用户信息

git config --global user.name "hechongyang" 

git config --global user.email "hechongyangowen@163.com"

git config --global credential.helper store  

#git push的时候记住用户名和密码
以上配置信息默认存储在用户目录下，如果设置错误，可以删除以下如图文件，重新操作以上命令即可。

查看配置信息：
git config --list
git config user.name

通过上面的命令设置的信息会保存在~/.gitconfig文件中

2 Git的工作流程

2.1 基本概念

2.1.1 远程仓库

在局域网或互联网上的一个主机，存放代码库的主机或平台，比如GitHub，gitee.com(码云)等。

2.1.2 工作区

就是你在电脑里能看到的目录，对任何文件的修订(增删改)，都先放在工作区，工作区不与任何仓库分支进行关联。

2.1.3 暂存区（stage）

把修订的文件，从工作区经过add（添加）后与某一个仓库分支进行关联，只有进入暂存区的文件才能commit(提交)到本地仓库。

2.1.4 版本库（Repository本地仓库）

工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。版本库里包含了暂存区。暂存区通过commit提交到版本库，然后才可以push到远程仓库。

Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

2.1.5 思考

1. git为什么要设计暂存区呢？

3 Git常用命令

在git的窗口中，使用的是Linux的命令

3.1 获取远程仓库到本地

可以通过Git提供的命令从远程仓库进行克隆，将远程仓库克隆到本地

命令为： git clone 远程Git仓库地址

远程Git仓库地址有两种形式，一种是HTTPS协议（HTTP安全协议），另一种是SSH协议（安全外壳协议）。HTTPS协议如果登录私有库必须提供用户名及密码。

3.2 操作本地仓库

Git工作目录下的文件存在两种状态：

untracked 未跟踪（未被纳入版本控制）

tracked 已跟踪（被纳入版本控制）

Unmodified 未修改状态

Modified 已修改状态

Staged 已暂存状态

这些文件的状态会随着我们执行Git的命令而发生变化

3.2.1 查看本地仓库的状态

命令形式：git status [-s]

3.2.2 添加工作区文件到暂存区

命令形式：git add 单个文件名 | 通配符
eg. git add . (通配符 . 代表全部文件)
添加一个或多个文件到暂存区

3.2.3 从暂存区返回工作区

修改文件后会从暂存区返回到工作区，需要再次add到暂存区提交

3.2.3 提交暂存区到版本库

命令形式：git commit -m ‘注释内容’ 提交暂存区内容到本地仓库的当前分支

3.3 操作远程仓库

3.3.1 查看远程仓库

命令形式：git remote
git remote show origin

3.3.2 从远程获取代码并合并本地的版本（更新本地代码为最新）

git pull的作用是，从远程库中获取某个分支的更新，再与本地指定的分支进行自动merge。

$ git pull <远程库名> <远程分支名>:<本地分支名>

比如，取回远程库中的develop分支，与本地的develop分支进行merge，要写成：

git pull origin develop:develop

如果是要与本地当前分支merge，则冒号后面的<本地分支名>可以不写。只需要远程的仓库名和分支名。

git pull origin develop

3.3.3 解决冲突（可能有或者没有冲突）

3.3.4 推送到远程仓库

命令形式：git push 【remote name】【branch name】

3.4 其他一些命令

3.4.1 查看日志文件

命令形式：git log

3.4.2 从远程仓库中抓取和拉取

抓取 命令形式：git fetch【remote name】【branch name】

git fetch 是从远程仓库获取最新版本到本地仓库，不会自动merge

合并远程分支内容到当前,命令形式: git merge【remote name】【branch name】
git pull【remote name】【branch name】包含了fetch和merge两个操作

3.4.3 git diff 命令详解

查看分支上的差异：

3.4.4 git reset命令（版本回退）

你不断对文件进行修改，然后不断提交修改到版本库里，每当你觉得文件修改到一定程度的时候，Git就可以“保存一个快照”，这个快照在Git中被称为commit。一旦你把文件改乱了，或者误删了文件，还可以从最近的一个commit恢复，然后继续工作。
先使用git log查看commit的id


HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭

3.4.5 git stash 保存当前工作进度

git stash list
显示保存进度的列表。也就意味着，git stash命令可以多次执行。
git stash pop stash@{n}恢复指定的进度到工作区

4 关于冲突的问题

4.1 冲突场景

在一段时间，A、B用户修改了同一个文件，且修改了同一行位置的代码，此时会发生合并冲突。

A用户在本地修改代码后优先推送到远程仓库，此时B用户在本地修订代码，提交到本地仓库后，也需要推送到远程仓库，此时B用户晚于A用户，故需要先拉取远程仓库代码，经过合并后才能推送代码。在B用户拉取代码时，因为A、B用户同一段时间修改了同一个文件的相同位置代码，故会发生合并冲突。

解决：

根据业务需要解决：

4.2 撤销修改

丢弃工作区的修改
git checkout – filename

git checkout -- hello.java

tips：注意需要有–，否则没有–，就变成了“切换到另一个分支”的命令

从暂存区退回到工作区：

#回到add之前的状态，但是你的修改还在
git reset HEAD <file>
#再回到未修改的状态
git checkout -- hello.java

从版本库（已经commit过的状态）退回到工作区：
git reset命令，3.4.4的版本回退那节

git reset --hard commitId

5 分支

几乎所有的版本控制系统都以某种形式支持分支。 使用分支意味着你可以把你的工作从开发主线上分离开来进行重大的Bug修改、开发新的功能，以免影响开发主线。

在开发中，一般有如下分支使用原则与流程：

• master （生产） 分支

  线上分支，主分支，中小规模项目作为线上运行的应用对应的分支；

• test（测试）分支

  从master创建的分支，一般作为测试部门的测试分支，进行预发测试。测试完成后，需要合并到master分支，进行发版上线，中小规模项目可省略此分支；

• develop（开发）分支

  从test创建的分支，如果开发没有test分支，是从master创建的分支，一般作为开发部门的主要开发分支，如果没有其他并行开发不同期上线要求，都可以在此版本进行开发，阶段开发完成后，需要是合并到test分支继续测试，如果没有test分支，可直接合并到master分支。

• develop_xxx分支

  从develop创建的分支，一般是同期并行开发，但不同期上线时创建的分支，一般是合并到develop分支。

• hotfix(bugfix)分支，

  从master派生的分支，一般作为线上bug修复使用，修复完成后需要合并到master、test、develop分支。

5.1 分支概述

Git都把每次commit时间点串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。
关于分支

5.2 常用命令

5.1.1 查看分支

查看本地分支
​ git branch
查看远程分支
​ git branch -r
查看所有分支
​ git branch -a

5.1.2 创建分支

git branch dev_01

5.1.3 切换分支

git checkout dev_01

5.1.4 分支推送至远程仓库

把dev_01分支推送至远程仓库的dev_01分支

5.1.4 合并分支

在哪个分支开始合并：从下往上合并：master派生出dev，此时合并要先切换到master上来合并dev分支。

dev_01合并到master分支：
git checkout master
git merge dev_01

遇到的问题1：子父关系顺序不对
将dev_01合并到master，提示说already up to date
实际是并没有合并到master分支；
可能的原因：dev_01已经被merge过了，在merge之后master上又增加了新的东西，使用gitk查看：dev_01已经在master下面了，master作为父级了，所以默认master已经是最新的，不需要合并了。
总之要满足：master的时间线在dev的后面才可以将dev合并

遇到的问题2：冲突
master修改了提交了，dev修改了提交了，合并有可能会冲突

5.1.6 删除分支

git branch -d dev
git branch 查看

5.3 分支策略

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

6 其他事项

采用ssh协议：
需要产生公钥和私钥
.git中的config文件查看url是否采用http还是ssh协议