Git

https://www.bilibili.com/video/BV1vy4y1s7k6?p=1

Git 安装

官网地址： https://git-scm.com

选择 Git 安装位置，要求是非中文并且没有空格的目录，然后下一步

Git 选项配置，推荐默认设置，然后下一步。

Git 安装目录名，不用修改，直接点击下一步

Git 的默认编辑器，建议使用默认的 Vim 编辑器，然后点击下一步

默认分支名设置，选择让 Git 决定，分支名默认为 master，下一步。

修改 Git 的环境变量，选第一个，不修改环境变量，只在 Git Bash 里使用 Git。

选择后台客户端连接协议，选默认值 OpenSSL，然后下一步

配置 Git 文件的行末换行符，Windows 使用 CRLF，Linux 使用 LF，选择第一个自动转换，然后继续下一步。

选择 Git 终端类型，选择默认的 Git Bash 终端，然后继续下一步

选择 Git pull 合并的模式，选择默认，然后下一步。

选择 Git 的凭据管理器，选择默认的跨平台的凭据管理器，然后下一步

其他配置，选择默认设置，然后下一步。

实验室功能，技术还不成熟，有已知的 bug，不要勾选，然后点击右下角的 Install按钮，开始安装 Git。

点击 Finsh 按钮，Git 安装成功

右键任意位置，在右键菜单里选择 Git Bash Here 即可打开 Git Bash 命令行终端

在 Git Bash 终端里输入 git --version 查看 git 版本，如图所示，说明 Git 安装成功

Git 配置

Git 提供了一个叫做 git config 的工具，专门用来配置或读取相应的工作环境变量。
这些环境变量，决定了 Git 在各个环节的具体工作方式和行为。这些变量可以存放在以下三个不同的地方：

• /etc/gitconfig 文件：系统中对所有用户都普遍适用的配置。若使用 git config 时用 --system 选项，读写的就是这个文件。
• ~/.gitconfig 文件：用户目录下的配置文件只适用于该用户。若使用 git config 时用 --global 选项，读写的就是这个文件。
• 当前项目的 Git 目录中的配置文件（也就是工作目录中的 .git/config 文件）：这里的配置仅仅针对当前项目有效。每一个级别的配置都会覆盖上层的相同配置，所以 .git/config 里的配置会覆盖 /etc/gitconfig 中的同名变量。

在 Windows 系统上，Git 会找寻用户主目录下的 .gitconfig 文件。主目录即 $HOME 变量指定的目录，一般都是 C:\Documents and Settings\$USER。
此外，Git 还会尝试找寻 /etc/gitconfig 文件，只不过看当初 Git 装在什么目录，就以此作为根目录来定位。

用户信息

$ git config --global user.name "runoob"
$ git config --global user.email test@runoob.com

如果用了 --global 选项，那么更改的配置文件就是位于你用户主目录下的那个，以后你所有的项目都会默认使用这里配置的用户信息。

如果要在某个特定的项目中使用其他名字或者电邮，只要去掉 --global 选项重新配置即可，新的设定保存在当前项目的 .git/config 文件里。

说明：

签名的作用是区分不同操作者身份。用户的签名信息在每一个版本的提交信息中能够看 到，以此确认本次提交是谁做的。Git 首次安装必须设置一下用户签名，否则无法提交代码。

注意：

这里设置用户签名和将来登录 GitHub（或其他代码托管中心）的账号没有任 何关系。

文本编辑器

设置Git默认使用的文本编辑器, 一般可能会是 Vi 或者 Vim。

$ git config --global core.editor emacs

差异分析工具

还有一个比较常用的是，在解决合并冲突时使用哪种差异分析工具。比如要改用 vimdiff 的话：

$ git config --global merge.tool vimdiff

查看配置信息

要检查已有的配置信息，可以使用 git config --list 命令：

$ git config --list

有时候会看到重复的变量名，那就说明它们来自不同的配置文件（比如 /etc/gitconfig 和 ~/.gitconfig），不过最终 Git 实际采用的是最后一个。
这些配置我们也可以在 ~/.gitconfig 或 /etc/gitconfig 看到，如下所示：

