参考：https://mp.weixin.qq.com/s/Km5KuXPETvG0wCGHrvj9Vg
一，git本地版本库的基本用法
（1）首先初始化一个本地版本库
命令：git init （版本库名称），版本库名称可选用不用，如果不加版本库名称会初始化为当前文件夹为一个版本库，加上了名字后会在当前路径下产生一个文件夹。
初始时git的文件夹如图所示
执行 git init 命令，不带版本库名称
我们可以看到多了一个.git文件夹，把当前文件目录当成了一个版本库
执行 git init 命令，带版本库名称
多了一个test文件夹，且test文件夹之下也生成了一个.git文件夹
（2）查看当前工作区(workspace的状态)
命令：git status
先进入 test文件夹，然后执行 git status，此时由于是刚刚初始化的本地仓库，所以目前的状态是还没有执行过commit操作过。
（3）把文件添加到暂存区(index)
命令：git add [files]
该命令添加的是当前文件夹下的文件
（4）把文暂存区的文件提交到仓库
命令：git commit -m "关于这次提交的描述"
（5）查看当前HEAD之前的提交记录，便于回到过去
命令：git log
（6）回退
命令：git reset -- hard HEAD^^/HEAD~100/commit-id/commit-id的头几个字符
报这个错误的原因是由于该仓库目前只有一commit，已经是head版本。
再一次commit后使用git log命令
再使用回退命令后回退成功了
（7）查看当前HEAD之后的提交记录，便于回到未来
命令：git reflog
（8）回到未来
命令：git reset --hard commit-id/commit-id的头几个字符
二，git远程版本库的基本用法
先在远程github上新建一个仓库
（1）连接到远程仓库
命令：ssh -T git@github.com
（2）克隆一个存储库到一个新的目录下
命令 ：git clone [远程仓库的地址]
可以看到生成了一个software文件夹
打开该文件夹可以看到改项目已经被克隆了下来
（3）下载一个远程存储库数据对象等信息到本地存储库
命令：git fetch
先在远程修改README.md文件
执行git fetch命令
本地打开发现并没有更新原来的文件 ，这个时候需要执行下一步的命令
（4）合并两个或多个开发历史记录
命令：git merge
合并上一步的fetch的远程分支到本地的当前分支
再次打开README.md文件，发现已经更新了
（5）将本地仓库的相关数据对象更新到远程仓库
命令: git push
在本地新建一个文件
需要先使用git add 命令添加到暂存区
然后使用git commit命令提交到本地仓库
最后再使用git push命令推送到远程仓库
再打开github，发现已经有了新的文件
（6）从远程仓库或分支抓取并合并到当前仓库的当前分支
命令：git pull
相当于git fetch 和git merge命令一起执行，默认更新到当前分支
先在远程仓库进行修改
然后执行命令
发现本地的文件已经更新了
三，团队项目中的分叉合并
如果团队项目像二中的方法一样多人同时向远程origin/master分支频繁提交代码，一来可能会有诸多冲突合并的情况发生；二来整个git log提交记录中多个开发者或多个代码模块的commit是交错排列在同一条时间线上，不利于回顾查看和回退代码，让跟踪代码的成长轨迹变得异常困难。
需要考虑新的方式来能够独立维护不同的开发者或者不同的功能模块的代码，让一段连续的工作在commit日志的时间线上呈现为一段独立的分支线段，只在关键节点处进行分支合并。
每一个开发者都采用的工作流程大致如下：
1，克隆或同步最新的代码到本地库
2，为自己的工作创建一个分支，改分支应该只负责单一功能模块或代码模块的版本控制
3，在该分支上完成某单一功能模块或代码的开发工作
4，最后，将改分支合并到主分支上
（1）把远程的仓库克隆下来
（2）为自己的工作创建一个分支，该分支只负责单一模块或代码模块的版本控制
先创建一个分支：命令：git branch [branchName]，当没有[branchName]的时候会列出在本地分支
然后再切换到自己创建的分支上
命令：git checkout [branchName]
（3）在改分支下进行修改和增加文件的操作
（4）推送到远程仓库
先切换为main分支，将远程 origin/main同步最新到本地仓库，再合并mybranch到main分支。
最后推送到远程orign/main 。
在远程仓库上可以看到已经进行了修改。
四，Git Rebase
一般我们在软件开发的流程中，有一个朴素的版本管理哲学：开发者的提交要尽量干净、简单。开发者要把自己的代码修改按照功能拆分成一个个相对独立的提交，一个提交对应一个功能点，而且要在对应的 commit log message 里面描述清楚。因此在合并和 push 之前检查修改一下 commit 记录时常需要。
在上面三中增加一步Git Rebase，即在mybranch分支上完成自己的工作之后，为了让 log 记录将来更容易回顾参考，用 git rebase 重新整理一下提交记录。
注意不要通过rebase对任何已经提交到远程仓库中的commit进行修改。
命令：git rebase -i [startpoint] [endpoint]
其中 -i的意思是 --interactive，即弹出交互时的界面让用户编辑完成合并操作，[startpoint] [endpoint] 则指定了一个编辑区间，如果不指定 [endpoint]，则该区间的终点默认是当前分支的HEAD。
可以使用HEAD^^、HEAD~100、commit ID或者commit ID的头几个字符来指定一个commit节点。
下面完成这么一个例子：
rebase之前的mybranch 分支，有A，B两个commit：
在mybranch分支合并进来之前，main分支进行了推进：
这个时候在mybranch分支合并到main分支之前进行rebase操作
rebase之前的mybranch分支日志
可以看到，已经没有 A，B的commit记录了，但是A，B所执行的修改还保留了下来
使用这个文件在每次提交前进行了 记录，A操作创建了这个文件，B操作，写了第一句，after B操作后写了第二句。此时改文件的内容没有改变。
然后进行分支合并，把mybranch分支合并到主分支。
合并前的主分支
合并后的主分支
最后推送到远程仓库
五，总结
git的版本控制在项目开发中起到的作用非常大，特别是对于多人合作的项目，能够高效便捷的完成合作开发，同时由于可以进行版本回退的性质，所以对于操作错误的容错性很大，对于团队项目开发而言，应该尽量使用git，能减少很多的沟通成本，同时对于项目的管理会更加高效。