一、Git 安装

1、各版本安装

网站：https://git-scm.com/

2、查看是否已经安装了 Git，CentOS 默认预装。

git --version
git version 1.8.3.1

3、使用前配置

• 由于 Git 是分布式的版本控制系统，每个人都必须有自己的名字已经邮箱，这里我们设置一下

git config --global user.email "xxxxx@qq.com"
git config --global user.name "zhaojishun"

• 查看设置过的用户名与邮箱

git config --list

像这样就是已经是安装了 Git，关于安装不做过多介绍

二、仓库

1、初始化本地仓库

• 仓库 repository本质上就是一个项目，一个目录，这里我们使用/home/git 这个目录，使用 git init [目录名]命令创建仓库 , 如果加上目录名git会自动创建目录并初始化仓库

git init

Initialized empty Git repository in /home/git/.git/

初始化成功，自动在文件夹下创建了一个.git 文件，这个是版本控制的文件，不要乱改。

2、克隆仓库

• 使用 git clone 远程仓库连接 [名称]命令从远程仓库克隆到本地仓库，命令中加上目录会自动重命名仓库名。

git clone https://github.com/zhaojishun/threefloor.git

3、关联远程仓库

git remote add origin https://github.com/zhaojishun/duanlian.git

三、基本用法

• 查看仓库当前状态

git status

• 将所有文件添加到暂存区

git add .

• 将暂存区提交到仓库，-m 是本次提交的说明，可以从提交记录中查看到

git commit -m "更改了xxx"

• 图示版本记录日志

git log --all --graph

• 显示简介日志

git log --pretty=oneline

• 显示每次提交命令的记录

git reflog

• 查看修改的内容

git diff

• 回退到上一节点

git reset --hard HEAD^

• 回退到指定历史节点

git reset --hard xxx

• 创建并切换分支

git checkout -b 分支名

• fork主仓库后更新主仓库代码到自己仓库

git remote add upstreamName https://github.com/hlx-xx/hlx-serve.git

git pull upstreamName BranchName

git push

四、三种状态

五、tag标签

分支很容易被人为移动，并且当有新的提交时，它也会移动。分支很容易被改变，大部分分支还只是临时的，并且还一直在变。

tag标签可以永远指向某个提交记录的标识，比如软件发布新的大版本，或者是修正一些重要的 Bug 或是增加了某些新特性

• 添加tag,不添加commitid就是在当前节点添加tag

git tag -a 标签名 -m "描述" [commit ID]

• 查看tag

git tag

• 查看标签的详细信息

git tag show 标签名

• 删除标签

git tag -d 标签名

• 推送标签到远程

git push origin 标签名

• 回退到某个标签

git checkout 标签名

六、分支 branch

• 在当前提交上创建分支

git branch 分支名

• 在指定节点上创建分支

git branch 分支名 [commitID]|[HEAD]|[branch]

• 切换分支

git checkout 分支名

• 创建并切换分支

git checkout -b 分支名

• 查看分支

git branch

• 回到主分支

git checkout master

• 把指定的分支合并到当前分支上

git merge 分支名

• 推送分支 [别名 分支名]

git push origin dev

• 查看远程分支

git branch -r

七、远程基本用法

• 查看所有远程地址别名

git remote -v

• 为远程仓库起别名

git remote add remoteName https://github.com/xx/xxx.git

• 推送本地分支上的内容到远程

git push remoteName branchName

• 克隆远程仓库内容

git clone https://github.com/xx/xxx.git

• 将指定的远程分支合并到当前分支

git pull remoteName remoteBranchName

八、本地仓库操作-高级

rebase

第二种合并分支的方法是 git rebase。Rebase 实际上就是取出一系列的提交记录，“复制”它们，然后在另外一个地方逐个的放下去。

Rebase 的优势就是可以创造更线性的提交历史，这听上去有些难以理解。如果只允许使用 Rebase 的话，代码库的提交历史将会变得异常清晰。

git rebase bugFix side

将side分支rebase 到bug fix 上

git checkout another
git rebase side

将当前分支rebase 到side分支上

git rebase another main

将main分支rebase到another上 ，main色块被挡住了。

这样的提交记录就是一条直线，非常清晰

分离 HEAD

我们首先看一下 “HEAD”。 HEAD 是一个对当前检出记录的符号引用 —— 也就是指向你正在其基础上进行工作的提交记录。

HEAD 总是指向当前分支上最近一次提交记录。大多数修改提交树的 Git 命令都是从改变 HEAD 的指向开始的。

