Git 详解（原理、使用）

git 快速上手请看这篇博客 Git 快速上手

1. 什么是 Git

Git 是目前最主流的一个版本控制器，并且是分布式版本控制系统，可以控制电脑上所有格式的文档

版本控制器：记录每次修改以及版本迭代的管理系统

• 对于文本文件，可以记录每次对这个文件的内容进行了怎样的修改

• 对于二进制文件，具体内容进行了怎样的修改，他没法管理，但可以知道文件大小等方面的变化

2. 安装

常用命令

• 查看当前安装的 git 版本

git --version

• Cent OS 安装

yum install git -y

• Ubuntu 安装

apt-get install git -y

• windows 安装

  下载安装包直接安装即可，在这里下载

  安装过程中除了安装路径需要修改之外，其他都用默认的即可

要用 Git 来管理文件，必须将文件放在 Git 仓库中，只有仓库中的文件才会被 Git 管理

3. 创建本地仓库

1. 创建一个目录（工作区）

mkdir mystore

2. 进入这个目录

cd mystore

3. 创建 git 本地仓库

git init

此命令执行成功之后会在当前目录中生成一个 .git 隐藏目录（版本库），用来追踪管理仓库，注意不要手动修改这个目录中的文件

4. 配置本地仓库的 name 和 email

   全局配置的添加和删除需要加上 --global

git config user.name "ly"
git config user.email "361@163.com"

• 查看刚才的配置

  git config -l
  

• 删除某一项配置

  git config --unset user.name
  

4. 使用 Git 管理

工作区：并未被 Git 管理

暂存区（stage，/index）：暂时存放工作区中修改的内容（git 对象的索引）

objects 对象库：修改的工作区内容会写入对象库中一个新的 git 对象中，通过对这些 git 对象的管理维护便可实现对文件的版本管理，故每次 Add 操作都会在版本库中新增一个 git 对象

HEAD：指针，指向某个分支，如 master 分支，存储的也是 git 对象的索引

如果只是单纯将文件置于 mystore 目录下（工作区），Git 是不会进行管理的，需要进行 Add 以及 Commit 操作将要管理的内容置于版本库中之后才会被 Git 管理

4.1 将工作区中的文件使用 Git 进行管理

4.1.1 Add

将工作区中所有的修改内容添加到版本库的暂存区中

git add .
git add 指定某个要添加的修改文件，多个文件用空格分隔

. 表示所有修改的内容

4.1.2 Commit

将暂存区中的目录树写入 HEAD 指向的相应分支下，即将暂存区中的内容提交到相应分支下

经过 commit 操作之后才算真正意义上写入到了版本库

git commit -m "这里对本次提交的内容进行描述，如：普通用户提交个人信息功能完成"

每次提交都会有一个 commit id，可以在 git 中看到

• 查看提交记录（时间从近到远）

git log
git log --pretty=oneline  # 每次提交打印一行

refs/head/master 中存放的是最近一次提交的 commit id

commit id：是一个索引，指向一个 git 对象，前两位表示 objects 中的目录名，之后的内容表示目录名中的文件名

查看 objects 中某个文件：git cat-file -p commit-id

注意：Git 管理的不是文件，而是文件的修改

• 查看仓库状态

  查看从上次提交到现在是否对文件进行过修改，暂存区是否还有修改未提交，工作区是否还有修改未添加到暂存区。但不能看到对文件进行了怎样的修改

  git status
  

• 查看暂存区和工作区差异

  git diff 文件名
  

• 查看版本库和工作区的差异

  git diff HEAD -- 文件名
  

• 查看某次提交的代码修改

  git show commitid
  

4.2 版本回退

本质回退的是版本库中的内容

git reset [--soft | --mixed | --hard] [HEAD]

• –soft：只回退版本库中的内容
• –mixed（默认选项）：版本库和暂存区中的内容都进行回退
• –hard：工作区、暂存区、版本库中的内容都进行回退

版本库中维护了多个 git 对象，版本回退本质上是将 HEAD -> master 的指向进行了改变，原本指向最近一次修改的 git 对象，回退到上一个提交，就只需要将 master 指向前一个 提交的 git 对象即可

• 查看本地的每次执行的命令及 commit id

  git reflog
  

4.3 撤销修改

对工作区中的文件进行修改之后想要撤销，将工作区的修改回退到最近一次 add 或 commit 之后的状态

git checkout -- 文件名

分别处于一下状态时，如何回退

工作区	暂存区	版本库	操作
√			git checkout – filename
√	√		1. git reset --hard HEAD^ 2. git reset --mixed HEAD; git checkout – filename
√	√	√	git reset --hard HEAD^（前提是代码未进行 push）

• 删除文件

  git rm filename
  

  会直接在工作区和暂存区中都删除掉，只需要再执行 commit 即可删除

4.4 和远程仓库建立关联

git remote add origin 远程仓库链接

5. 分支管理

