直接从官网下载，改一下路径确认安装即可。若桌面右键有下面两个命令即为安装成功

• Git GUI：Git提供的图形界面工具
• Git Bash：Git提供的命令行工具——类似一个极简的Linux命令行窗口

当安装Git后首先要做的事情是设置用户名称和email地址。这是非常重要的，因为每次Git提交都会使用该用户信息

1. 打开Git Bash

2. 设置用户信息

   git config --global user.name “itcast”
   git config --global user.email “[email protected]”
   复制

3. 查看配置信息——设置完后可以使用下面的命令进行验证

   git config --global user.name
   git config --global user.email
   复制

有些常用的指令参数非常多，每次都要输入好多参数，我们可以使用别名。最简单的配置方式如下：

1. 打开用户目录，创建 .bashrc 文件
   部分windows系统不允许用户创建点号开头的文件，可以打开Git Bash,执行 touch ~/.bashrc

2. 在 .bashrc 文件中输入如下内容

   #用于输出git提交日志 
   alias git-log='git log --pretty=oneline --all --graph --abbrev-commit' 
   #用于输出当前目录所有文件及基本信息 
   alias ll='ls -al'
   复制

3. 打开gitBash，执行 source ~/.bashrc

较为通用的方案

1. 打开GitBash执行下面命令

   git config --global core.quotepath false
   复制

2. ${git_home}/etc/bash.bashrc 文件最后加入下面两行

   ${git_home}即你Git的安装根目录

   export LANG="zh_CN.UTF-8" 
   export LC_ALL="zh_CN.UTF-8"
   复制

前面我们已经知道了Git中存在两种类型的仓库，即本地仓库和远程仓库。那么我们如何搭建Git远程仓库呢？我们可以借助互联网上提供的一些代码托管服务来实现，其中比较常用的有GitHub、码云、GitLab等。

• GitHub（ 地址：https://github.com/ ）是一个面向开源及私有软件项目的托管平台，因为只支持Git 作为唯一的版本库格式进行托管，故名GitHub

• 码云（地址： https://gitee.com/ ）是国内的一个代码托管平台，由于服务器在国内，所以相比于 GitHub，码云速度会更快

• GitLab （地址： https://about.gitlab.com/ ）是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的web服务，一般用于在企业、学校等内部网络搭建git私服。

以码云为例，先创建账号，创建账号后

当成功与远程仓库连接后会在计算机本地生成凭证

作用：查看修改的状态（暂存区、工作区）

git status
复制

作用：添加工作区一个或多个文件的修改到暂存区

命令形式：git add 单个文件名|通配符

git add file.txt # 添加单个文件
git add . # 将所有修改加入暂存区
复制

作用：提交暂存区内容到本地仓库的当前分支

命令形式：git commit -m ‘注释内容’

git commit -m "XXX update"
复制

配置的别名git-log就包含了这些参数，所以后续可以直接使用指令 git-log

作用:查看提交记录

命令形式：git log [option] 或者 git-log

• —all 显示所有分支
• —pretty=oneline 将提交信息显示为一行
• —abbrev-commit 使得输出的commitId更简短
• —graph 以图的形式显示

作用：版本切换

命令形式：

git reset --hard commitID # commitID 可以使用 git-log 或 git log 指令查看
复制

每一次提交文件都会生成一个唯一的ID，我们就是通过这个ID进行回退版本。当然上面的git-log（这是我们配置的指令别名其实是加了多个限制条件来优化结果的log命令）和git log只能看到未清除的历史记录，那么如何查看已经删除的记录？

git reflog：这个指令可以看到已经删除的提交记录

我们可以在reflog里面知道删除文件的id，我们可以直接使用命令：
git reset --hard commitID 还原

所以git reset --hard commitID既可以做版本回退，也可以做版本还原（找回删除的记录）

标签操作（相当于快照，给某个时间点的状态手动打上标签）

• 列出已有的标签 :git tag
• 创建标签:git tag [name]
• 将标签推送至远程仓库:git push [shortName] [name]
• 检出标签:检出的时候需要创建一个新的分支来记录
  • git checkout -b [branch] [name]

一般我们总会有些文件无需纳入Git 的管理，也不希望它们总出现在未跟踪文件列表。 通常都是些自动生成的文件，比如日志文件，或者编译过程中创建的临时文件等。 在这种情况下，我们可以在工作目录中创建一个名为 .gitignore 的文件（文件名称固定），列出要忽略的文件模式（语法像正则，也支持路径）

git branch
复制

git branch 分支名
复制

git checkout 分支名
复制

我们还可以直接切换到一个不存在的分支（创建并切换）：

git checkout -b 分支名
复制

一个分支上的提交可以合并到另一个分支

git merge 分支名
复制

该项职责由git管理员来完成。例如当开发分支Develop上的所有功能已经完成时，需要合并到master上，此时：在本地创建dev分支并与远程dev分支对应

git checkout -b dev origin/dev
复制

切换到master分支

git checkout master
复制

本地的dev合并到master上（遇到冲突解决完后再次提交）

git merge dev
复制

推送到远程的master上（执行这项操作时，需要有操作远程master分支的权限）

git push origin master
复制

• 释放权限：

• 操作结果：

git branch -d 分支名 # 删除分支时，需要做各种检查（智能提示防止误删，一般是提到了暂存区但没有提交的内容）
git branch -D 分支名 # 不做任何检查，强制删除
复制