HEAD 通常情况下是指向分支名的（如 bugFix）。在你提交时，改变了 bugFix 的状态，随着提交向前移动，这一变化通过 HEAD 变得可见。

git checkout commitID

修改前 HEAD -> main -> commitID

修改后 HEAD -> commitID

当你想要基于某个提交进行一些实验或者测试，可以直接检出这个提交，立马在上面开始实验/测试工作，如果结果满意，就保留，如果结果不满意，就丢弃

相对引用^

• 使用 ^ 向上移动 1 个提交记录 使用^2可以选择另一个父提交
• 使用 ~<num> 向上移动多个提交记录，如 ~3

git checkout main^

也可以连用

git checkout main~3^2~

也可以将 HEAD 作为相对引用的参照。下面咱们就用 HEAD 在提交树中向上移动几次。

git checkout HEAD^

用 ~<num> 一次后退四步

git checkout HEAD~4

强制修改分支位置

git branch -f main HEAD~3

git branch -f main [HEAD~3]|[commitID]|[branchName]

上面的命令会将 main 分支强制指向 HEAD 的第 3 级父提交。

撤销变更

主要有两种方法用来撤销变更 —— 一是 git reset，还有就是 git revert。接下来咱们逐个进行讲解。

reset

git reset 通过把分支记录回退几个提交记录来实现撤销改动。你可以将这想象成“改写历史”。git reset 向上移动分支，原来指向的提交记录就跟从来没有提交过一样。

git reset HEAD~1

Git 把 main 分支移回到 C1；现在我们的本地代码库根本就不知道有 C2 这个提交了。

在reset后， C2 所做的变更还在，但是处于未加入暂存区状态。

Revert

虽然在你的本地分支中使用 git reset 很方便，但是这种“改写历史”的方法对大家一起使用的远程分支是无效的！

为了撤销更改并分享给别人，我们需要使用 git revert。

git revert HEAD

奇怪！在我们要撤销的提交记录后面居然多了一个新提交！这是因为新提交记录 C2' 引入了更改 —— 这些更改刚好是用来撤销 C2 这个提交的。也就是说 C2' 的状态与 C1 是相同的。

revert 之后就可以把你的更改推送到远程仓库与别人分享啦。

git commit --amend

有时你提交过代码之后，发现一个地方改错了，你下次提交时不想保留上一次的记录；或者你上一次的commit message的描述有误，这时候你可以使用接下来的这个命令：git commit --amend。

整理提交记录 cherry-pick

如果你想将一些提交复制到当前所在的位置（HEAD）下面的话， Cherry-pick 是最直接的方式了。我个人非常喜欢 cherry-pick，因为它特别简单。

git cherry-pick <提交号>

git cherry-pick C2 C4

我们只需要提交记录 C2 和 C4，所以 Git 就将被它们抓过来放到当前分支下了。 就是这么简单!

交互式rebase -i

当你知道你所需要的提交记录（并且还知道这些提交记录的哈希值）时, 用 cherry-pick 再好不过了 —— 没有比这更简单的方式了。

但是如果你不清楚你想要的提交记录的哈希值呢? 幸好 Git 帮你想到了这一点, 我们可以利用交互式的 rebase —— 如果你想从一系列的提交记录中找到想要的记录, 这就是最好的方法了

交互式 rebase 指的是使用带参数 --interactive 的 rebase 命令, 简写为 -i

如果你在命令后增加了这个选项, Git 会打开一个 UI 界面并列出将要被复制到目标分支的备选提交记录，它还会显示每个提交记录的哈希值和提交说明，提交说明有助于你理解这个提交进行了哪些更改。

git rebase -i HEAD~4

假如这是我们需要的提交记录顺序

C0 <-- C1 <-- C5 <-- C2 <-- C4 <-- C3《--main

只取一个提交记录

来看一个在开发中经常会遇到的情况：我正在解决某个特别棘手的 Bug，为了便于调试而在代码中添加了一些调试命令并向控制台打印了一些信息。

这些调试和打印语句都在它们各自的提交记录里。最后我终于找到了造成这个 Bug 的根本原因，解决掉以后觉得沾沾自喜！

最后就差把 bugFix 分支里的工作合并回 main 分支了。你可以选择通过 fast-forward 快速合并到 main 分支上，但这样的话 main 分支就会包含我这些调试语句了。你肯定不想这样，应该还有更好的方式……

实际我们只要让 Git 复制解决问题的那一个提交记录就可以了。跟之前我们在“整理提交记录”中学到的一样，我们可以使用