vim ~/.gitconfig 

也可以直接查阅某个环境变量的设定，只要把特定的名字跟在后面即可，像这样：

$ git config user.name
runoob

Git工作流程

一般工作流程如下：

• 克隆 Git 资源作为工作目录。
• 在克隆的资源上添加或修改文件。
• 如果其他人修改了，你可以更新资源。
• 在提交前查看修改。
• 提交修改。
• 在修改完成后，如果发现错误，可以撤回提交并再次修改并提交。

Git 工作区、暂存区和版本库

基本概念

工作区:就是你在电脑里能看到的目录。

暂存区:英文叫stage, 或index。一般存放在.git目录下下的index文件（.git/index）中，所以我们把暂存区有时也叫作索引（index）。

版本库:工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。

图中左侧为工作区，右侧为版本库。在版本库中标记为 index 的区域是暂存区（stage, index），标记为 master 的是 master 分支所代表的目录树。

图中我们可以看出此时 HEAD 实际是指向 master 分支的一个游标。所以图示的命令中出现 HEAD 的地方可以用 master 来替换。

图中的 objects 标识的区域为 Git 的对象库，实际位于 .git/objects 目录下，里面包含了创建的各种对象及内容。

当对工作区修改（或新增）的文件执行 git add 命令时，暂存区的目录树被更新，同时工作区修改（或新增）的文件内容被写入到对象库中的一个新的对象中，而该对象的ID被记录在暂存区的文件索引中。

当执行提交操作（git commit）时，暂存区的目录树写到版本库（对象库）中，master 分支会做相应的更新。即 master 指向的目录树就是提交时暂存区的目录树。

当执行 git reset HEAD 命令时，暂存区的目录树会被重写，被 master 分支指向的目录树所替换，但是工作区不受影响。

当执行 git rm --cached <file> 命令时，会直接从暂存区删除文件，工作区则不做出改变。

当执行 git checkout .或者 git checkout -- <file> 命令时，会用暂存区全部或指定的文件替换工作区的文件。这个操作很危险，会清除工作区中未添加到暂存区的改动。

当执行 git checkout HEAD . 或者 git checkout HEAD <file> 命令时，会用 HEAD 指向的 master 分支中的全部或者部分文件替换暂存区和以及工作区中的文件。这个命令也是极具危险性的，因为不但会清除工作区中未提交的改动，也会清除暂存区中未提交的改动。

Git 创建仓库

版本库又名仓库，英文名repository，可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。

所以，创建一个版本库非常简单，首先，选择一个合适的地方，创建一个空目录：

$ mkdir learngit
$ cd learngit
$ pwd
/Users/michael/learngit

第二步，通过git init命令把这个目录变成Git可以管理的仓库

$ git init
Initialized empty Git repository in /Users/michael/learngit/.git/

瞬间Git就把仓库建好了，而且告诉你是一个空的仓库（empty Git repository），细心的读者可以发现当前目录下多了一个.git的目录，这个目录是Git来跟踪管理版本库的，没事千万不要手动修改这个目录里面的文件，不然改乱了，就把Git仓库给破坏了。

如果你没有看到.git目录，那是因为这个目录默认是隐藏的，用ls -ah命令就可以看见。
也不一定必须在空目录下创建Git仓库，选择一个已经有东西的目录也是可以的。

把文件添加到版本库

所有的版本控制系统，其实只能跟踪文本文件的改动，比如TXT文件，网页，所有的程序代码等等，Git也不例外。版本控制系统可以告诉你每次的改动，比如在第5行加了一个单词“Linux”，在第8行删了一个单词“Windows”。而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从100KB改成了120KB，但到底改了啥，版本控制系统不知道，也没法知道。

使用Windows的童鞋要特别注意：千万不要使用Windows自带的记事本编辑任何文本文件。原因是Microsoft开发记事本的团队使用了一个非常弱智的行为来保存UTF-8编码的文件，他们自作聪明地在每个文件开头添加了0xefbbbf（十六进制）的字符，你会遇到很多不可思议的问题，比如，网页第一行可能会显示一个?，明明正确的程序一编译就报语法错误，等等，都是由记事本的弱智行为带来的。

