有时候会高估自己在别人心中的分量，因为会去希望，也会期待，指望别人会有多好。应该不算一种坏习惯吧，只是自己可能失望或者失落多一些，或者慢慢就会适应，然后学着调整自己的位置。
git了解
1、git是一种分布式的版本控制的软件。
a、分布式：
b、版本控制：大学论文一遍又一遍修改，最终会有很多个版本，这种是文件版本控制。
存太多版本了，不是我想要的，向前发展。。。
c、本地版本控制：（此时只有一个当前版本了，通过命令可以查看以往的不同版本的论文），此时只能是自己进行控制，不能同时多人协作一起控制
d、集中式：（存在中央服务器）这里存着所有的不同的版本—SVN，每一个电脑上只存在一种版本，若当前中央服务器挂掉了，此时代码的完整性可能就被破坏了。
分布式：与集中式不同，每一台电脑上都保存了一份所有版本的代码，主服务器挂掉并不影响代码的完整性，依然可以进行各自的开发。
软件：下载安装到电脑上运行的称为软件
2、进行版本控制的主要目的：防止线上问题，方便回滚。
3、git配置个人信息
git config --global user.email “[email protected]”
git config --global user.name"wangzi"
4、git 官网安装 实现本地版本控制
①打开git进入git要管理的文件夹
②初始化仓库 git init 生成一个.git 的文件，里面会包含之后的版本控制的一些信息，一般不需要进行修改(开始管理了)
③git status 查看当前文件夹下的文件状态 （红色表示未管理）,有红色文件的处于工作区
④git add demo.txt 该文件变绿了，文件被管理了，若要所有被管理输入 git add . add之后进入暂存区
⑤git commit -m “v1” 实现第一个版本控制 commit之后进入版本库也就是本地仓库
⑥git log 查看已经生成的版本
5、回滚
git log 查看提交的记录 commit后面的一长串字符
git reset --hard +git_log命令之后的 想要回到的版本的commit 信息
回滚之后 git log命令不会显示被回滚的那条记录 需要输入 git reflog 这时就可以显示出所有的提交记录，想回到那个版本就运行 git reset --hard +版本号（git reflog命令之后，每一个提交都有一个版本号）
6、分支开发
V1是最原始的分支， V2是修改之后的，会通过指针的形式只保留修改的内容，未修改的保存一个快照的形式，指向V1，V3同理。V4、5表示创建了分支。
分支开发 是 解决线上bug紧急修复的一种非常好的形式。
比如v3是现在上线的内容，出现一个bug需要紧急修复，v5是目前正在开发的内容，那就可以在v3的基础上新建一个分支比如是v4，修复好之后V4合并到主分支上直接就可以直接上线，同时不影响V5的继续开发。
创建分支：git branch dev
切换分支：git checkout dev
创建并切换分支：git checkout -b dev
7、修复bug流程：
基于主分支创建分支bug,修改内容commit，回到当前主分支，合并bug分支。-------git merge bug
修复完之后，msater分支正常，这时候可以卸磨杀驴了，干掉bug分支。—git branch -d bug
8、github与gitlab
github代码托管仓库 gitlab(开源，自己搭建服务器自己创建仓库自己管理自己的代码)
9、git pull origin dev
git fetch origin dev先拉取到本地仓库 git merge origin/dev 为了表明是从远程拉取下来的前面要加origin/
10、有一种情况是 在家开发了一半代码，但忘记推送远程。然后回家了pull代码的时候发现没推送，这时候可以先开发其他功能的，然后push，到公司之后再pull代码，解决冲突，继续开发完成，再推送。
11、rebase用法
好处①可以使git记录更加简洁
将本地的多个提交记录合并成一个记录（已提交到远程仓库的不建议做rebase合并，会比较麻烦）
git rebase -i HEAD~2 表示将当前最新的记录与前两个提交的记录进行合并 或者 git rebase -i +版本号
场景②—git pull命令通常会产生分叉。为了避免产生分叉 可以输下面的命令： git fetch origin dev 再 git rebase origin/dev 若有冲突，先解决 再 git rebase --continue
场景③—分支开发，产生多个分叉，如果不想分叉就可以用rebase
12、解决多个冲突软件 beyond compare
git config --local merge.tool aaa
git config --local mergetool.path ‘软件安装目录’
git config --local mergetool.keepBackup false 表示解决冲突之后不保存备份文件
应用软件解决冲突： git mergetool
13、记录图形展示：git log --graph --pretty=format:"%h %s"
tag规范
git tag主要是对某一次代码提交后生成版本ID号进行标签注明的作用
每个项目合并master之后需要打tag
生产:GIC2021-01-21
测试环境：k8s_test_20210111
tag备注要尽可能明确
tag命令操作：
查看本地的tag git tag
在本地打一个tag git tag 1-25
删除本地tag git tag -d 1-25
创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。
给tag添加附注 — git tag V1 -m "first version“
如果要推送某个标签到远程，使用命令 git push origin 1-25
推送多个本地tag至远程 git push origin --tags
删除tag，已经推送至远程的，可以先删除本地的，再删除远程的 git push origin :refs/tags/1-25
删除tag 或者使用： git push origin :111
切换到某个tag对应的代码：git checkout <tagname>
如果想编辑某个tag对应的代码需要先创建分支再切换tag: git checkout -b <branch-name> <tagname>
tag使用场景：
mc-service 1-22日 上线 权限接口修改 tag: GIC2021-01-22
1.26日 上线新的内容 用户信息获取 tag: GIC2021-01-26 上线过程中发现代码有bug，此时有两种办法：
一种是：修复bug 进行新一轮的上线，这种情况可能时间要求比较高，需要迅速解决问题并上线
另一种是：利用已有的tag GIC2021-01-22 直接回退。将该tag下的代码部署生产环境，然后再去认真修复bug重新上线。
拉远程代码：
1、下载桌面工具，打开git bash here
2、创建文件夹并进入文件夹，进行仓库的初始化 mkdir test/ cd test / git init
3、关联远程仓库 git remote add origin <远程仓库地址>
4、拉取远程仓库代码 git pull origin master 或者 git clone <克隆地址> 此命令不需要进行仓库的初始化，可以直接克隆代码到本地
分支操作：
查看本地分支：git branch
查看远程分支：git branch -r
查看本地和远程分支：git branch -a
将所有分支拉到本地：git fetch (有些时候找不到远程分支可进行此操作)
查看本地分支绑定的远程分支：git branch -vv
绑定远程分支：git branch --set-upstream-to=origin/master
创建本地分支：git branch <分支名字>
创建并切换分支：git checkout -b <分支名字>
推送本地分支到远程：git push origin test:test
删除本地分支：git branch -D <分支名字>
删除远程分支：git push origin --delete <分支名>
分支重命名：git branch -m <原来名字> <新名字>
提交本地所有修改内容到暂存区：git add .
提交本地某一文件(加文件名)：git add test.py
将暂存区提交至本地分支: git commit -m “备注信息”
将本地分支提交至远程：git push
git stash操作：
将当前进度存储,把所有未提交的修改（包括暂存的和非暂存的）都保存起来，用于后续恢复当前工作目录。
git stash
推荐给每个stash加一个message，用于记录版本，使用git stash save取代git stash命令。示例如下：
显示所有已存储的：
git stash list----
恢复指定进度（不会从list列表中删除）：
git stash apply + stash@{ }:
恢复最新进度,会将最新进度从list表中删除：
git stash pop
清除所有的存储
git stash clear
清除某一个存储
git stash drop stash@{ }:
git 回退操作：
推送到本地仓库，不想提交，回到上一次提交的版本
1、soft ①移动本地库HEAD指针
意思就是，回滚后，仅仅是把本地库的指针移动了，而暂存区和你本地的代码是没有做任何改变的。
而你上次改动已提交到本地库的代码显示是绿色，即未提交
2、mixed ①移动本地库HEAD指针
②重置暂存区
意思就是，回滚后，不仅移动了本地库的指针，同时暂存区的东西也没了，意思就是你上次添加到暂存区的文件需要重新添加
3、hard ①移动本地库HEAD指针
②重置暂存区
③重置工作区
意思就是，回滚后，本地代码就是你回退版本的代码
依次进行4次提交，提交信息相应进行备注------------------
git log 查看提交记录，head指向最新的替吉commit-------
git reset --hard <commit 号>-------------------------------
再次git log 发现已经没有了 444的提交记录，代码更为333
4、keep
①移动本地库HEAD指针
②重置工作区
意思就是，回滚后，本地代码就是你回退版本的代码，暂存区的文件依然保存。
rebase操作：
将多次提交记录合并成一次提交，方便code_review
git rebase -i <某次提交的commit>
git log查看当前的提交记录
执行命令 git rebase -i 02ee740b49912baf2ed7275c983124b131d87bfc （会将之前的进行合并，不包括本次的commit） 进入如下页面，pick表示选中当前的提交 s表示不要本次commit 保存退出，进入第二个页面 输入本地合并之后的一个提交记录，保存退出，再次git log 合并成功了！！！
git push -f 强制推送至远程即可，合并成功。
rebase操作有一定的风险，会把之前的一些提交记录覆盖，建议新建一个分支进行操作。然后没问题之后将新建的分支合并所有的commit之后再合并至master.
merge操作：
当前所在分支 master
git merge branch_test----将分支 branch_test合并至master，通过merge进行操作会产生分叉，如下图1，如果不想产生分叉可以使用rebase,如图二，命令为 git rebase <分支名>，若有冲突解决完冲突之后，git rebase --continue
分支开发工作流:
当接到一个新的需求时，比如 修改数据库的用户名和密码，通常的流程如下 ：
切换到项目的master分支: git checkout master
拉取最新的代码: git pull origin master
创建新的分支并切换到新创建的分支：git checkout -b feature/update_database_username_pwd(分支命名通常以feature/开头，后加对应的功能名称)
在新创建的分支上进行修改，完成之后推送至远程：git add . / git commit -m “update_finish” / git push orgin feature/update_database_username_pwd:feature/update_database_username_pwd
将当前代码合并至master：git checkout master / git merge feature/update_database_username_pwd
将merge request 发送给 相关代码 review 的同事，进行code_review。
代码审核通过之后，在master上打tag,tag标准参考每个项目之前的，然后进行上线前测试。
没问题之后，正常上线。如发生回退，需提供上一版本的tag，这个需要在上线前提前准备好，以便及时回退。
线上发生bug需要紧急修复流程：
在创建分支并命名的时候略有不同，名字如下： hotfix/+“修复的内容概括”
其余流程 与分支开发时的流程一致。