• git rebase -i
• git cherry-pick

来达到目的。

九、提交的技巧

1、修改之前的提交 rebase法

接下来这种情况也是很常见的：你之前在 newImage 分支上进行了一次提交，然后又基于它创建了 caption 分支，然后又提交了一次。

此时你想对某个以前的提交记录进行一些小小的调整。比如设计师想修改一下 newImage 中图片的分辨率，尽管那个提交记录并不是最新的了。

我们可以通过下面的方法来克服困难：

• 先用 git rebase -i 将提交重新排序，然后把我们想要修改的提交记录挪到最前
• 然后用 git commit --amend 来进行一些小修改
• 接着再用 git rebase -i 来将他们调回原来的顺序
• 最后我们把 main 移到修改的最前端（用你自己喜欢的方法），就大功告成啦！

当然完成这个任务的方法不止上面提到的一种（我知道你在看 cherry-pick 啦），之后我们会多点关注这些技巧啦，但现在暂时只专注上面这种方法。 最后有必要说明一下目标状态中的那几个' —— 我们把这个提交移动了两次，每移动一次会产生一个 '；而 C2 上多出来的那个是我们在使用了 amend 参数提交时产生的，所以最终结果就是这样了

我们可以使用 rebase -i 对提交记录进行重新排序。只要把我们想要的提交记录挪到最前端，我们就可以很轻松的用 --amend 修改它，然后把它们重新排成我们想要的顺序。

但这样做就唯一的问题就是要进行两次排序，而这有可能造成由 rebase 而导致的冲突。下面还是看看 git cherry-pick 是怎么做的吧。

2、cherry-pick法

要在心里牢记 cherry-pick 可以将提交树上任何地方的提交记录取过来追加到 HEAD 上（只要不是 HEAD 上游的提交就没问题）。

git cherry-pick c2

十、远程仓库操作

远程分支

远程分支有一个命名规范 —— 它们的格式是:

• <remote name>/<branch name>

如果你看到一个名为 o/main 的分支，那么这个分支就叫 main，远程仓库的名称就是 o。

使用真正的 Git 时, 你的远程仓库默认为 origin

远程分支有一个特别的属性，在你检出时自动进入分离 HEAD 状态。Git 这么做是出于不能直接在这些分支上进行操作的原因, 你必须在别的地方完成你的工作, （更新了远程分支之后）再用远程分享你的工作成果。

git checkout o/main
git commit

fetch

git fetch 完成了仅有的但是很重要的两步:

• 从远程仓库下载本地仓库中缺失的提交记录
• 更新本地仓库远程分支指针(如 o/main)

git fetch 实际上将本地仓库中的远程分支更新成了远程仓库相应分支最新的状态。

如果你还记得上一节课程中我们说过的，远程分支反映了远程仓库在你最后一次与它通信时的状态，git fetch 就是你与远程仓库通信的方式了！希望我说的够明白了，你已经了解 git fetch 与远程分支之间的关系了吧。

git fetch 通常通过互联网（使用 http:// 或 git:// 协议) 与远程仓库通信

git fetch 不会做的事

git fetch 并不会改变你本地仓库的状态。它不会更新你的 main 分支，也不会修改你磁盘上的文件。

理解这一点很重要，因为许多开发人员误以为执行了 git fetch 以后，他们本地仓库就与远程仓库同步了。它可能已经将进行这一操作所需的所有数据都下载了下来，但是并没有修改你本地的文件。我们在后面的课程中将会讲解能完成该操作的命令 :D

所以, 你可以将 git fetch 的理解为单纯的下载操作。

pull

既然我们已经知道了如何用 git fetch 获取远程的数据, 现在我们学习如何将这些变化更新到我们的工作当中。

其实有很多方法的 —— 当远程分支中有新的提交时，你可以像合并本地分支那样来合并远程分支。也就是说就是你可以执行以下命令:

• git cherry-pick o/main
• git rebase o/main
• git merge o/main
• 等等

实际上，由于先抓取更新再合并到本地分支这个流程很常用，因此 Git 提供了一个专门的命令来完成这两个操作。它就是我们要讲的 git pull。git pull 就是 git fetch 和 git merge 的缩写！

push

如何与大家分享我的成果呢？

嗯，上传自己分享内容与下载他人的分享刚好相反，那与 git pull 相反的命令是什么呢？git push！

