为什么在clone项目的时候会有https和ssh地址两个选项？
一种区别是两种方式去clone项目走的是不同身份验证方式，https的话走的是账号+密码的方式验证身份，ssh的话走的是ssh-key的方式去验证身份。 另一种区别是https即便只有只读权限，也能把代码clone下来，ssh的方式则clone代码都不可以
两种方式各有优劣，ssh的方式对于很多场景都比较方便，不会泄露对应git账号密码，对于一些打包机的场景，用ssh的方式去拉代码省去了验证时输入账号密码的步骤，也不用刻意在某台打包机上去登某个git账户
为什么公司规定了工号密码每半年换一次，我每半年发现提交不了代码才想起来密码换了，却没见同事mark在电脑上更新过git密码
通常公司/员工为了方便，一般都是将工号(工名)和对应服务密码作为企业git服务的账号密码，然后为了安全考虑，公司会要求员工每半年更换一次密码。上面说过clone项目的时候会有https和ssh地址两个选项，我clone项目的时候都走的https的方式，然后命令行会要求我输入账号密码，验证通过后就能正常提交了。每到半年的时候发现企业oa提示要更换工号密码，于是就立马修改，修改完之后却一时没想到要同时去更新本地git客户端的密码，然后等到提交代码的时候发现验证不通过才意识到密码换了，然后才去更新git客户端的密码。
但是却一直不见同事mark有这样的操作，然后留心他clone项目的方式，一直都是通过ssh地址的方式clone项目的，本地生成的ssh-key在企业git服务中配置过保证不删除就一直能够正常提交代码而不受密码修改的影响
为什么平时生成ssh-key的时候，都推荐我们直接使用三个回车？
如图所示，通过命令
ssh-keygen -t rsa -C "your email"生成ssh-key的时候会要我们输入存储ssh-key的文件目录，以及对应的密码和密码二次确认，分别对应我们输入的三个回车。第一个回车是默认使用路径/c/Users/xiaoqq/.ssh/id_rsa作为ssh-key的存放地址，第二个回车则是将回车符作为密码，第三个回车则是对密码二次确认。
当我们生成完ssh-key之后，我们一般的操作是把/c/Users/xiaoqq/.ssh/id_rsa.pub文件内容拷贝到Github的SSH Keys列表中，然后我们就能通过ssh的方式clone项目了。再说回三个回车的问题，其实三个回车都是为了省事，第二第三个是为了不用想密码，第一个则是为了直接使用默认的ssh-key地址，那么第一个回车只有省略自己去想ssh-key地址这一点方便么？不只是的，因为这个默认的ssh-key地址其实是系统默认认可的地址，假如我们第一处不使用回车，而是输入/c/Users/xiaoqq/.ssh/github_rsa，那么其实你会发现，你之后直接通过ssh的方式去clone项目是clone不下来的，因为系统在其默认的认可的地址中没有找到你的ssh-key，这时候就需要你手动去配置，这个配置在文件/c/Users/xiaoqq/.ssh/config中，这个文件默认是没有创建的，如果你需要配置就需要你手动去创建，且文件名必须是没有任何后缀的config，在该文件中可以进行如下配置
配置完之后就可以正常通过ssh的方式clone项目了。所以推荐第一处也使用回车确实是省事的，不过可能在某些场景就不适用了
为什么同事mark能在本地同时配置公司gitlab环境和github环境无缝切换提交代码，而我要么通过https的方式挣扎于输入不同平台的账号密码，要么通过ssh的方式发现总有一个环境无法提交代码
当通过https的方式clone项目时，确实在不同平台提交代码是需要输入不同平台的账号密码无可厚非。而通过ssh的方式，假如这种场景依然使用了推荐的三个回车生成ssh-key的方式那么就会有题中的问题，总有一个平台提交不了代码。
那是因为通过三个回车的方式生成的ssh-key总是会在固定路径下，当你分别在两个平台都分别通过三个回车生成ssh-key之后，把对应内容拷贝到平台ssh-key列表配置中的时候，后面生成的ssh-key总会覆盖前面生成的ssh-key，机会导致前面生成的ssh-key失效，所以总有一个平台是失效的。那么这种情况就可以分别自定义ssh-key文件名，然后建立配置文件/c/Users/xiaoqq/.ssh/config，然后添加一个gitlab的设置，在不同配置中指定不同的ssh-key文件地址，这样在进行ssh认证的时候就会根据不同平台的host来判定平台取对应配置，识别不同的ssh-key文件
更简单的方式是，还是通过三个回车生成ssh-key，只是将相同内容分别粘贴到不同平台的ssh-key配置列表中，这样当你在不同平台去提交代码，走默认ssh-key地址去验证，验证都是通过的，那么就自然而然能正常提交代码了
为什么我的同事mark的git提交记录中用户名跟工号姓名都不一样，甚至还有头像，而我的用户名只是个光秃秃的工号？
这个就要说到git的配置文件了，如问题中所说，提交记录中同事的用户信息包括有名称+头像，而决定名称和头像的分别是配置项中的user.name和user.email。关键的是这些可以随便填而不影响你是否能提交上去，决定你是否能提交上去的是ssh方式的ssh-key和https方式的账号密码。
user.name好理解直接把配置的内容作为用户名，user.email决定头像是因为git会去对应的服务中寻找对应邮箱注册的git用户的头像，也就是说其实你可以伪造提交，让这个代码看起来就真的很像是别人提交的。可以通过修改user.name和user.email的配置，改成和其他人的一样，那么在提交记录中看到的用户信息就会看起来是别人的。
以下是我用github测试的时候恶搞的操作，我在本地配置了之前学校一个大神师兄的邮箱和乱写的用户名然后提交，可以看到头像用了大神师兄的，然后去github网页上看到的竟然更逼真，github这块估计用户名是跟着邮箱走的，然后把用户名自动改成了大神师兄的，这样就看起来大神师兄真的在我这个仓库里提交代码了🤣
git配置级别主要有以下3类：
仓库级别 local 【优先级最高】
用户级别 global 【优先级次之】
系统级别 system 【优先级最低】
- git仓库级别对应的配置文件是当前仓库下的.git/config文件中【.git目录是默认隐藏的需要显示默认隐藏的文件】
- git用户级别对应的配置文件是电脑当前用户文件夹根目录下的的.gitconfig 对应 (~/.gitconfig)
- git系统级别对应的配置文件是git安装目录下的 /etc/
我们可以通过直接修改配置文件内容的方式完成，如下图
更主流的方式是通过命令行的方式去修改，以下分别为三种级别修改用户配置的命令行
git config --local user.name "aaa"
git config --local user.email "aaa@163.com"
git config --global user.name "aaa"
git config --global user.email "aaa@163.com"
git config --system user.name "aaa"
git config --system user.email "aaa@163.com"
不过仓库级别配置的时候需要cd到目标仓库目录之下再执行命令行，命令行执行完之后会自动在对应配置文件添加相应配置内容
三种不同级别的配置可以支持你实现在不同的场景下的用户信息配置，假如只是某个仓库的提交信息中想特殊应用某个用户名，那么针对对应仓库使用local级别的配置设置方式即可；假如大部分场景下希望使用xxx这个用户名，那么使用global级别的的配置设置方式即可，这样除了设置过local级别配置的仓库，其他仓库都默认使用global的设置，另外system级别的配置，我们一般是不会去配置的，我猜想系统这里默认可能配置了操作系统当前用户名为user.name
重度参考以下文章：
同一台电脑同时使用gitHub和gitLab - 给你一页白纸 - 博客园 (cnblogs.com)
