有时候会高估自己在别人心中的分量,因为会去希望,也会期待,指望别人会有多好。应该不算一种坏习惯吧,只是自己可能失望或者失落多一些,或者慢慢就会适应,然后学着调整自己的位置。
git了解
1、git是一种分布式的版本控制的软件。
a、分布式:
b、版本控制:大学论文一遍又一遍修改,最终会有很多个版本,这种是文件版本控制。
存太多版本了,不是我想要的,向前发展。。。
c、本地版本控制:(此时只有一个当前版本了,通过命令可以查看以往的不同版本的论文),此时只能是自己进行控制,不能同时多人协作一起控制
d、集中式:(存在中央服务器)这里存着所有的不同的版本—SVN,每一个电脑上只存在一种版本,若当前中央服务器挂掉了,此时代码的完整性可能就被破坏了。
分布式:与集中式不同,每一台电脑上都保存了一份所有版本的代码,主服务器挂掉并不影响代码的完整性,依然可以进行各自的开发。
软件:下载安装到电脑上运行的称为软件
2、进行版本控制的主要目的:防止线上问题,方便回滚。
3、git配置个人信息
git config --global user.email “wangzi@qq.com”
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/+“修复的内容概括”
其余流程 与分支开发时的流程一致。