git push 负责将你的变更上传到指定的远程仓库，并在远程仓库上合并你的新提交记录。一旦 git push 完成, 你的朋友们就可以从这个远程仓库下载你分享的成果了！

你可以将 git push 想象成发布你成果的命令。它有许多应用技巧，稍后我们会了解到，但是咱们还是先从基础的开始吧……

注意 —— git push 不带任何参数时的行为与 Git 的一个名为 push.default 的配置有关。它的默认值取决于你正使用的 Git 的版本，但是在教程中我们使用的是 upstream。 这没什么太大的影响，但是在你的项目中进行推送之前，最好检查一下这个配置。

远程仓库接收了 C2，远程仓库中的 main 分支也被更新到指向 C2 了，我们的远程分支 (o/main) 也同样被更新了。所有的分支都同步了！

旧的提交历史

假设你周一克隆了一个仓库，然后开始研发某个新功能。到周五时，你新功能开发测试完毕，可以发布了。但是 —— 天啊！你的同事这周写了一堆代码，还改了许多你的功能中使用的 API，这些变动会导致你新开发的功能变得不可用。但是他们已经将那些提交推送到远程仓库了，因此你的工作就变成了基于项目旧版的代码，与远程仓库最新的代码不匹配了。

这种情况下, git push 就不知道该如何操作了。如果你执行 git push，Git 应该让远程仓库回到星期一那天的状态吗？还是直接在新代码的基础上添加你的代码，亦或由于你的提交已经过时而直接忽略你的提交？

因为这情况（历史偏离）有许多的不确定性，Git 是不会允许你 push 变更的。实际上它会强制你先合并远程最新的代码，然后才能分享你的工作。

如果 git push则什么都没有变，因为命令失败了！git push 失败是因为你最新提交的 C3 基于远程分支中的 C1。而远程仓库中该分支已经更新到 C2 了，所以 Git 拒绝了你的推送请求。

我们可以用 git fetch 更新本地仓库中的远程分支，然后用 rebase 将我们的工作移动到最新的提交记录下，最后再用 git push 推送到远程仓库。

我们用 git fetch 更新了本地仓库中的远程分支，然后合并了新变更到我们的本地分支（为了包含远程仓库的变更），最后我们用 git push 把工作推送到远程仓库

但是要敲那么多命令，有没有更简单一点的？

当然 —— 前面已经介绍过 git pull 就是 fetch 和 merge 的简写，类似的 git pull --rebase 就是 fetch 和 rebase 的简写！

让我们看看简写命令是如何工作的。

常规的

git pull;
git push

十一、远程仓库操作-高级

推送主分支

git pull --rebase;
git push

将左侧的分支提交为右侧的状态

$ git checkout main
$ git pull --rebase
$ git checkout side1
$ git rebase main side1
$ git rebase side1 side2
$ git rebase side2 side3
$ git rebase side3 main
$ git push

为什么不用 merge 呢?

为了 push 新变更到远程仓库，你要做的就是包含远程仓库中最新变更。意思就是只要你的本地分支包含了远程分支（如 o/main）中的最新变更就可以了，至于具体是用 rebase 还是 merge，并没有限制。

那么既然没有规定限制，为何前面几节都在着重于 rebase 呢？为什么在操作远程分支时不喜欢用 merge 呢？

在开发社区里，有许多关于 merge 与 rebase 的讨论。以下是关于 rebase 的优缺点：

优点:

• Rebase 使你的提交树变得很干净, 所有的提交都在一条线上

缺点:

• Rebase 修改了提交树的历史

比如, 提交 C1 可以被 rebase 到 C3 之后。这看起来 C1 中的工作是在 C3 之后进行的，但实际上是在 C3 之前。

一些开发人员喜欢保留提交历史，因此更偏爱 merge。而其他人（比如我自己）可能更喜欢干净的提交树，于是偏爱 rebase。仁者见仁，智者见智。 :D

远程跟踪分支

在前几节课程中有件事儿挺神奇的，Git 好像知道 main 与 o/main 是相关的。当然这些分支的名字是相似的，可能会让你觉得是依此将远程分支 main 和本地的 main 分支进行了关联。这种关联在以下两种情况下可以清楚地得到展示：

• pull 操作时, 提交记录会被先下载到 o/main 上，之后再合并到本地的 main 分支。隐含的合并目标由这个关联确定的。
• push 操作时, 我们把工作从 main 推到远程仓库中的 main 分支(同时会更新远程分支 o/main) 。这个推送的目的地也是由这种关联确定的！