首次查看（工作区没有任何文件）

git status

>>>
On branch master
No commits yet
nothing to commit (create/copy files and use "git add" to track)

新增文件

现在编写一个readme.txt文件，内容如下：

Git is a version control system.
Git is free software.

一定要放到learngit目录下（子目录也行），因为这是一个Git仓库，放到其他地方Git再厉害也找不到这个文件。

再次查看（检测到未追踪的文件）

git status

>>>
On branch master
No commits yet
Untracked files:
	(use "git add <file>..." to include in what will be committed)

     hello.txt
         
nothing added to commit but untracked files present (use "git add" 
to track)

添加暂存区

第一步，用命令git add告诉Git，把文件添加到仓库：

$ git add readme.txt

执行上面的命令，没有任何显示，这就对了，Unix的哲学是“没有消息就是好消息”，说明添加成功。

查看状态（检测到暂存区有新文件）

git status
On branch master
No commits yet
Changes to be committed:
 (use "git rm --cached <file>..." to unstage)

	new file: hello.txt

提交本地库

$ git commit -m "wrote a readme file"
[master (root-commit) cb926e7] wrote a readme file
 1 file changed, 2 insertions(+)
 create mode 100644 readme.txt

-m后面输入的是本次提交的说明，可以输入任意内容，最好写下有意义的版本记录。
为什么Git添加文件需要add，commit一共两步呢？因为commit可以一次提交很多文件，所以你可以多次add不同的文件，比如：

$ git add file1.txt
$ git add file2.txt file3.txt
$ git commit -m "add 3 files."

add把文件提交到暂存区，但此时文件并没有真正进入到版本库当中，文件目前只处于一个中间状态。git commit(将暂存区文件提交到版本库中)。

git status: 可以让我们时刻掌握仓库当前的状态，上面的命令告诉我们，readme.txt被修改过了，但还没有准备提交的修改。
git status -s

Changes not staged for commit
stage缓存区 commit提交仓库

$ git diff readme.txt 

git diff:顾名思义就是查看difference，显示的格式正是Unix通用的diff格式，可以从上面的命令输出看到，我们在第一行添加了一个“distributed”单词。

执行 git diff 来查看执行 git status 的结果的详细信息。git diff 命令显示已写入缓存与已修改但尚未写入缓存的改动的区别。git diff 有两个主要的应用场景。

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

历史版本

查看历史版本

git reflog  查看版本信息
git log 查看版本详细信息

需要友情提示的是，你看到的一大串类似3628164...882e1e0的是commit id（版本号），和SVN不一样，Git的commit id不是1，2，3……递增的数字，而是一个SHA1计算出来的一个非常大的数字，用十六进制表示，而为什么commit id需要用这么一大串数字表示呢？因为Git是分布式的版本控制系统，后面我们还要研究多人在同一个版本库里工作，如果大家都用1，2，3……作为版本号，那肯定就冲突了。

每提交一个新版本，实际上Git就会把它们自动串成一条时间线。

首先，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交3628164...882e1e0（注意我的提交ID和你的肯定不一样），上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。

版本回退

$ git reset --hard HEAD^
HEAD is now at ea34578 add distributed

也可以指定回到未来的某个版本：

$ git reset --hard 3628164

版本号没必要写全，前几位就可以了，Git会自动去找。当然也不能只写前一两位，因为Git可能会找到多个版本号，就无法确定是哪一个了。

Git的版本回退速度非常快，因为Git在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git仅仅是把HEAD从指向append GPL

工作区和暂存区

Git和其他版本控制系统如SVN的一个不同之处就是有暂存区的概念。

工作区（Working Directory）: 就是你在电脑里能看到的目录，比如我的learngit文件夹就是一个工作区。

版本库（Repository）: 工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。

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

前面讲了我们把文件往Git版本库里添加的时候，是分两步执行的：

1. 第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；
2. 第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。

因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。

