Git基础

1. 版本控制工具应该具备的功能

• 协同修改
  多人并行不悖的修改服务器端的同一个文件。
• 数据备份
  不仅保存目录和文件的当前状态，还能够保存每一个提交过的历史状态。
• 版本管理
  在保存每一个版本的文件信息的时候要做到不保存重复数据，以节约存储空 间，提高运行效率。这方面 SVN 采用的是增量式管理的方式，而 Git 采取了文 件系统快照的方式。
• 权限控制
  对团队中参与开发的人员进行权限控制。
  对团队外开发者贡献的代码进行审核——Git 独有。
• 历史记录
  查看修改人、修改时间、修改内容、日志信息。
  将本地文件恢复到某一个历史状态。
• 分支管理
  允许开发团队在工作过程中多条生产线同时推进任务，进一步提高效率。

2. 版本控制简介

2.1版本控制

在 IT 开发过程中使用版本控制思想管理代码的版本迭代。

2.2版本控制工具

集中式版本控制工具： CVS、SVN、VSS……

分布式版本控制工具： Git、Mercurial、Bazaar、Darcs……

3.Git简介

Git简史

Git算法验证原理

哈希算法，Git底层采用SHA-1算法

Git官网

https://git-scm.com/

Git优点

大部分操作在本地，无需联网
分支操作流畅
与Linux全面兼容

Git安装过程(只记录注意的点，其它全是默认)

Git结构

Git和代码托管中心

托管中心任务——维护远程库
局域网——Gitlab服务器
外网——GitHub、码云Gitee

本地库和远程库

团队内部

第三方开发

4.Git常用命令

本地库初始化：

git init
注: .git文件是隐藏文件需要ls -lA查看。.git目录中存放的是本地库相关的子目录和文件，不要删除，也不要胡乱修改。

设置签名

形式：用户名：XXX Email地址：XXX
作用：区分不同开发人员的身份
辨析：这里设置的签名和登录远程库(代码托管中心)的账号、密码没有任何关系。

命令(两种)：

1.项目级别/仓库级别：仅在当前本地库范围内有效
git config user.name XXX
git config user.email XXX
信息保存位置：./.git/config 文件
2.系统用户级别：登录当前操作系统的用户范围
git config --global user.name XXX
git config --global XXX
信息保存位置：~/.gitconfig 文件

级别优先级

1.就近原则：项目级别优先于系统用户级别，二者都有时采用项目级别的签名
2.如果只有系统用户级别的签名，就以系统用户级别的签名为准
3.二者都没有不允许

状态查看：

git status

添加添加：

git add [filename]
将工作区的修改添加到暂存区

提交：

git commit -m “commit message” [filename]
将暂存区的内容提交到本地库
git commit -am “commit message” [filename] 可跳过上一步add

查看历史记录：

git log
空格向下翻页，b向上翻页，q退出

git log --pretty=oneline

git log --oneline

git reflog(常用)

–oneline ：查看历史记录的简洁版本
–graph ：查看历史中什么时候出现了分支、合并
–reverse ：逆向显示所有日志
–author ：查找指定用户的提交日志
–since、–before、 --until、–after： 指定帅选日期
–no-merges ：选项以隐藏合并提交

前进后退

本质是指针HEAD的前进后退
基于索引值操作[推荐]
git reset --hard [局部索引值]
使用^符号：只能后退
git reset --hard HEAD^
注：一个^表示后退一步，n 个表示后退 n 步
使用~符号：只能后退
git reset --hard HEAD~n
注：表示后退 n 步

reset命令的三个参数对比

–soft 仅在本地库移动指针
–mixed 在本地库移动指针，并重置暂存区
–hard 在本地库移动指针，重置暂存区和工作区

取消缓存：

git reset HEAD [filename]

删除：

工作目录中删除：git rm
删除之前修改过并且已经放到暂存区域的话，则必须要用强制删除选项：git rm -f
从暂存区删除，但在工作目录中保留git rm --cache [filename]
递归删除：git rm -r *

删除文件并找回

前提：删除前，文件存在时的状态提交到了本地库。
操作：git reset --hard [指针位置]
删除操作已经提交到本地库：指针位置指向历史记录
删除操作尚未提交到本地库：指针位置使用 HEAD

比较文件差异 (同一个文件[文件名]可不写)

尚未缓存的改动：git diff [文件名]
查看已缓存的改动： git diff --cached [文件名]
查看已缓存的与未缓存的所有改动：git diff HEAD [文件名]
显示摘要而非整个 diff：git diff --stat