直接了当地讲，main 和 o/main 的关联关系就是由分支的“remote tracking”属性决定的。main 被设定为跟踪 o/main —— 这意味着为 main 分支指定了推送的目的地以及拉取后合并的目标。

你可能想知道 main 分支上这个属性是怎么被设定的，你并没有用任何命令指定过这个属性呀！好吧, 当你克隆仓库的时候, Git 就自动帮你把这个属性设置好了。

当你克隆时, Git 会为远程仓库中的每个分支在本地仓库中创建一个远程分支（比如 o/main）。然后再创建一个跟踪远程仓库中活动分支的本地分支，默认情况下这个本地分支会被命名为 main。

克隆完成后，你会得到一个本地分支（如果没有这个本地分支的话，你的目录就是“空白”的），但是可以查看远程仓库中所有的分支（如果你好奇心很强的话）。这样做对于本地仓库和远程仓库来说，都是最佳选择。

这也解释了为什么会在克隆的时候会看到下面的输出：

local branch "main" set to track remote branch "o/main"

我能自己指定这个属性吗？

当然可以啦！你可以让任意分支跟踪 o/main, 然后该分支会像 main 分支一样得到隐含的 push 目的地以及 merge 的目标。 这意味着你可以在分支 totallyNotMain 上执行 git push，将工作推送到远程仓库的 main 分支上。

有两种方法设置这个属性，第一种就是通过远程分支检出一个新的分支，执行:

git checkout -b totallyNotMain o/main

就可以创建一个名为 totallyNotMain 的分支，它跟踪远程分支 o/main。

git checkout -b foo o/main;
git pull

正如你所看到的, 我们使用了隐含的目标 o/main 来更新 foo 分支。需要注意的是 main 并未被更新！

git push 同样适用

第二种方法

另一种设置远程追踪分支的方法就是使用：git branch -u 命令，执行：

git branch -u o/main foo

这样 foo 就会跟踪 o/main 了。如果当前就在 foo 分支上, 还可以省略 foo：

git branch -u o/main

git branch -u o/main;
git commit;
git push

.

push的参数

首先来看 git push。 Git 是通过当前检出分支的属性来确定远程仓库以及要 push 的目的地的。这是未指定参数时的行为，我们可以为 push 指定参数，语法是：

git push <remote> <place>

先看看例子, 这个命令是: git push origin main

把这个命令翻译过来就是：

切到本地仓库中的“main”分支，获取所有的提交，再到远程仓库“origin”中找到“main”分支，将远程仓库中没有的提交记录都添加上去，搞定之后告诉我。

我们通过“place”参数来告诉 Git 提交记录来自于 main, 要推送到远程仓库中的 main。它实际就是要同步的两个仓库的位置。

需要注意的是，因为我们通过指定参数告诉了 Git 所有它需要的信息, 所以它就忽略了我们所检出的分支的属性！

git checkout C0;
git push origin main

如果不指定参数会push失败，因为我们所检出的 HEAD（C0）没有跟踪任何分支。

<place>参数详解

还记得之前课程说的吧，当为 git push 指定 place 参数为 main 时，我们同时指定了提交记录的来源和去向。

你可能想问 —— 如果来源和去向分支的名称不同呢？比如你想把本地的 foo 分支推送到远程仓库中的 bar 分支。

要同时为源和目的地指定 <place> 的话，只需要用冒号 : 将二者连起来就可以了：

git push origin <source>:<destination>

这个参数实际的值是个 refspec，“refspec” 是一个自造的词，意思是 Git 能识别的位置（比如分支 foo 或者 HEAD~1）

git push origin foo^:main

这是个令人困惑的命令，但是它确实是可以运行的 —— Git 将 foo^ 解析为一个位置，上传所有未被包含到远程仓库里 main 分支中的提交记录。

如果你要推送到的目的分支不存在会怎么样呢？没问题！Git 会在远程仓库中根据你提供的名称帮你创建这个分支！

git push origin main:newBranch

空<source>

如果 push 空 它会删除远程仓库中的分支！

git push origin :foo

fetch 的参数

git fetch 的参数和 git push 极其相似。他们的概念是相同的，只是方向相反罢了（因为现在你是下载，而非上传）

<place> 参数

如果你像如下命令这样为 git fetch 设置 的话：

git fetch origin foo

Git 会到远程仓库的 foo 分支上，然后获取所有本地不存在的提交，放到本地的 o/foo 上。

来看个例子（还是前面的例子，只是命令不同了）

git fetch origin foo

“如果我们指定 <source>:<destination> 会发生什么呢？”

