git使用教程

知识体系相当于骨架，有了这个架构，接触到新知识【学习】，就知道应该放在哪个位置。查/调用它就知道在哪儿找了。
但是如果没有这个架构，新知识就没有存储的地方，我们所学习的内容就会变得零散【找都可能找不到】。

1.git 简介

1.0 先玩起来git-来者必看

来者必看！！！
如果你只想初窥门径，想知道Git是怎么干活的，不想被文中其他大量信息干扰，请直接跳到7.1案例演示一关，通过完整案例感觉一下Git的工作流程。
把案例边看边做一遍，你会用案例涉及到的基本命令你也能拿Git干活了。
这篇博文可以当做你的手头参考手册。

1.0.1 关于git的几个好问题

（1）git push 的 -u 参数具体作用？
就是你第一次使用 git push -u origin master 之后，
第二次【下次，以后】可以直接使用 git pull 拉取代码，就不需要输入完整的命令 git pull origin master 来拉取代码了。
即 第二次 使用 git pull 等同于执行 git pull origin master。
然后第二次也可以用 git push推送代码而不用git push origin master。
即第二次 使用 git push 等同于执行 git push origin master。
stackoverflow参考链接

1.1 产生历史

git是目前世界上最先进的分布式版本控制系统。
Linus在1991年创建了开源的Linux,从此，Linux系统不断发展，已经成为最大的服务器系统软件了。
Linus虽然创建了Linux,但Linux的壮大是靠全世界热心的志愿者参与的，这么多人在世界各地为Linux编写代码，那Linux的代码是如何管理的呢？
事实是，在2002年以前，世界各地的志愿者把源代码文件通过diff的方式发给Linus,然后由Linus本人通过手工方式合并代码！
你也许会想，为什么Linus不把Linux代码放到版本控制系统里呢？
不是有CVS、SVN这些免费的版本控制系统吗？
因为Linus坚定地反对CVS和SVN,这些集中式的版本控制系统不但速度慢，而且必须联网才能使用。
有一些商用的版本控制系统，虽然比CVS、SVN好用，但那是付费的，和Linux的开源精神不符。

不过，到了2002年，Linux系统已经发展了十年了，代码库之大让Linus很难继续通过手工方式管理了，社区的弟兄们也对这种方式表达了强烈不满，于是**Linus选择了一个商业的版本控制系统BitKeeper,BitKeeper的东家BitMover公司出于人道主义精神，授权Linux社区免费使用这个版本控制系统。
**安定团结的大好局面在2005年就被打破了，原因是Linux社区牛人聚集，不免沾染了一些梁山好汉的江湖习气。

开发Samba的Andrew试图破解BitKeeper的协议（这么干的其实也不只他一个）,被BitMover公司发现了（监控工作做得不错！)，于是BitMover公司怒了，要收回Linux社区的免费使用权。Linus可以向BitMover公司道个歉，保证以后会严格管教弟兄们，嗯，这是不可能的。

实际情况是这样的：
Linus花了两周时间自己用C写了一个分布式版本控制系统，这就是Git！一个月之内，Linux系统的源码已经由Git管理了！

牛是怎么定义的呢？大家可以体会一下。
Git迅速成为最流行的分布式版本控制系统，尤其是2008年，GitHub网站上线了，它为开源项目免费提供Git存储，无数开源项目开始迁移至GitHub，包括jQuery，PHP，Ruby等等。

历史就是这么偶然，如果不是当年BitMover公司威胁Linux社区，可能现在我们就没有免费而超级好用的Git了。

1.2 git两大特点

版本控制：可以解决多人同时开发的代码问题，也可以解决找回历史代码的问题。

分布式：Git是分布式版本控制系统，同一个Git仓库，可以分布到不同的机器上。首先找一台电脑充当服务器的角色，每天24小时开机，其他每个人都从这个服务器仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。可以自已搭建这台服务器，也可以使用GitHub网站。

2.安装配置

Windows安装链接
一路点Next即可，安装位置就放在C盘。
装好git后