移动或重命名：

git mv [file] [newfile]

5.Git分支管理

什么是分支？

版本控制中，使用多条线同时推进多个任务

优点：

提高开发效率；
一个分支失败其他分支不受影响，失败的分支重新开始即可。

常用命令

创建分支命令：

git branch (branchname)
注：执行git init 的时候，默认情况下会创建master分支。

删除分支命令：

git branch -d (branchname)

查看分支：

git branch -v

切换分支命令：

git checkout (branchname)
注：git checkout -b (branchname) 命令来创建新分支并立即切换到该分支

合并分支命令：

git merge
第一步：切换到接受修改的分支（被合并，增加新内容）上 git checkout [被合并分支名]
第二步：执行 merge 命令 git merge [有新内容分支名]

解决冲突步骤：

第一步：编辑文件，删除特殊符号
第二步：把文件修改到满意的程度，保存退出
第三步：git add [文件名]
第四步：git commit -m “日志信息”(注意：此时 commit 一定不能带具体文件名)

Git分支类型

master 分支

• master 为产品主分支，该分支为只读唯一分支，也是用于部署生产环境的分支，需确保master分支的稳定性。
• master 分支一般由release分支或hotfix分支合并，任何情况下都不应该直接修改master分支代码。
• 产品的功能全部实现后，最终在master分支对外发布，另外所有在master分支的推送应该打标签（tag）做记录，方便追溯。
• master 分支不可删除。

develop 分支

• develop 为主开发分支，基于master分支创建，始终保持最新完成功能的代码以及bug修复后的代码。
• develop 分支为只读唯一分支，只能从其他分支合并，不可以直接在该分支做功能开发或bug修复。
• 一般开发新功能时，feature分支都是基于develop分支下创建的。
• develop 分支包含所有要发布到下一个release的代码。
• feature功能分支完成后, 开发人员需合并到develop分支(不推送远程)，需先将develop分支合并到feature，解决完冲突后再合并到develop分支。
• 当所有新功能开发完成后，开发人员并自测完成后，此时从develop拉取release分支，进行提测。
  release或hotfix 分支上线完成后, 开发人员需合并到develop分支并推送远程。
• develop 分支不可删。

feature 分支

• feature 分支通常为新功能或新特性开发分支，以develop分支为基础创建feature分支。
• 分支命名: feature/ 开头的为新特性或新功能分支
• 建议的命名规则: feature/user_createtime_feature，例如：feature/ftd_20201018_alipay，含义为：开发人员ftd在2020年10月18日时创建了一个支付宝支付的功能分支。
• 新特性或新功能开发完成后，开发人员需合到develop分支。
• feature 分支可同时存在多个，用于团队中多个功能同时开发。
• feature 分支属于临时分支，功能完成后可选删除。

release 分支

• release 分支为预上线分支，基于本次上线所有的feature分支合并到develop分支之后，从develop分支创建。
• 分支命名: release/ 开头的为预上线分支
• 建议的命名规则: release/version_publishtime，例如：release/v2.1.1_20201018，含义为：版本号v2.1.1计划于2020年10月18日时发布。
• release 分支主要用于提交给测试人员进行功能测试。发布提测阶段，会以release分支代码为基准进行提测。测试过程中发现的bug在本分支进行修复，上线完成后需合并到develop/master分支并推送远程。
• release 分支属于临时分支，产品上线后可选删除。
  ❝ 当有一组feature开发完成后，首先开发人员会各自将最新功能代码合并到develop分支。进入提测阶段时，开发组长在develop分支上创建release分支。 如果在测试过程中发现bug需要修复，则直接由开发者在release分支修复并提交。当测试完成后，开发组长将release分支合并到master和develop分支，此时master为最新可发布代码，用作产品发布上线。
  ❞

hotfix 分支

• hotfix 分支为线上bug修复分支或叫补丁分支，主要用于对线上的版本进行bug修复。
• 分支命名: hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似
• 建议的命名规则: hotfix/user_createtime_hotfix，例如：hotfix/ftd_20201018_alipaybugfix，含义为：开发人员ftd在2020年10月18日时创建了一个支付宝支付bug修复的分支。
• hotfix 分支用于线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支。当问题修复完成后，需要合并到master分支和develop分支并推送远程。
• 所有hotfix分支的修改会进入到下一个release。
• hotfix 分支属于临时分支，bug修复上线后可选删除。