据我所知，团队代码维护分为两派：git命令行党和图形化界面党，二者彼此都还瞧不上。。。

当我在实际开发中二者都使用过之后才明白，图形化界面真是解放coder，提升团队默契和开发速度的一个利器啊。当然，这种所谓的“无脑”操作带来的便利也真是命令行党的鄙夷所在。

说实话，我是十分的崇拜那些git命令行大佬的，但是在日益加速的快速迭代快速开发的时代，图形化是真好用啊！

进入正题，在我的实际开发中我用到的图形化界面不多，TortoiseGit（小乌龟）、SourceTree、VScode，都是我认为比较好用的软件了，关于sourcetree就不赘述了，上手简单容易。这边文章主要是记录我日常工作中用到的使用频率最高的命令行，希望看到这些文字的你请多多指正。

一、日常git命令

git clone XXX 

----》下载代码，推荐ssh方式

git checkout master && git pull 

----》切换到对应分支，并拉最新代码，如上面是拉master分支。建议分开使用，以免冲突

❗️❗️此处注意区别以下命令

git pull --rebase

—-rebase 并不会产生一个commit提交，而是会将你的E commit附加到D commit的结尾处。在看commit log时，不会多出你所不知道的commit出来

git checkout “XXX“ 

----》切换到“XXX”分支

❗️❗️此处注意区别 git checkout -- file  丢弃工作区的修改，

eg：

    命令git checkout -- readme.txt意思就是，把readme.txt文件在工作区的修改全部撒销，这里有两种情况:

    一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库-模一样的状态;

    一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。

git stash -m "XXX" 

----》一般在提交代码前必须要拉去目前代码库里最新的代码，不然你提交的版本过低就会导致集体的冲突。此命令行可以将你当前的修改存到本地缓存，-m后面紧跟你自定义的此次缓存的名字，没有特殊含义，主要是方便自己区别。

git stash  pop

----》释放修改，也就是上一步git stash 的反向操作，如果提示有冲突时，先解冲突

git add XXX

----》将工作区需要提交的文件提交到版本裤

git commit -m "YYYY"

----》添加提交注释

git push origin HEAD:refs/for/master

----》提交，如上面是提交到远程master分支

二、git commit log的优雅处理

我认为一个优秀的程序员并不是他写出来的代码有多么的晦涩难懂才证明了他的高级，相反，真正的优秀是他的代码工整、规范、易懂才最优雅。因此代码注释便是一个优秀程序员的必备基本素质。

日常开发中，将自己的每次提交都做好注释，并且是一目了然的注释自然是十分重要。下面给大家接受我在日常开发中常用的优雅提交方式，当然，作为团队一份子的你也不能擅自使用团队，如果你的队员看不懂的话，最好是要做好提前沟通和约定才最能提高团队开发的素质和效率。😊

feat: 新功能

fix: 修复问题

docs: 修改文档

style: 修改代码格式，不影响代码逻辑

refactor: 重构代码，理论上不影响现有功能

perf: 提升性能

test: 增加修改测试用例

revert: 回退，建议直接使用Github Desktop回退，而不是使用命令