在终端里面敲入git,

出现这样的画面就表示你的git装好了，此处应该有掌声~~

2.1 如何在Windows的cmd 中使用linux的命令

cmd的命令功能肯定没有linux的命令功能好用，这点毋庸置疑。
现在装好了Git，就可以在Windows的cmd中使用linux命令了。
记住关键词：环境变量 Git命令
怎么玩？如下2步操作：
假如你按照上述步骤将Git装在C盘，那么做如下操作：
操作1：找Git命令的【.exe文件】。如图：

操作2：添加到环境变量，就可以在cmd里使用linux命令了。如图：

最终效果：

PyCharm也可以使用linux命令。【环境变量–全局—使用】

备注：你可能需要关闭之前打开的cmd窗口/PyCharm窗口，重新打开新的cmd窗口//PyCharm窗口，使用命令才可能生效。
恭喜你已经掌握在Windows环境下使用linux命令了_{【效率会提高一点点}】

3.创建一个版本库

(1)新建一个目录git_test,在git_test目录下创建一个版本库，命令如下：


接着初始化仓库

说明：可以看到在git_test目录下创建了一个.git隐藏目录，这就是版本库目录。

4.版本的创建与回退

4.1 使用

(1)在git_test目录下创建一个文件code.txt,编辑内容如下：

(2)使用如下两条命令可以创建一个版本：
git add code.txt
git commit -m “版本1”

(3)使用如下命令可以查看版本记录：
git log

(4)继续编辑code.txt,在里面增加一行。

(5)使用如下命令再创建一个版本并查看版本记录：

(6)现在若想回到某一个版本，可以使用如下命令：

其中HEAD表示当前最新版本【请记死】，HEAD^表示当前版本的前一个版本，HEAD^^表示当前版本的前前个版本，也可以使用HEAD~1表示当前版本的前一个版本，HEAD~100表示当前版本的前100版本。


因为版本1的内容是1行：
this is the first line

因为版本2的内容是2行：
this is the first line
this is the second line

因为
$ git reset --hard HEAD^ HEAD is now at 51d36c7 版本1
使指针HEAD指向（倒退）到版本1，
因此打印的内容就是版本1的内容，即this is the first line

(7)假如我们现在又想回到版本2,这个时候怎么办？可以使用如下命令：
git reset --hard 版本号

（8）在终端执行如下命令：

版本2又回来了，内容也是原来的内容。

接着玩

退出终端，再重进：

这个重进终端的操作让我们看不到版本2的版本号，要回到版本2怎么办？
命令：git reflog来查看操作记录。

错误示例：
原因是按照当前版本1倒退的话，怎么也不会前进到版本2吧？逻辑错误。

正确实例：
要用到版本号。

查看版本2的内容：

不理解版本1，版本2有啥区别？
这个东西像游戏更新一样，版本2是在版本1的基础上添加新功能的，版本1内容不发生改变。例如王者荣耀版本更新，界面总会变化，但是英雄的属性（技能，名字）一般不会改变。

4.2 工作区和缓存区

4.2.1 工作区（WorkingDirectory)

工作区（WorkingDirectory) 电脑中的目录，比如我们的git_test,就是一个工作区。

4.2.2 版本库（Repository)

工作区有一个隐藏目录.git,这个不是工作区，而是git的版本库。git的版本库里存了很多东西，其中最重要的就是称为stage(或者叫index)的
暂存区，
还有git为我们自动创建的第一个分支master,以及指向master的一个指针叫HEAD。

因为我们创建git版本库时，git自动为我们创建了唯一一个master分 支，所以，现在，git commit就是往master分支上提交更改。
你可以简单理解为，需要提交的文件修改通通放到暂存区【计算机的缓存区】，然后，一次性提交暂存区的所有修改。

前面讲了我们把文件往版本库里添加的时候，是分两步执行的：
第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区
第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。

(1)下面在git test目录下再创建一个文件code2.txt,然后编辑内容如下：

(2)然后编辑code.txt,操作如下：