5.1 为什么要分支

以软件开发为例，通常情况下一个产品最少有一个生产环境和开发环境，通常在开发环境中经过测试没有问题后将程序部署到生产环境，而不会直接在生产环境乱搞，因为一旦生产环境出现问题，将会造成严重损失。

我们可以通过分支，将 master 分支（稳定代码）作为生产环境的代码，在 dev 分支进行新功能的开发，经过测试没有问题之后再合并到 master 分支，这样对 master 分支代码的影响就会降低

当然，也可以通过分支来更好的进行协同开发，以 master 作为主分支，多人协同开发时，每个人都在自己的分支上进行开发，测试没有问题之后再合并到 master 分支上

5.2 分支管理

• 查看当前仓库有哪些分支

  git branch
  

  HEAD 指向的分支就是工作分支，工作分支名字前面有 * 标记

• 创建分支

  git branch 分支名
  

  成功创建分支之后，当前分支也指向最近一次提交的 git 对象

• 切换工作分支

  git checkout 分支名
  

  git checkout -b 新分支名 可同时实现创建新分支和切换到新分支的操作

• 合并分支

  在 master 分支中合并 abc 分支

  git merge abc
  

  当合并分支有冲突时，需要手动解决冲突，并再次提交（Add，Commit）（no fast-forward）

  • no ff：可以在提交分支中明显看到合并操作

  • ff：不能区分出来是 maser 提交的还是分支合并的

    可以使用 git merge --no-ff -m "合并分支" 分支名 来实现，这样在分支图中就可以清楚的辨别

• 删除分支

  git branch -d abc
  

  若在分支未被合并之前就要删除分支，则这里的 d 需要改为大写，表示强行删除

• 可视化分支及提交记录

  git log --graph --abbrev-commit
  

5.3 bug 分支

当 master 分支出现 bug 时，不能直接在 master 分支上进行修改，因为有可能会由于此次修改而引入其他 bug

如果在 dev 分支上开发的过程中，发现 master 分支存在 bug，一般不会直接在 dev 分支上进行 bug 修复，而是基于 master 分支新建分支来专门处理这个 bug

1. 在 dev 分支上的已被 git 管理而未进行 add 的修改内容，可以通过 git stash 来将工作区中的内容进行存储，否则切换到 master 分支中，也能看到在 dev 分支中对工作区中内容的修改。
2. 基于 master 分支创建新分支进行 bug 修复，并将其合并到 master 分支，删除这个用于修复 bug 的分支
3. 切换到 dev 分支，将存储区中的内容恢复 git stash pop，继续进行开发，然后提交
4. 将 dev 分支合并 master 分支并测试，这样即使合并有冲突，也不会影响 master 分支的代码，若合并之后有冲突，在 dev 分支上进行修改测试，解决问题之后再提交，然后合并到 master 上，就不用再 master 分支上再解决冲突了

6. 本地仓库与远程仓库的交互

6.1 克隆

• 克隆远程仓库到本地

  git clone 远程仓库链接
  

  1. HTTP 方式

     直接克隆

  2. SSH 方式

     SSH 是非对称加密，需要将本地的公钥配置到 git 服务器上

     首先在用户主目录查看是否有 .ssh 目录，若有，进入查看是否有 id_rsa、id_rsa.pub 这两个文件，若有，则直接将 id_rsa.pub 中的内容在 git 服务器上进行配置，即可通过 SSH 方式克隆仓库。若没有这两个文件，则执行以下命令生成 SSH 密钥文件，然后在 git 服务器上配置。配置完成后即可进行克隆

     ssh-keygen -t rsa -C "邮箱地址"
     

• 查看远程仓库

  git remote
  git remote -v
  

6.2 推送

将本地的修改推送到远程仓库

git push origin 本地分支:远程分支

push 操作是远程分支和本地分支之间的交互，要让两个分支建立链接，才能推送成功。克隆时，git 会自动对 master 分支建立链接

6.3 拉取

远程仓库的代码可能被其他用户修改了，需要将远程仓库代码拉取到本地

git pull origin 远程分支:本地分支

这里本质上是两个操作，1. 拉取；2. 合并

• 拉取分支内的内容，需要建立连接，或者指定分支

• 拉取仓库内容，无需建立连接或指定分支

6.4 .gitignore 文件

有的文件不需要被 git 追踪管理，可以将其添加到 .gitignore 文件中（存在于工作区根目录），在进行 add、commit、push 等操作时，就会忽略这些文件。

# 忽略 .idea 文件以及以 .out 结尾的文件
.idea
*.out

# 不忽略 today.out 文件
!today.out

• 如果有的文件添加到了 .gitignore 中，又想上传上去，则可使用以下命令强制上传

  git add -f 文件名
  

当 .ignore 文件特别多，有的时候上传文件，被忽略，已经不知道哪一项配置导致的，可以使用 git check-ignore -v 文件名 来得知

