Git的工作流程图

基本命令：

clone：从远程仓库克隆代码到本地仓库

checkout：从本地仓库检出一个仓库分支，然后进行修订

add：在提交前，先将代码提交到暂存区

commit：提交到本地仓库。本地仓库中保存修改的各个版本

fetch：从远程仓库抓取到本地仓库，不进行合并操作（使用较少）

pull：从远程仓库拉取到本地仓库，总合并，然后放到工作区

push：修改完成后，需要和团队成员共享代码，将代码推送到仓库

status：查看一些状态信息

log：查看提交日志

commit的工作流程

log命令的查看

alias git-log='git log --pretty=oneline --abbrev-commit --all --graph'

--pretty=oneline 表示commit信息压缩成一行

--abbrev-commit表示commitID最小长度

--all显示所有分支的提交

--graph以图的形式显示

版本回退

版本切换：git reset --hard commitID

具体了解 reset 不同参数对本地仓库、暂存区和工作区的影响。

commitID 可以通过 git log 查看

已经删除了的分支可以通过 git reflog 分析出来删除的分支的 commitID

告诉git别管哪些文件

创建一个 .gitignore 文件，在里面写上不用git管理的文件（可以使用通配符）

比如我不想 .a 后缀不需要管理，所以我们就可以在 .gitignore 写上 *.a

被选中的文件不在通过git进行管理。

git的分支

真实的开发中是会使用很多个分支的，分支之间经常会产生冲突，下面我就通过类似实验的方式，一步步探究：git的分支是如何产生的。

假设在最开始，一个人单人开发一个 master 分支，这个分支的状况如下

master 分支原来只有一个人开发，并把内容写在 master.txt 中。

后来，本项目变成了两个人开发，这个时候，一条分支不够用了，需要另外一条分支。

两个人商议决定开一条新的分支 workerA 给新加入进来的人开发

git checkout -b 新分支名

可以创建一个新分支，并切换到新分支中

workerA 刚创建好的项目状况如下：

由于 master.txt 是已经有人在开发了，workerA 只能另开一个工作文件 workerA.txt 来进行开发。

注意：在workerA.txt创建完成后，但还没有commit到workerA分支时，master是能看见workerA.txt的。

按理说master不合并workerA分支是看不见workerA分支新增的内容的，但上述的情况除外。

假设一段时间过后，workerA 在 workerA.txt 里完成了很多东西，但 master 没做任何事。master 分支能正确地合并 workerA 分支而不发生冲突吗？

合并前的状态：

合并后的状态：

这里给人的感觉就是：master 分支什么都没做，直接转入了workerA的劳动成果。

可以发现，在上述情况下，并不会出现分支合并冲突的情况。

以上面的结果为起始状态，workerA 又在 workerA.txt 上写了一些东西，而这一次 master 也干了点正事，写了一些东西在 master.txt 中。

这个时候，master 和 workerA 合并，会不会发生冲突？

合并前：

合并后：

可以发现，两个分支依旧能正常合并，不会产生冲突。

通过上述实验，大概可以判断一件事：

不同的分支如果工作在不同的文件中，不管他们怎么样改变自己的文件的状态，最终都能不会产生冲突地合并。

那如果 workerA 不满意 master 所写的 master.txt 内容，想要将其全部进行修改。而 master 不知道 workerA 所做的修改，依然在 master.txt 上工作，那最终很可能产生冲突。

先将上一步的 master 合并到 workerA 以更新其状态

下面我就来进行实验。master.txt 的初始状态如下：

workerA 对其工作区的 master.txt 做出了修改并commit，做出的修改如下：

而master只是单纯对master.txt增加了一些东西：

这种情况下，master 合并 workerA 会不会产生冲突？

合并前：

此时，冲突产生，git帮我们标记处了冲突的地方，让我们做出选择。

根据上面的结果，可以分析出怎样的结论？

只要各分支工作在只属于自己的工作区上，不去干扰其他分支的工作区，那就可以避免冲突。

可是，我们可能会想：执行的时候可能只有一个主函数，如果我们需要测试自己的代码，那不都是要改主函数吗？

关于这个问题，如果我们是用Java进行开发，那Junit可以一定程度上解决这个问题，因为每个人都能拥有自己的测试类。

但是对于其他编程语言，我能想到的方案就是，你可以修改main函数，但永远记住不要commit它，这样就不会让别人看见你修改了main，冲突就不会发生。

从这里我们可以窥探到真实开发中的一些情况：一个团队肯定是通过分支进行协作的，每个人各自工作在自己的工作区上，不去影响他人的代码（信任你的同事）。

如果写好的代码想要进行测试，其实可以将使用的方法交给测试人员，让测试人员进行测试，他会告诉你测试的结果，你需要进行改进（信任你的同事）。

如果你认为自己的代码还没有完成，需要通过调试的方式完成编写，可以去改main函数，但不要将其加入暂存区也就是不要 git add 这样的话你的修改没有commit就是没有修改，合并依然能正常进行。