注意的是创建文件和编辑文件都是在工作区里完成。
（3）使用如下命令查看当前工作树的状态：
git status

翻译一下：

上面提示我们code.txt被修改，而code2.txt没有被跟踪。

(4)我们使用如下命令把code.txt和code2.txt加入到暂存区，然后再执行git status命令，结果如下：

注意：所有的 git add 命令是把所有提交的修改存放到暂存区。

(5)然后，执行git commit就可以一次性把暂存区的所有修改提交到分支并创建一个版本。

注意：指针HEAD永远指向当前版本。此时当前版本是版本3。

(6)一旦提交后，如果你又没有对工作区做任何修改，那么工作区就是“干净”的。执行如下命令可以发现：

现在我们的版本库变成了酱紫：

4.3 管理修改

git管理的文件的修改，它只会提交暂存区的修改来创建版本。
(1)编辑code.txt,并使用git add命令将其添加到暂存区中。

(2)继续编辑code.txt,并在其中添加一行。

(3)git commit创建一个版本，并使用git status查看，发现第二次修改code.txt内容之后，并没有将其添加的工作区，所以创建版本的时候并没有被提交。


注意：对于code.txt里的四行内容，每一个版本对应一行，例如版本1对应first line，以此类推。

4.4 撤销修改

(1)继续上面的操作，提示我们可使用git checkout – <文件>来丢弃工作区的改动。执行如下命令，发现工作区干净了，第二次的改动内容也没了。

(2)我们继续编辑code.txt,并在其中添加如下内容，并将其添加的暂存区。

(3)git同样告诉我们，用命令git reset HEAD file可以把暂存区的修改撤销掉，重新放回工作区。

(4)现在若想丢弃code.txt的修改，执行如下命令即可。

现在，如果你不但改错了东西，还从暂存区提交到了版本库，则需要进行版本回退。

小结：
场景1:当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用 命令git checkout – file
场景2:当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步：
第一步用命令git reset HEAD – file,就回到了场景1,
第二步按场景1操作。
场景3:已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节。
该需求你可以理解为：
如果想要删除远程仓库或本地的一个分支的最新的commit提交记录，那么可以使用版本回退、版本回滚 git reset
具体例子：
比如github最新的4条commit记录如下：

我要从github上删除以上4条commit记录中的最新的commit记录即commit4怎么做？
目标是删除最新的commit记录。即删除图片中commit4的记录
怎么做？参考代码如下：
在参考代码之前，先做最坏的打算：
万一按照参考代码操作代码消失了怎么办？
因此在参考之前先git clone命令，总之目标就是先获取完整代码，做个备份。

上面的准备工作做完之后，再参考代码：

给出用到的命令：

# 获取最近4条提交记录，查看版本回滚、版本回退的4条commit_id信息
git log -n 4 --pretty=oneline
# 拉远程仓库的代码到本地
git pull
# 版本回退到 commit3
git reset commit3
# 对比之前的版本信息差异
git log
# 推到远程仓库就可以看到版本信息变化了——commit4消失了，删掉了
git push origin -f dev

如何避免上述问题或同类问题的发生？
有好的git flow习惯。就像有好的编码习惯一样。有按步骤顺序操作的思维习惯很重要。

4.5 对比文件的不同

对比工作区和某个版本中文件的不同：

(1)继续编辑文件code.txt,在其中添加一行内容。

(2)现在要对比工作区中code.txt和HEAD版本中code.txt的不同。使用如下命令：

(3)使用如下命令丢弃工作区的改动。

对比两个版本间文件的不同：
(1)现在要对比HEAD和HEAD ^版本中code.txt的不同，使用如下命令：

反过来

4.6 删除文件

(1)我们把目录中的code2.txt删除。

这个时候，git知道删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻提示哪些文件被删除了。

(2)现在你有两个选择，一种情况是确实要从版本库中删除该文件，那就用命令 gitrm删掉【永久删除，无法撤消】，并且 git commit:

另一种情况是删错了，可以直接使用git checkout – code2.txt,这样文件code2.txt又回来了。
注意：两种情况有区别：
当执行第一种情况时【永久删除，无法撤消】，再执行第二种情况，会报错：