给命令配置别名

git config --global alias.con config

7. 标签管理

通过标签，来对某个 commit id 进行标记，相当于 commit id 的别名，可以通过标签来标记重要的版本以及对 commit id 的语义化

在 .git 目录中管理了 tags

• 为最近一次提交打标签

  git tag 标签名
  

• 查看所有标签

  git tag
  

• 为之前的某次提交打标签

  git tag 标签名 commitid
  

• 打标签带上描述信息

  git tag -a 标签名 -m "描述信息" commitid
  

• 查看某个标签

  git show 标签名
  

• 删除标签

  git tag -d 标签名
  

  要删除远程仓库的标签，需要在本地删除之后，进行 push

  git push origin :标签名
  

• 推送本地标签到远程仓库

  git push origin 标签名
  

• 推送所有标签

  git push origin --tags
  

8. 其他

• 创建本地分支并和远程分支建立链接

  git checkout -b 分支名 origin/分支名
  

  git branch –-set-upstream-to=远程仓库名/远程分支名 本地分支名
  

• 查看链接

  git branch -vv
  

8.1 同一分支上多人协作开发

1. 开发完毕后进行 push
2. 若有冲突，无法 push，则先进行 pull
3. 本地解决冲突，重新提交并 push
4. 合并分支，删除开发分支

8.2 多人多分支协作

让某个功能私有某一个分支

8.3 合并分支

分支的合并可以在本地进行也可以在远程仓库进行（PR）

PR：开发人员在完成某个功能的开发之后，填写 PR 申请单，向管理员发起分支合并的申请，由管理员审核并决定是否要合并，管理员审核通过之后即可自动在远程仓库合并

• 查看远程分支情况

  git remote show origin
  

• 删除 stale 的分支

  git remote prune origin
  

DevOps（Development Operations）：重视开发和运维人员沟通合作的。通过自动化 “软件交互” 和 “架构变更” 的流程，使得构建、测试、发布能更加方便高效可靠。DevOps 的软件开发过程包含计划、编码、构建、测试、预发布、运维、监控。

8.4 环境隔离

为了使最终发布上线的代码的更稳定，需要部署稳定的代码到服务器上，而不会直接在用户直接访问到的服务器上进行开发和测试。因此需要有多个环境来分别进行开发、测试、部署等。也就有了开发环境、测试环境、预发布环境、灰度环境、生产环境等。

8.5 Git Flow 模型

Git Flow 是一个非常常见的分支模型。

分支	名称	适用环境	解释
master	主分支	生产环境
develop	开发分支	开发环境
release	预发布分支	预发布 / 测试环境
feature	需求开发分支	本地
hotfix	紧急修复分支	本地

8.5.1 master 分支

只读。用于部署生产环境，一般由合并 release 分支得到。所有的 master 分支的推送都要打标签记录，便于追溯，且 master 分支不能删除。

8.5.2 feature 分支

基于 develop 分支创建，用于新功能或新特性的开发，开发完成之后，将 feature 分支合并到 develop 分支，后删除。

• 命名规则：feature/user_createtime_feature(功能描述)

8.5.3 develop 分支

基于 master 分支创建，只读，记录开发提交，始终保持最新完成以及 bug 修复后的代码

8.5.4 release 分支

预发布分支，在 feature 分支合并到 develop 分支之后，基于 develop 分支创建 用于提交给测试人员进行测试。若测试有问题，则需要开发者在 develop 分支上看看是否存在问题，然后在 feature 分支上进行修复。release 分支属于临时分支，代码上线后可删除

• 命名规则：release/version_publishtime

8.5.5 hotfix 分支

用于对 master 分支的 bug 进行修复（紧急修复），基于 master 分支创建，然后修复 bug，之后将该分支合并到 master 分支以及 develop 分支

8.6 git 相关图标无法显示的问题

在注册表的以下目录中将 Max Cached Icons 改为 2000，并将 ShellIconOverlayIdentifiers 目录下和 git 相关的目录通过缩进排到最前面即可

HKEY_LOCAL_MACHINE\Software\Microsoft\windows\CurrentVersion\Explorer\

git pull 与 git push 命令 是否和所在分支相关
试。若测试有问题，则需要开发者在 develop 分支上看看是否存在问题，然后在 feature 分支上进行修复。release 分支属于临时分支，代码上线后可删除

• 命名规则：release/version_publishtime

8.5.5 hotfix 分支

用于对 master 分支的 bug 进行修复（紧急修复），基于 master 分支创建，然后修复 bug，之后将该分支合并到 master 分支以及 develop 分支

8.6 git 相关图标无法显示的问题

在注册表的以下目录中将 Max Cached Icons 改为 2000，并将 ShellIconOverlayIdentifiers 目录下和 git 相关的目录通过缩进排到最前面即可

HKEY_LOCAL_MACHINE\Software\Microsoft\windows\CurrentVersion\Explorer\