目录
概要
作为初次学习使用Git版本控制器，体会git的概念与一些基础指令。
整体架构流程
首先我们需要明白几个概念"工作区"、"缓存区"、"本地仓库"、"远程仓库"。
本文全程以pycharm为例，说明如何在pycharm里搭建项目并与GitHub交互。
1.工作区：
顾名思义即项目本身的路径，每创建一个项目，该项目在pycharm里有属于自己的路径和folder，在这个项目里的任何文件均保存在该项目子目录下。
我们创建好项目后，在项目里调出终端即可查看当前项目的根路径，由于刚创建项目，并未新建任何文件，该路径下只有main.py。
此时我们创建了项目，但尚未为该项目创建本地git仓库，无法执行任何git命令，在确保安装好git之后(Mac用户可以使用Homebrew直接安装)，我们需要在该项目里执行git仓库初始化'git init'。
已为当前项目成功创建一个新的空git仓库。
目前项目和git仓库的事前准备已完成，接下来进入到git仓库命令执行部分。
2.缓存区：
属于git特有的一个区域，可以理解为一个中间区，当我们在工作区进行一些创建/修改文件的行为，git仓库能够识别到工作区的改动，但是这些改动一开始是没有给git仓库报备的，针对新创建的文件，或者新创建并进行修改的文件，对于git仓库来说，全部都是未追踪（untracked）状态，此时使用' git status '可以查看当前项目里git仓库的状态以及git对项目文件改动的识别：
此时我在项目里新建一个f1.txt，使用git 查看后识别到新增的f1文件和该项目的主文件main.py，这两个文件均没有向git报备，git对它们是未追踪的状态。
当我们尝试将文件向git报备时，我们需要使用' git add <file_name> ' 将目标报备文件添加至git缓存区，如果想批量添加可使用' git add <file_name1> <file_name2> ',或者是' git add . '将当前项目里所有文件添加至缓存区。
此时已对这俩文件进行报备，成功加入缓存区，等待提交。
接下来让我们对f1进行编辑，添加部分内容进去，查看git对该改变的识别：
这里有两点需要注意：首先git已经在缓存区报备了f1和main文件，作为初始状态，这时我们还没修改f1，这意味着此时工作区和缓存区f1文件的版本/内容是一致的，git识别到版本一致。
当我们对f1做出修改后，在没有向git仓库报备的情况下，工作区和缓存区的f1文件版本/内容不再一致，此时工作区的f1版本/内容领先于git缓存区的f1版本，git识别到这一差异，会告诉我们当前项目发生了以下更改(change)但并未向git仓库报备，即上述的针对f1文件的修改。
这时git识别的一项核心动作，亦或者说这是我们在日常写代码最常见的版本更新行为。
想象一下针对某个模块的代码修改，首先将该文件在git里报备（加入至缓存区），在工作区里我们可能会经历多次修改该文件，以达到最终满足的版本，这个修改的过程你不需要频繁的使用' git add <file_name> '将该文件的每一个修改版本加入到缓存区 以求平衡工作区和缓存区该文件版本/内容的同步，你仅需要将最终版本加入至缓存区即可。
3.提交至git本地仓库：
缓存区已经解释完毕，你会注意到，我们添加至缓存区后，git告诉我们这些内容'待提交'即需要commit，即git仓库等待你对缓存区的进一步操作。
仍然是刚刚的场景，当我们对文件加入缓存区后进行多次修改，终于满意并将该文件最新版本同步至缓存区，此时我们可以正式将该文件提交至git本地仓库 使用' git commit -m '提交说明'
此时我们将编辑好的f1与main一同从缓存区提交至git本地仓库，并附上提交说明'create file and edit first time for f1 save original version of main' 即'首次创建与编辑f1 保存原始main文件'，用作git仓库提交记录。提交完毕后再次查看当前git的缓存区，发现没有任何'待提交'文件。
注意到提交说明里出现' 2 files changed, 21 insertions(+) '，前者很好理解，我们提交了两个文件，后者' 21个新增行 '是因为f1文件里有4行内容，main文件里有17行内容，一起是新增了21行内容，此时如果我们进一步增加f1文件里的内容再提交，则会再出现' xx insertions (+) '的说明，如果我们的某次编辑是删除文件某内容，则会出现' xx deletion (-) '的说明，告诉我们在本次提交里哪个文件有改动 改动如何（新增xx行 or 删除xx行）。
这里我暨上次提交后再次对f1文件进行修改，本次修改我删除了一行内容，保存后依旧先将最新f1文件添加至缓存区，然后提交并说明' edit second time for f1 delete 1 row '，git仓库更新提交行为：'本次提交1个文件发生改变 删除1行'。
针对提交记录的查看和其他命令
除开使用的最频繁的git命令，我们还需要知道git的一些设定信息，使用'git config --list'查看git配置参数：
可以看到git的配置有非常多的参数，最后直接skipping全部显示，我们需要常用以及自己手动修改的参数就是用户名和用户邮箱，用户名可以自己设定，用户邮箱需要和咱们git远程仓库的注册邮箱一致，本文会以GitHub为例，所以需要和注册GitHub的邮箱保持一致，否则git本地仓库无法与远程仓库对接。
bash
# 配置用户名 用户邮箱
git config --global user.email <email>
git config --global user.name <name>
# 清除配置用户名 用户邮箱
git config --global --unset-all user.email
git config --global --unset-all user.name
# 初始化默认分支设为 main
git config --global init.defaultBranch main
# 配置代理ip
git config --global http.proxy <ip>
git config --global https.proxy <ip>
# 查看所有配置参数 (q退出)
git config --list
# 查看日志 提交记录 (q退出)
git log' git log '命令能够查看我们对本项目所有的提交记录，包括提交hash id 提交时间 以及提交备注，是从最近一次提交往前现实，即5 -> 4 -> 3 -> 2 -> 1这样。
如果我们在修改文件过程中出错，又不小心将出错的版本加入到缓存区并提交至git仓库，并且在错误版本的基础上又进行了几次提交，我们该如何做来调整错误版本，甚至回溯至该版本之前，接下来将以一个新文件f2为例：
可以看到对f2文件，一共进行了三次操作，1.创建 2.第一次修改 增加1行内容 3.第二次修改 增加2行内容。每次操作均通过缓存区提交至git仓库，记录了相应的提交id。
那么此时我们发现第一次修改的内容不够全面 想撤回第一次修改，但是第二次修改的内容我们又很满意，此时我们可以使用以下几个命令：
bash
# 撤回某次提交 在现有提交记录上新增反响回溯提交
git revert <hash id> --no-edit
# 强制返回某次提交状态 抹除该提交后的所有提交记录和版本数据
git reset --hard <hash id>我们首先从' git revert ' 开始，该命令能新建一个反向提交，撤回某次提交的更改，例如我们想保留f2文件的第二次修改部分，又想重新更新第一次修改部分，那我们使用revert指向第一次修改部分的提交hash id，做一个反向提交撤回原本的第一次修改。--no-edit 意味着本次revert无需添加说明。
很遗憾，git告诉我们无法跳过第二次修改，直接撤回第一次的修改。
这是因为f2是txt文件，第一次修改的内容如果撤回，会影响第二次修改内容的上下文结构，git不允许这样做！，那么我们只能使用' git reset '强制回到第一次修改版本之前，即创建f2文件时的提交版本，使用reset会无视冲突，因为reset本质是删除指定提交记录后的所有提交：
一手reset直接让我们回到创建f2文件的提交阶段，后续的第一次修改、第二次修改提交记录已被删除。
' git reset --hard ' 非常危险，因为它会让我们工作区的数据也被删除，如果我们仅希望在git仓库里强力退回某个版本，可以考虑:
bash
假设最新版本v5 -> 回退至v3
# 默认mixed reset 回退版本
git reset <hash id>
# 效果：
# 1. git仓库log 头指向指定提交id v3
# 2. 缓存区清空 仅保留v3的版本
# 3. 但工作区的修改 v5版本保留！
# 4. 运行 git status 显示"未暂存的修改" 当前v5修改未和缓存区同步
# soft reset 软回退版本
git reset --soft <hash id>
# 效果：
# 1. git仓库log 头指向指定提交id v3
# 2. 暂存区v5版本保留（之前的v5版本变成已暂存状态）
# 3. 工作区也保留v5
# 4. 运行 git status 显示"要提交的变更" 当前v5修改已加入缓存区 但未提交本地仓库与远程GitHub仓库连接
待更新..