加长版：

简短版：


小结：
命令rm 删除是永久删除，要恢复数据的话可以恢复/扫描硬盘；
命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。

5. 分支管理

5.1概念

分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学习Git的时候，另一个你正在另一个平行宇宙里努力学习SVN。
如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并了，结果，你既学会了git又学会了SVN!

分支在实际中有什么用呢？
假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

5.2 创建与合并分支

git把我们之前每次提交的版本串成一条时间线，这条时间线就是一个分支。截止到目前只有一条时间线，在git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master,master才是指向提交的，所以，HEAD指向的就是当前分支。

(1)一开始的时候，master分支是一条线，git用master指向最新的提交，再用HEAD指向master,就能确定当前分支，以及当前分支的提交点：

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。
(2)当我们创建新的分支，例如dev时，git新建了一个指针叫dev,指向master相同的提交，再把HEAD指向dev,就表示当前分支在dev上：

git创建一个分支很快，因为除了增加一个dev指针，改变HEAD的指向，工作区的文件都没有任何变化。

(3)不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

(4)假如我们在dev上的工作完成了，就可以把dev合并到master上。git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

git合并分支也很快，就改改指针，工作区内容也不变。
（5）合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

(1)执行如下命令可以查看当前有几个分支并且看到在哪个分支下工作。

(2)下面创建一个分支dev并切换到其上进行工作。


(3)下面我们修改code.txt内容，在里面添加一行，并进行提交。


(4)dev分支的工作完成，我们就可以切换回master分支：


查看code.txt,发现添加的内容没有了。因为那个提交是在dev分支上，而master分支此刻的提交点并没有变。【这里需要细细品味一下】

(5)现在，我们把dev分支的工作成果合并到master分支上：
git merge命令用于合并指定分支到当前分支。合并后，再查看code.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。

注意到上面的rast-forward信息，Git告诉我们，这次合并是“快进模式“，也就是直接把master指向dev的当前提交，所以合并速度非常快。

(6)合并完成后，就可以放心地删除dev分支了，删除后，查看branch,就只剩下master分支了。


小结：
查看分支：git branch
创建分支：git branch <name>
切换分支：git checkout <name>
创建+切换分支：git checkout -b <name>
合并某分支到当前分支：git merge <name>
删除分支：git branch -d <name>

5.3 解决冲突

合并分支往往也不是一帆风顺的。
(1)再创建一个新分支dev。

(2)修改code.txt内容，并进行提交。

(3)切换回master分支。

(4)在master的code.txt添加一行内容并进行提交。


这种情况下，git无法执行"快速合并"，只能试图把各自的修改合并起来，但这种合并就可能会有冲突。

(5)执行如下命令尝试将dev分支合并到master分支上来。

冲突原因：
现在，master分支和dev分支各自都分别有新的提交，并且编辑了同一个文件，变成了这样：

git告诉我们，code.txt文件存在冲突，必须手动解决冲突后再提交。

最重要的一步：

(6)git status也可以告诉我们冲突的文件：

(7)查看code.txt的内容。

(8)git用<<<<<<<<,========,>>>>>>>>标记不同分支的内容，我们修改如下后保存：

(9)再提交。

(10)现在，master分支和dev分支变成了下图所示：

(11)用带参数的git log也可以看到分支的合并情况：

(12)最后工作完成，可以删除dev分支：

5.4 分支管理策略

通常，合并分支时，如果可能，git会用fast forward模式，但是有些快速合并不能成功而且合并时没有冲突，这个时候git会帮我们在合并之后做一次新的提交，但这种模式下，删除分支后，会丢掉分支信息。【弹窗说明信息】

(1)创建切换到dev分支下。

(2)新建一个文件code3.txt,编辑内容如下，并提交一个commit。

(3)切换回master分支，编辑code.txt并进行一个提交。

(4)合并dev分支的内容到master分支。