你可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。
然后，在工作区新增一个LICENSE文本文件（内容随便写）。
先用git status查看一下状态：

$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   readme.txt
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       LICENSE
no changes added to commit (use "git add" and/or "git commit -a")

Git非常清楚地告诉我们，readme.txt被修改了，而LICENSE还从来没有被添加过，所以它的状态是Untracked。
现在，使用两次命令git add，把readme.txt和LICENSE都添加后，用git status再查看一下：

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   LICENSE
#       modified:   readme.txt
#

所以，git add命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支。

$ git commit -m "understand how stage works"
[master 27c9860] understand how stage works
 2 files changed, 675 insertions(+)
 create mode 100644 LICENSE

一旦提交后，如果你又没有对工作区做任何修改，那么工作区就是“干净”的：

$ git status
# On branch master
nothing to commit (working directory clean)

如果你觉得 git add 提交缓存的流程太过繁琐，Git 也允许你用 -a 选项跳过这一步。命令格式如下：

git commit -am '修改 hello.php 文件'

git reset HEAD命令用于取消已缓存的内容。

$ git reset HEAD -- hello.php 

简而言之，执行 git reset HEAD 以取消之前 git add 添加，但不希望包含在下一提交快照中的缓存。

git rm: 如果只是简单地从工作目录中手工删除文件，运行 git status 时就会在 Changes not staged for commit 的提示。

要从 Git 中移除某个文件，就必须要从已跟踪文件清单中移除，然后提交。可以用以下命令完成此项工作

git rm <file>

如果删除之前修改过并且已经放到暂存区域的话，则必须要用强制删除选项 -f

git rm -f <file>

如果把文件从暂存区域移除，但仍然希望保留在当前工作目录中，换句话说，仅是从跟踪清单中删除，使用 --cached 选项即可

git rm --cached <file>

可以递归删除，即如果后面跟的是一个目录做为参数，则会递归删除整个目录中的所有子目录和文件：

git rm –r * 

git mv: 命令用于移动或重命名一个文件、目录、软连接。
我们先把刚移除的 README 添加回来：

$ git mv README  README.md
$ ls
README.md

Git 分支管理

几乎每一种版本控制系统都以某种形式支持分支。使用分支意味着你可以从开发主线上分离开来，然后在不影响主线的同时继续工作。
有人把 Git 的分支模型称为"必杀技特性"，而正是因为它，将 Git 从版本控制系统家族里区分出来。
创建分支命令：

git branch (branchname)

切换分支命令:

git checkout (branchname)

当你切换分支的时候，Git 会用该分支的最后提交的快照替换你的工作目录的内容， 所以多个分支不需要多个目录。
合并分支命令:

git merge 

你可以多次合并到统一分支， 也可以选择在合并之后直接删除被并入的分支。

列出分支

列出分支基本命令：

git branch

没有参数时，git branch 会列出你在本地的分支。

$ git branch
* master

此例的意思就是，我们有一个叫做"master"的分支，并且该分支是当前分支。当你执行 git init 的时候，缺省情况下 Git 就会为你创建"master"分支。如果我们要手动创建一个分支。执行 git branch (branchname) 即可。

$ git branch testing
$ git branch
* master
  testing

现在我们可以看到，有了一个新分支 testing。
当你以此方式在上次提交更新之后创建了新分支，如果后来又有更新提交， 然后又切换到了"testing"分支，Git 将还原你的工作目录到你创建分支时候的样子.

我们也可以使用 git checkout -b (branchname) 命令来创建新分支并立即切换到该分支下，从而在该分支中操作。

删除分支

删除分支命令：

git branch -d (branchname)

分支合并

一旦某分支有了独立内容，你终究会希望将它合并回到你的主分支。 你可以使用以下命令将任何分支合并到当前分支中去：即如果你要把和newtest、master合并，你要在 master上去操作 git merge newtest

$ git branch
* master
  newtest
$ ls
README        test.txt    test2.txt
$ git merge newtest
Updating 2e082b7..556f0a0
Fast-forward
 test2.txt | 1 -
 1 file changed, 1 deletion(-)
 delete mode 100644 test2.txt
