如果一切顺利的话，可以在用户主目录里找到 .ssh 目录，里面有 id_rsa 和 id_rsa.pub 两个文件，这两个就是SSH Key的秘钥对， id_rsa 是私钥，不能泄露出去， id_rsa.pub 是公钥，可以放心地告诉任何人。
第2步：登录gitee，打开账号设置，从左边目录中找到ssh公钥：
2. HTTS协议
当然不配置公钥也可以使用HTTS协议。
3. 克隆
使用https协议
git clone https://gitee.com/zhao-yuchen_wanqui/learngit.git使用ssh协议
git clone git@gitee.com:zhao-yuchen_wanqui/learngit.git1.2 添加远程库
首先，登陆Gitee，然后，在右上角找到“新建仓库”按钮，创建一个新的仓库：
注意不要选择初始化仓库和模板，要创建一个空的仓库
点击创建会出现如下内容：
简易的命令行入门教程:
Git 全局设置:
git config --global user.name "xxx"git config --global user.email "13191810+wanqui@user.noreply.gitee.com"创建 git 仓库:
mkdir learngitq1cd learngitq1git init touch README.mdgit add README.mdgit commit -m "first commit"git remote add origin git@gitee.com:xxxwanqui/learngitq1.gitgit push -u origin "master"已有仓库?
cd existing_git_repogit remote add origin git@gitee.com:xxxwanqui/learngitq1.gitgit push -u origin "master"下一步，就可以把本地库的所有内容推送到远程库上：
$ git push -u origin masterCounting objects: 20, done.Delta compression using up to 4 threads.Compressing objects: 100% (15/15), done.Writing objects: 100% (20/20), 1.64 KiB | 560.00 KiB/s, done.Total 20 (delta 5), reused 0 (delta 0)remote: Resolving deltas: 100% (5/5), done.To github.com:michaelliao/learngit.git* [new branch] master -> masterBranch 'master' set up to track remote branch 'master' from 'origin'.把本地库的内容推送到远程，用 git push 命令，实际上是把当前分支 master 推送到远程。由于远程库是空的，我们第一次推送 master 分支时，加上了 -u 参数，Git不但会把本地的 master分支内容推送的远程新的 master 分支，还会把本地的 master 分支和远程的 master 分支关联起来，在以后的推送或者拉取时就可以简化命令。
- git push 提交代码
- git pull 拉取代码
推送成功后，可以立刻在gitee页面中看到远程库的内容已经和本地一模一样：
从现在起，只要本地作了提交，就可以通过命令：
git push origin master1.3从远程库克隆
打开另一个窗口模拟其他小伙伴下载远程库
1.4 分支管理
1.4.1 创建与合并分支
首先创建分支，我们刚开始都是只有个master分支，现在我需要创建一个dev1分支，然后对dev1分支中的内容进行更改，然后再将dev1与master合并。
- 当前这是我们的一条分支，也就是我们的主分支，master分支，我们的HEAD也是指向这我们的master。
- 当我们创建一个dev1分支，并切换到dev1分支，查看log，发现现在HEAD指向了dev1。dev1和master处于同一个版本中。
分支情况：
- 这个时候我们对文件进行操作还有进行提交就是对dev1的操作了，当我们进行了一次新的提交：
分支情况就变成这样了：
假如我们在 dev 上的工作完成了，就可以把 dev 合并到 master 上。Git怎么合并呢？最简单的方法，就是直接把 master 指向 dev 的当前提交，就完成了合并
- 我们切换回master，然后查看刚刚修改的文件，发现刚刚添加的东西消失不见了：
- 要想把刚刚对dev1的修改出现再master中，我们就需要进行合并，达成下面的样子：
Administrator@zyc MINGW64 /s/study/03git/learngit (master)$ git merge dev1Updating 8c94e5c64..37e774f05Fast-forward readme.txt | 1 + 1 file changed, 1 insertion(+)git merge 命令用于合并指定分支到当前分支。合并后，再查看 readme.txt 的内容，就可以看
到，和 dev 分支的最新提交是完全一样的。
合并完成后，就可以放心地删除 dev 分支了,删除后我们查看一下分支：
总结：
总结：
- git checkout
- git checkout – file：把版本库的文件重置到工作区（撤销工作区的修改）
- git checkout master：切换到master分支
- git checkout -b dev：创建dev分支，并且切换到dev分支
- git branch
- git branch：列表分支分支，有*当前的分支
- git branch dev：创建dev分支，如果切换需要git checkout dev
- git branch -d dev：删除分支
- git merge dev：合并分支
1.4.2 版本冲突
- 我们准备好新的分支，然后进行新的开发：
# 这里我们使用到了一个新的命令git checkout -b feature1# 等同于：git branch feature1 #创建分支git checkout feature1 #切换分支
- 然后我们对readme.txt进行修改：
这里我对readme.txt进行了修改，在最后新增加的一行new feature1 simple 内容，并进行提交- 切换到 master 分支：
Git还会自动提示我们当前 master 分支比远程的 master 分支要超前1个提交。- 这时，我们将master中的readme.txt最后添加一句 new master simple并提交：
这个时候我们可以想到现在的分支情况如下：
这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：
果然冲突了！Git告诉我们， readme.txt 文件存在冲突，必须手动解决冲突后再提交。 git
status 也可以告诉我们冲突的文件
然后我们查看readme.txt的内容
Git用 <<<<<<< ， ======= ， >>>>>>> 标记出不同分支的内容，我们修改如下后保存：
new master and feature1 simple
再次提交：
现在， master 分支和 feature1 分支变成了下图所示：
用带参数的 git log 也可以看到分支的合并情况：
最后删除分支feature1，并查看log：
就会变成如下分支：
1.4.3 分支管理策略
- fast forward模式
通常，合并分支时，如果可能，Git会用 Fast forward 模式，但这种模式下，删除分支后，会丢掉分支信息。如果要强制禁用 Fast forward 模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。下面我们实战一下 --no-ff 方式的 git merge ：
首先，仍然创建并切换 dev 分支：
$ git checkout -b devSwitched to a new branch 'dev'修改readme.txt文件，并提交一个新的commit：
$ git add readme.txt$ git commit -m "add merge"[dev f52c633] add merge1 file changed, 1 insertion(+)现在，我们切换回 master ：
$ git checkout masterSwitched to branch 'master准备合并 dev 分支，请注意 --no-ff 参数，表示禁用 Fast forward ：
$ git merge --no-ff -m "merge with no-ff" devMerge made by the 'recursive' strategy.readme.txt | 1 +1 file changed, 1 insertion(+)因为本次合并要创建一个新的commit，所以加上 -m 参数，把commit描述写进去。
合并后，我们用 git log 看看分支历史：
$ git log --oneline --graph* e1e9c68 (HEAD -> master) merge with no-ff|/| * f52c633 (dev) add merge|/* cf810e4 conflict fixed...可以看到，不使用 Fast forward 模式，merge后就像这样：
- 分支策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
- master 分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
- 那在哪干活呢？干活都在 dev 分支上，也就是说， dev 分支是不稳定的，到某个时候，比如1.0版本发布时，再把 dev 分支合并到 master 上，在 master 分支发布1.0版本；
- 你和你的小伙伴们每个人都在 dev 分支上干活，每个人都有自己的分支，时不时地往 dev 分支上合并就可以了。
所以，团队合作的分支看起来就像这样：
我们执行以下操作进行练习：
#创建本地dev分支git checkout -b dev#提交dev给服务器git push origin dev#创建bob的本地分支git checkout -b bob#创建env.txttouch env.txt#提交git add .git commit -m "add env bob"#回到dev，合并bob分支git checkout devgit merge bob#上传dev到远程git push origin dev
#注意，只下载master分支，其他分支不会被clonegit checkout -b devgit branch --set-upstream-to=origin/dev dev#等价于git checkout -b dev origin/dev#拉取dev分支git pull origin dev#创建mickey分支git checkout -b mickey#修改env.txt增加内容"mickey env"vim env.txt#提交git add .git commit -m "update env by mickey"#合并到devgit checkout devgit merge mickey# 上传 git push origin dev合并到master分支
#拉取最新代码git pull origin master**既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！**gin/dev#拉取dev分支git pull origin dev#创建mickey分支git checkout -b mickey#修改env.txt增加内容"mickey env"vim env.txt#提交git add .git commit -m "update env by mickey"#合并到devgit checkout devgit merge mickey# 上传 git push origin dev合并到master分支
#拉取最新代码git pull origin master[外链图片转存中...(img-6C0zpQhr-4702043030686)][外链图片转存中...(img-S5XVJlLn-4702043030687)][外链图片转存中...(img-v2WPGIVr-4702043030687)]**既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！**