(5)出现如下提示时，这是因为这次不能进行快速合并，所以git提示输入合并说明信息，输入之后合并内容之后git会自动创建一次新的提交。

按 :x保存并退出。

(6)使用分支命令查看分支信息。

(7)删除dev分支。

如果要强制禁用fast forward模式，git就会在merge时生成一个新的commit,这样，从分支历史上就可以看出分支信息。
(1)创建并切换到dev分支。

(2)修改code.txt内容，并提交一个commit。

(3)切换回master分支。

（4）准备合并dev分支，请注意–no-ff参数，表示禁用Fast forward:

因为本次合并要创建一个新的commit,所以加上-m参数，把commit描述写进去。

5.5 Bug分支

软件开发中，bug就像家常便饭一样，有了bug就需要修复，在git中，由于分支是如此的强大，所以，
每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

(1)当你接到一个修复一个代号001的bug的任务时，很自然地，你想创建一个分支bug-001来修复它，但是，等等，当前正在dev上进行的工作还没有提交：
建议先敲clear清屏。

并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug,怎么办？

(2)git还提供了一个stash功能，可以把当前工作现场“储藏“起来，等以后恢复现场后继续工作：【工作中可能会用到，在git pull之前先用这条命令。放入缓存是git stash，相对应的git stash pop从缓存中释放出来】

更多请参考：传送门
(3)首先确定要在哪个分支上修复bug,假定需要在master分支上修复，就从master创建临时分支：


(4)现在修复bug,这里假设把code.txt里的第9行删掉，然后提交。

(5)修复完成后，切换到master分支，并完成合并，最后删除bug-001分支。

(6)现在bug-001修复完成，是时候接着回到dev分支干活了！

(7)工作区是干净的，刚才的工作现场存到哪去了？用git stash list命令看看：【帮助我们列出保存的工作现场】

工作现场还在，git把stash内容存在某个地方了，需要恢复一下：

小结：
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug,修复后，再git stash pop,恢复工作现场。

6.使用github

6.1 创建仓库

(1)注册github账户



登录后，点击"New respository"

(2)在新页面中，输入项目的名称【如2020】，勾选’readme.md’,点击’Create repository’






这里完成。

6.2 添加ssh账户

(1)点击账户头像后的下拉三角，选择’settings’如果某台机器需要与github上的仓库交互，那么就要把这台机器的ssh公钥添加到这个github账户上。

(2)在git的命令行中，回到用户的主目录下，编辑文件.gitconfig,修改某台机器的git配置。
修改为注册github时的邮箱，填写用户名。





完美：

6.3 克隆项目

接着：

6.4 上传分支/推送代码

(1)项目克隆到本地之后，执行如下命令创建分支：

(2)创建一个views.py并提交一个版本：

(3)推送前github上文件列表如下图:

(4)推送前github上分支列表如下图:

(5)推送分支，就是把该分支上的所有本地提交推送到远程库，推送时要指定本地分支，这样，git就会把该分支推送到远程库对应的远程分支上：
git push origin 分支名称
例：
git push origin smart

（6）再次查看github分支：
接下来操作重新加载页面：



点击smart,再点击views.py,如图所示：

6.5 将本地分支跟踪服务器分支

 git branch --set-upstream-to=origin/远程分支名称 本地分支名称

例：

  git branch --set-upstream-to=origin/smart smart

我的社交网址：https://github.com/Keegan-y

6.6 从远程分支上拉取代码

git pull orgin 分支名称
例：
git pull orgin smart
使用上述命令会把远程分支smart上的代码下载并合并到本地所在分支。

7.工作使用git

不墨迹直接上代码：
知道如何生成SSH KEY
知道know_hosts文件路径在哪儿
loading…
项目经理/组长：
(1)项目经理/组长搭建项目的框架。
(2)搭建完项目框架之后，项目经理/组长把项目框架代码放到服务器。

