Week1

git基本操作

1.初始化 创建新版本库
git clone 项目地址 (克隆一份到本地)
cd 项目本机地址
touch README.md (创建文件)
git add ./README.md (添加资料到本地缓存区、可反复多次使用，添加多个文件)
git commit -m"备注 上传什么东西" （添加所有资料到本地库）
git push -u origin master (将本地库push到服务器上面的msater)
others
git branch -a （查看所有本地分支)
git checkout -b dev(创建并切换到dev分支，已有该分支就不加-b)
git merge self (将self分支合并到dev上,此步骤需切换至主分支)
git push --delete origin 远程分支名（删除远程分支）
git status(即gst) 检查本地需要提交的文件
备份修改
git stash (把当前工作现场“储藏”起来，等以后恢复现场后继续工作)
git stash pop(恢复备份的工作现场）
tig 查看本地日志
查看精简日志：git log --pretty=oneline
暂存区概念：

image.png

与主干同步:git rebase origin/master
查看修改内容：git diff
版本回退：git reset --hard commit_id。HEAD指向的版本就是当前版本，上一个版本就是HEAD^
回退前，用git log可以查看提交历史，以便查找回退版本的ID。
重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。
pull冲突
终端：拉取pull -> 解决冲突 -> 正常提交
覆盖修改（本地提交3次通过覆盖远程端提交2次）
前两次正常commit、push -> 第三次修改后（git commit --amend 、git push -f origin B)

CI/CD

What

CI：将应用代码的新更改定期构建、测试并合并到共享存储库中（有需人工操作的按钮）
CD：自动将应用发布到生产环境（无按钮）

How

通过buildkit工具：配置pipeline.yml文件，由auto参数指定操作

Why

缩短产品上市时间，降低实施成本，提高监控能力。传统部署方式可移植性差，对存储能力要求高，代码更新后，甚至需要重启部署。（典型如tomcat、img镜像备份方式）

Application

实际应用时，由于buildkit方式通常需要先测试后部署，若修改较大且有短时响应需求时，可暂时采用CI，先完成测试，时机合适时人工操作开始部署。

AWS Cognito

• userpool：为应用程序提供注册和登录选项的用户目录。
• identity：提供 AWS 凭证以向用户授予对其他 AWS 服务的访问权限。

Application

实际应用时，其他业务线进入网站做某些操作时，要进本线userpool完成用户认证。

others

pool ARN ：地区+account+user pool+identity pool
Lambda：“一段程序”
S3：simple storage service
尾递归
尾递归 = 尾调用 + 递归

• 递归：函数调用自身，称为递归
• 尾调用：函数最后是调用另一个函数

总结：一个函数在其内部最后一步调用其自身
return tailrec(x+1); //尾递归
return tailrec(x+1) + x; //非尾递归

OAuth2 + OpenID1.0

OAuth角色:

• Consumer：消费方
• Service Provider：服务提供者
• User：用户

OAuth流程：
（A）用户打开客户端以后，客户端要求用户给予授权。
（B）用户同意给予客户端授权。
（C）客户端使用上一步获得的授权，向认证服务器申请令牌。
（D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。
（E）客户端使用令牌，向资源服务器申请获取资源。
（F）资源服务器确认令牌无误，同意向客户端开放资源。

OAuth和OpenID的区别：

OAuth关注的是authorization授权，即：“用户能做什么”；
而OpenID侧重的是authentication认证，即：“用户是谁”。
前者是网站对用户进行认证，让网站知道“你是你所声称的URL的属主”
后者其实并不包括认证，只不过“只有认证成功的人才能进行授权”，结果类似于“认证+授权”