如果你觉得直接更新本地分支很爽，那你就用冒号分隔的 refspec 吧。不过，你不能在当前检出的分支上干这个事，但是其它分支是可以的。

这里有一点是需要注意的 —— source 现在指的是远程仓库中的位置，而 <destination> 才是要放置提交的本地仓库的位置。它与 git push 刚好相反，这是可以讲的通的，因为我们在往相反的方向传送数据。

理论上虽然行的通，但开发人员很少这么做。我在这里介绍它主要是为了从概念上说明 fetch 和 push 的相似性，只是方向相反罢了。

git fetch origin foo~1:bar

Git 将 foo~1 解析成一个 origin 仓库的位置，然后将那些提交记录下载到了本地的 bar 分支（一个本地分支）上。注意由于我们指定了目标分支，foo 和 o/foo 都没有被更新。

如果执行命令前目标分支不存在会怎样呢？跟 git push 一样，Git 会在 fetch 前自己创建立本地分支, 就像是 Git 在 push 时，如果远程仓库中不存在目标分支，会自己在建立一样。

git fetch origin foo~1:bar

如果 git fetch 没有参数，它会下载所有的提交记录到各个远程分支……

空<source>

如果 fetch 空 到本地，会在本地创建一个新分支。

git fetch origin :bar

pull 的参数

以下命令在 Git 中是等效的:

git pull origin foo 相当于：

git fetch origin foo; git merge o/foo

还有...

git pull origin bar~1:bugFix 相当于：

git fetch origin bar~1:bugFix; git merge bugFix

看到了? git pull 实际上就是 fetch + merge 的缩写, git pull 唯一关注的是提交最终合并到哪里（也就是为 git fetch 所提供的 destination 参数）

git pull orgin main:foo

它先在本地创建了一个叫 foo 的分支，从远程仓库中的 main 分支中下载提交记录，并合并到 foo，然后再 merge 到我们的当前检出的分支 bar 上。

IDEA 中文乱码问题解决

1. 将idea默认命令窗口改为gitbash
   
2. 在idea安装目录下找到idea.exe.vmoptions和idea64.exe.vmoptions文件，在文件的最后添加：

-Dfile.encoding=UTF-8

3. 在git安装目录下找到etc/bash.bashrc文件，在文件的最后添加：

export LANG="zh_CN.UTF-8"

export LC_ALL="zh_CN.UTF-8"

4. 在Terminal控制台输入：

set LESSCHARSET=utf-8

5. 退出控制台，重新进入即可。

git配置.gitignore失效如何处理

##设置排除的文件##
.idea/
log/
target/
*.iml

.gitignore只能忽略没有被跟踪的文件(就是没有被纳入版本管理的文件),如果已经被纳入版本管理是无法忽略的。

所谓纳入版本管理，就是在本地有个缓存区(cached)，所有在缓存区的文件都被版本管理了，每次你修改文件后，git会对比缓存区和当前的文件差异，从而决定哪些需要提交更新。

为了重新让修改的.gitignore生效，首先在本地清除缓存，然后重新将文件纳入版本管理，最后提交新.gitignore到远端。

在项目根目录下,指令如下：

git rm -r --cached . //清除缓存区，注意最后有个"."

git add . //重新纳入版本管理，注意最后有个"."

git commit -m 'update .gitignore' //提交新的忽略文件。

如果你用的是sourceTree，最后一步更新忽略文件可以在界面操作

github配置ssh

1. 生成ssh

git ssh-keygen -t rsa

期间不需要输入密码，之后就就会生成两个文件，分别为id_rsa和id_rsa.pub，即密钥id_rsa和公钥id_rsa.pub. 对于这两个文件，其都为隐藏文件，默认生成在以下目录：
Linux 系统：~/.ssh
Mac 系统：~/.ssh
Windows 系统：C:\Users\username.ssh
Windows 10 ThinkPad：C:\Users\think.ssh

密钥和公钥生成之后，我们要做的事情就是把公钥id_rsa.pub的内容添加到 GitHub，这样我们本地的密钥id_rsa和 GitHub 上的公钥id_rsa.pub才可以进行匹配，授权成功后，就可以向 GitHub 提交代码

参考

git小游戏https://learngitbranching.js.org/?demo=&locale=zh_CN

分离HEAD https://www.zsythink.net/archives/3412/

commit --amend https://zhuanlan.zhihu.com/p/100243017

fetch与pull https://www.cnblogs.com/runnerjack/p/9342362.html

show solution