$ ls
README        test.txt

合并冲突

冲突产生的原因： 合并分支时，两个分支在同一个文件的同一个位置有两套完全不同的修改。Git 无法替 我们决定使用哪一个。必须人为决定新代码内容。

合并并不仅仅是简单的文件添加、移除的操作，Git 也会合并修改。

$ git branch
* master
$ cat test.txt
runoob.com

解决冲突

1.编辑有冲突的文件，删除特殊符号，决定要使用的内容

特殊符号：

<<<<<<< HEAD
当前分支的代码 
=======
合并过来的代码 
>>>>>>> hot-fix

如下图：

修改完

2.添加到暂存区

Layne@LAPTOP-Layne MINGW64 /d/Git-Space/SH0720 (master|MERGING)
$ git add hello.txt

3,执行提交（注意：此时使用 git commit 命令时不能带文件名)

Layne@LAPTOP-Layne MINGW64 /d/Git-Space/SH0720 (master|MERGING)
$ git commit -m "merge hot-fix"
[master 69ff88d] merge hot-fix
--发现后面 MERGING 消失，变为正常
Layne@LAPTOP-Layne MINGW64 /d/Git-Space/SH0720 (master)

Git 团队协作机制

团队内协作

跨团队协作

GitHub

创建远程仓库

远程仓库操作

命令名称	作用
git remote -v	查看当前所有远程地址别名
git remote add 别名 远程地址	起别名
git push 别名 分支	推送本地分支上的内容到远程仓库
git clone 远程地址	将远程仓库的内容克隆到本地
git pull 远程库地址别名 远程分支名	将远程仓库对于分支最新内容拉下来后与当前本地分支合并

IDEA 集成 Git

配置 Git 忽略文件

IDEA 特定文件

Maven 工程的 target 目录

忽略步骤

1.创建忽略规则文件 xxxx.ignore（前缀名随便起，建议是 git.ignore）
这个文件的存放位置原则上在哪里都可以，为了便于让~/.gitconfig 文件引用，建议也放在用
户家目录下
git.ignore 文件模版内容如下：

# Compiled class file
*.class
    
# Log file
*.log
    
# BlueJ files
*.ctxt
    
# Mobile Tools for Java (J2ME)
.mtj.tmp/
    
# Package Files #
*.jar
*.war
*.nar
*.ear
*.zip
*.tar.gz
*.rar
    
# virtual machine crash logs, see 
http://www.java.com/en/download/help/error_hotspot.xml
hs_err_pid*
.classpath
.project
.settings
target
.idea
*.iml

2.在.gitconfig 文件中引用忽略配置文件（此文件在 Windows 的家目录中）

[user]
	name = Layne
	email = Layne@atguigu.com
[core]
	excludesfile = C:/Users/asus/git.ignore
	注意：这里要使用“正斜线（/）”，不要使用“反斜线（\）”

定位 Git 程序

初始化本地库

选择要创建 Git 本地仓库的工程。

添加到暂存区

右键点击项目选择 Git -> Add 将项目添加到暂存区

提交到本地库

切换版本

创建分支

选择 Git，在 Repository 里面，点击 Branches 按钮

在弹出的 Git Branches 框里，点击 New Branch 按钮

填写分支名称，创建 hot-fix 分支

然后再 IDEA 的右下角看到 hot-fix，说明分支创建成功，并且当前已经切换成 hot-fix 分支

合并分支

在 IDEA 窗口的右下角，将 hot-fix 分支合并到当前 master 分支

如果代码没有冲突，分支直接合并成功，分支合并成功以后，代码自动提交，无需手动提交本地库

解决冲突

如图所示，如果 master 分支和 hot-fix 分支都修改了代码，在合并分支的时候就会发生冲突

我们现在站在 master 分支上合并 hot-fix 分支，就会发生代码冲突。

点击 Conflicts 框里的 Merge 按钮，进行手动合并代码。

手动合并完代码以后，点击右下角的 Apply 按钮

代码冲突解决，自动提交本地库