当两个分支上对文件的修改可能会存在冲突，例如同时修改了同一个文件的同一行，这时就需要手动解决冲突，如下图所示：

• 第一个count值表示的是当前分支修改的值

• 第二个count值是在dev分支修改的值

解决冲突步骤如下：

1. 处理文件中冲突的地方
2. 将解决完冲突的文件加入暂存区(add)
3. 提交到仓库(commit)

解决冲突后git-log查看记录：可以看到发生冲突的合并版本也会被记录

几乎所有的版本控制系统都以某种形式支持分支。 使用分支意味着你可以把你的工作从开发主线上分离

开来进行重大的Bug修改、开发新的功能，以免影响开发主线。

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

• master （生产） 分支
  线上分支，主分支，中小规模项目作为线上运行的应用对应的分支——经测试无误后发布的稳定版本供用户使用；

• develop（开发）分支
  是从master创建的分支，一般作为开发部门的主要开发分支，如果没有其他并行开发不同期上线要求，都可以在此版本进行开发，阶段开发完成后，需要是合并到master分支,准备上线。

例如我们要开发新功能，我们要可以在develop分支上在建一个分支，新功能一般叫做feature分支，开发完以后在合并到 develop分支上面去，而不是直接提交到master分支，最后项目做完了develop再合并到master分支上

develop和master分支是不可删除的

• feature/xxxx分支（用完可删）
  从develop创建的分支，一般是同期并行开发，但不同期上线时创建的分支，分支上的研发任务完成后合并到develop分支，用完后可删除。

• hotfifix/xxxx分支
  从master派生的分支，一般作为线上bug修复使用，修复测试完成后需要合并到master、test、develop分支。因为主分支线上代码存在bug，那么作为开发分支肯定也有相同的bug那么hotfifix分支修改bug后必然要合并到主分支的同时也要合并到开发分支来修复bug代码

• 还有一些其他分支，在此不再详述，例如test分支（用于代码测试）、pre分支（预上线分支）等等。

HEAD 指向当前所在的分支，类似一个活动的指针，表示一个「引用」。

HEAD 既可以指向「当前分支」的最新 commit，也可以指向历史中的某一次 commit (「分离头指针」的情况)。归根结底，HEAD 指向的就是某个提交点。

当我们做分支切换时，HEAD 会跟着切换到对应分支。

假如有一个场景：有两个分支，master 分支和 feature 分支。现在，feautre 分支需要合并回 master 分支。

fast-forward 合并方式是条件允许的情况，通过将 master 分支的 HEAD 位置移动到 feature 分支的最新提交点上，这样就实现了快速合并。这种情况，是不会新生成 commit 的。（快进模式）

git checkout master # 先切换到master分支
git merge feature # 将feature分支合并到当前分支上（master）
复制

--no-ff 的方式进行合并，master 分支就会新生成一次提交记录。

git checkout master # 先切换到master分支
git merge --no-ff feature # 将feature分支合并到当前分支上（master）
复制

如果条件满足时，merge 默认采用的 fast-forward 方式进行合并，除非你显示的加上 --no-ff 选项；而条件不满足时，merge 也是无法使用 fast-forward 合并成功的！

git merge 操作是区分上下文的。当前分支始终是目标分支，其他一个或多个分支始终合并到当前分支。这个注意点记住了，方便记忆！所以，当需要将某个分支合并到目标分支时，需要先切到目标分支上。

快进模式能够进行的条件是：源分支和目标分支之间没有分叉。 下图则是无法通过 HEAD 的快速移动实现分支的合并。

如果执行合并操作，默认会尝试 fast-forward 的方式进行合并，但是因为分叉了，所以此时会采用 no-ff 的方式进行合并，有新的 commit 生成了。最终的结果图如下：

git checkout master # 先切换到目标分支
git merge feature
复制

rebase 合并往往又被称为 「变基」。这里的「基」就是一个「基点」、「起点」的意思。git rebase 命令通常称为向前移植（forward porting）。

「变基」就是改变当前分支的起点。注意，是当前分支！ rebase 命令后面紧接着的就是「基分支」。与merge操作相反。

• 变基前：

• 执行命令：

git checkout feature # 切换到当前分支，或待变基分支
git rebase master # 变基

# 可合并为下面的语句
git rebase master feature
复制

• 变基后：

解释：rebase，变基，可以直接理解为改变基底。feature分支是基于master分支的B拉出来的分支，feature的基底是B。 而master在B之后有新的提交，就相当于此时要用master上新的提交来作为feature分支的新基底。实际操作为把B之后feature的提交存下来，然后删掉原来这些提交，再找到master的最新提交位置，把存下来的提交再接上去（新节点新commit id），如此feature分支的基底就相当于变成了E而不是原来的B了。（注意，如果master上在B以后没有新提交，那么就还是用原来的B作为基，rebase操作相当于无效，此时和git merge就基本没区别了，差异只在于git merge会多一条记录Merge操作的提交记录），图示：

从Develop分支分出两个分支，分属两个人员进行开发。F1分支开发完毕后，push到总分支。F2分支开发到F2_5时需要拉取最新代码。

• 如果F2分支采用git pull拉取最新代码：

  • F1分支的视角（F1分支的commit记录）：

    

  • F2分支的视角：这将会把F1分支的修改直接拉下来于本地代码merge，且产生一个commit F2_5，也就是merge commit。

    

• 如果F2分支采用git pull --rebase 拉取最新代码：

  • F1分支视角不变
  • F2分支视角：