你/小组成员：
(1)在自己的电脑上，生成ssh公钥，然后把公钥给项目经理/组长，项目经理/组长把它添加的服务器上面。
(2)项目经理/组长会给你（或其他组员）的项目代码的地址，你把代码下载【克隆】到自己的电脑上。
(3)创建本地的分支dev,在dev分支中进行每天的开发。
(4)每一个组员在开发完自己的代码之后，都需要将代码发布远程的dev分支上。

项目里一般会有两个分支，如：
main:用于保存发布的项目代码。【以前是master，现在推荐用main代替master命名，不过仍然可以用master命名主分支】
dev:用于保存开发过程中的代码。所有的组员开发完自己的代码提交到该分支上。
补充小技巧：
首先，整体认知一下工作中git常用的就这么几个命令：
步骤1.创建项目目录，如git_test【强烈建议返回到2.安装配置一节，学一学在windows中用mkdir git_test。工作中点来点去，文件夹一多就不爽了，学会在windows上用linux命令，工作效率谁用谁知道~】
步骤2.git init【如果你考皮github上别人的代码，必须将别人的.git文件删掉。步骤：进入项目目录，如git_test，cd git_test，ls -al，rm -rf .git】【工作中linux必会的，赶快回到2.安装配置一节，学一学在windows使用linux命令，这样就不用装linux环境了，简单胜于复杂~】
步骤3.git add .
步骤4.git commit -m “整体提交”
步骤5.git remote add origin/github URL
add 后面的名字可以是【origin/github】
URL是【你的github/gitlab仓库地址】
步骤6.git checkout -b dev
步骤7.git push origin/github dev
步骤8：权限控制允许了吗？
当然不止于这7步，这些步骤会在你的实践中不断升华，壮大~。
先把git玩起来再说，否则很容易从入门到放弃。先玩起来~
步骤操作如图所示：



可以看到，代码推到仓库了。
完整案例演示请参考7.1案例演示一关。

7.1 案例演示

说在前面：
如果是windows系统，你要在下载好的Git Bash里面执行下面用到的命令。如果你也想在cmd里面运行以下命令，请参考2.1 如何在Windows的cmd 中使用linux的命令 一关。
如果是mac 或 linux系统，可以直接执行以下命令。

如果你不熟悉git，可以对着案例边看边做。
好了，是时候跟它耍耍了~

步骤0：
安装好Git Bash软件后，进入Git Bash终端，在终端环境里设置用户名和邮箱。
命令如下：

# 设置用户名样例
git config --global user.name "zhangshan"
# 你可以这样改：把字符串里的zhangshan改成你自己设置的名字，比如wanger
git config --global user.name "wanger"

# 设置用户邮箱样例---跟GitHub关联的邮箱是一样的。
git config --global user.email zhangsan.me@qq.com 
# 你可以这样改：把zhangsan.me@qq.com改成你自己的邮箱，比如wanger.me@qq.com
git config --global user.email wanger.me@qq.com

# 查看用户名
git config user.name

# 查看邮箱
git config user.email

如果需要你设置用户名和邮箱，可以参考此步骤。
如果你已经设置过了【可用git config user.name和git config user.email】，
可以进入下一步骤。按顺序操作。

步骤1：
我们在本地创建一个新项目，并且进入项目目录：

mkdir git_tests && cd git_tests

步骤2：
初始化git仓库：

git init

当然，可以把步骤1和步骤2两步并为一步来做：

mkdir git_tests && cd git_tests && git init

步骤3：
新建README.md文件：

# 创建README.md文件并写入内容hello
 echo "hello" >> README.md

>> linux输出重定向查看
步骤4：
提交文件或者说提交代码：

git add README.md

步骤5：
创建commit提交信息：

git commit -m "add hello to README.md"

此时，在master分支上就有了第一个commit记录。
此时我们额外在新建一个分支：

git checkout -b feature-A

接着修改一下README.md文件【目的是模拟文件内容变更】：

echo "CSDN reader nihao" >> README.md

接着，提交变更并且创建一个新的commit:

git add README.md && git commit -m "add CSDN reader nihao to README.md"

好了，现在有了一个新分支feature-A，我们把这个分支的代码提交到master分支。
以下需求实现有2种方法，有用的方法见操作2【已实现】
需求是这样的：master分支是另外一个人维护的，要怎么把你的分支给他呢？

两种操作：【请跳到下面的分割线操作2按步骤操作复制粘贴命令】

操作1：通过git diff 和git apply的方式【已演示，有问题】
通过以下命令来创建diff文件：

git diff commit1 commit2 > patch.diff
或者
git diff master feature-A > patch.diff
两个命令等价的，效果一样。

这里的commit1,commit2是分支对应的commit号才可以。可以用git log查看commit号。
准备好前戏工作：
按顺序执行以下命令：
在master分支上：

echo "commit1 on master" >> commit.md
git add commit.md
git commit -m "add commit1 on master to commit.md"

执行git log:

输出结果如下：

commit 999ef96f2eba2b9729941f85bbd8723d8e55065c (HEAD -> master)
Author: Keegan-y <keagen@163.com>
Date:   Sat Aug 28 00:05:05 2021 +0800

    add commit1 on master to commit.md
# 省略其他输出结果...

说明：
commit 999ef96f2eba2b9729941f85bbd8723d8e55065c
就是主分支上的提交记录，
就是git diff commit1 commit2 > patch.diff中的commit1。
此时主分支准备工作结束，下面来到feature-A分支：

在master分支上执行：

git checkout feature-A

来到feature-A分支上。

在feature-A分支上：

echo "commit2 on " >> commit.md
git add commit.md
git commit -m "add commit2 on feat to commit.md"

执行git log:

commit 1eaf94ce07f9b56d26722dca54aa0839e5cd4af9 (HEAD -> feature-A)
Author: Keegan-y <keagen@163.com>
Date:   Sat Aug 28 00:06:00 2021 +0800

    add commit2 on feat to commit.md

说明：
commit 1eaf94ce07f9b56d26722dca54aa0839e5cd4af9
就是feature-A分支上的提交记录，
就是git diff commit1 commit2 > patch.diff中的commit2。

接着在feature-A分支上执行：

git diff 999ef96f2eba2b9729941f85bbd8723d8e55065c 1eaf94ce07f9b56d26722dca54aa0839e5cd4af9 > commit1_commit2_patch.diff

最后在feature-A分支上查看commit1_commit2_patch.diff文件显示情况：

切换到主分支：

git checkout master

创建完成的patch.diff文件类似下面的格式：

这个文件最重要的部分在于 + 的部分，
对应的也会有 - 的情况，如果删除或者替换，变更了某行的话，
那么 + 或者 - 声明了变更内容。
+CSDN reader nihao说明是在hello添加了一行内容：

commit 442745380d833fdbab70dfb45b15487764ac7c23 (HEAD -> feature-A)
Author: Keegan-y <keagen@163.com>
Date:   Fri Aug 27 23:13:10 2021 +0800

    add two two two to test.txt

commit 9aba8c4a58289d207bc98333a4e3ae8c07d1692b
Author: Keegan-y <keagen@163.com>
Date:   Fri Aug 27 23:10:01 2021 +0800

    one one one to test.txt

上面的patch.diff文件可以发给另外一个人，他就收到之后，只需要在master分支执行以下命令：

git apply patch.diff

就可以把我们做的变更应用到当前分支。
只是这种方式无法保留作者信息，也就是我们自己创建的commit信息。

说明：操作过程中有问题：

error: commit.md: patch does not apply

可能是先做了操作2然后做操作1有些顺序没遵循导致错误，环境混乱了，谷歌没搞定，
先放放，没关系，掌握操作2一样能解决问题。
如果有读者有
error: commit.md: patch does not apply
的解决方案，
含泪谢谢在评论区贴出来。

–分割线----------演示操作2-----------------------
因此还有另外一种方式，操作2【已演示没问题】：
即通过：

git format-patch <对应的一个或者多个commit>

来生成patch文件，通过：

git am <上面生成的patch文件>

来把patch合并到分支中。

上面演示的案例，我们可以通过:

git format-patch HEAD~1

来把最新的commit制作为patch，
此时目录中就会多出来一个后缀为 .patch 的文件。
如果是多个commit的话，那么就会有多个文件。

文件格式如下：

之后呀，你只需要把文件发送给另外一个人，他在master分支执行：

git am <对应的patch文件>

就可以把其他分支的commit放到当前的分支中。
好极了，先切换到master分支：

git checkout master

查看master分支的文件情况：

然后查看commit信息情况：

git log

图1：

再接着执行：

git am 0002-add-CSDN-reader-nihao-to-README.md.patch

会看到以下输出：

图2：可以对比上面的图1可以看出commit的变化情况，我框出来了。

------结束，这个话题有点高级了，掌握操作2即可------
步骤6：
在本地代码推送到远端之前，要设置远端仓库的地址：

git remote add origin git@url.git

注意：
origin只是仓库名，你也可以改成origin01，也可以改成github。看需求，一般远端仓库的默认名字是写origin的。提一嘴是提醒不要固定死了思维。
git@url.git 是ssh地址，https开头的是HTTPS的地址。

步骤7：
生成SSH KEY【生成 SSH 公钥】

非常详细的生成 SSH 公钥操作参考
步骤8：
再次往远端仓库为origin提交，推送代码：

git push -u origin master

推送结果：

以上就是拿Git干活的基本操作。会用以上基本命令你也会拿Git干活了。

7.2 总结

只是简单介绍了Git的常用命令，关于Git更多的用法，强烈推荐：
Git官方在线图书

掌握了上面基本命令，记住使用步骤，强烈建议建议建议你在PyCharm/Goland上操作git，能可视化+带提示帮你提交代码，解决冲突【你在git bash里搞不定冲突，在PyCharm/Goland上操作一看就知道怎么做了，人家可视化+提示，你只需要手指点一点即可，很简单，节约你的时间】，工具是个好东西，前面的步骤都是为了这样一句话铺垫：【PyCharm/Goland上玩git】
【不会的可以在评论区留言，我看到后会继续在后文补充。既然是git使用教程，那就是成体系的，知识技能是结构化安放的，方便查，方便增，是不？】

到此，git使用教程就写完了，既是自己的实践记录【记不住哈哈】，也能帮助更多的道友管理控制代码，如果内容对读者有用，请关注我，为思考点赞！

最后奉上导图笔记：

8.思维导图笔记

9. 其它问题

问题1描述：
[root@localhost comment-be]# git push
warning: push.default is unset; its implicit value is changing in
Git 2.0 from ‘matching’ to ‘simple’. To squelch this message
and maintain the current behavior after the default changes, use:
git config --global push.default matching
To squelch this message and adopt the new behavior now, use:

git config --global push.default simple
See ‘git help config’ and search for ‘push.default’ for further information.
(the ‘simple’ mode was introduced in Git 1.7.11. Use the similar mode
‘current’ instead of ‘simple’ if you sometimes use older versions of Git)
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.

然后很自然地使用：
[root@localhost comment-be]# git config --global push.default simple
[root@localhost comment-be]# git push
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

不错，看来经过我的快速试错，问题变得明确了，到这里我会解决了。
开始猜测。
问题定位是公钥没设置，不应该呀，然后使用以下命令检查：
[root@localhost comment-be]# cd ~/.ssh/
[root@localhost .ssh]# ls
known_hosts

这就是问题所在了，不应该只有known_hosts这一个文件。
会不会是我没切换用户呢？（猜测可能是因为linux下不同的用户导致的这个问题）
这是root用户，我之前开发用的是vagrant用户，于是：

可以发现，发生问题的原因是我没有切换到vagrant用户导致的。
小结：
无他，多想想，多猜猜，然后验证。
没有实践，就没有发言权。
踏踏实实写点真东西，不要偷懒，因为偷技术的懒，它迟早会找你算账的。

送给读到此处的你：为你的耐心点赞~读不懂没关系，多搜搜，总能找到你能看懂的东西，要有耐心，没耐心可不行。为思考点赞！