git命令记录

git知识:
git并不是基于diff进行管理的,git的每个commit都是当前版本的快照
git工作流:
1.feature branch
git flow,gitlab flow,github flow都属于feature branch development,它们都有一个共同点:都采用『功能驱动式开发』,
即:需求是开发的起点,现有需求再有功能分支或者补丁分支

  • 定义
    所有特性开发都应该在专用的分支,而不是在主分支中进行
  • 上线模式
    1.从master分支创建一个功能分支
    2.开发者们在功能分支中完成开发工作
    3.构建功能分支,并通知QA进行验证
    Q:构建的功能分支如何让测试验证?每个功能分支都部署一个线上的域名吗?
    4.如果发现任何问题
    4.1.开发者创建一个基于功能分支的修复MR
    4.2经过代码审阅和合并过程将修复的MR合入功能分支
    4.3在重新构建部署,并通知QA进行验证
    5.QA验证通过后,将功能分支发布至线上,然后将其合并入主干后删除
    -优势
    1.多功能并行开发
    2.保持主分支稳定
  1. 操作简单
    2.trunk-based
    -定义
    『基于主干的开发模式』是一种版本控制管理实践,开发者将小而频繁的更新合并到核心『主干』(通常是master分支)
    这是DevOps团队中的一种常见做法,也是DevOps生命周期的一部分,因为它简化了合并和集成阶段。事实上,它也是CI/CD的
    必备实践。
    与其他存在『长期分支』的功能分支策略相比,开发者可以通过一些小的提交创建『短期分支』。
    -上线模式

-从部署分支上线
:半自动化流程,适用于低频率的部署,以及自动化测试不全面的项目
1.从master分支创建一个部署分支RC
2.构建部署分支RC,并通知QA进行验证
Q:部署过程是不是已经发到master分支上了,已经经过e2e测试
3.如果发现任何问题
3.1开发者创建一个基于mater分支的修复MR
Q:RC的内容已经被提交到master分支上了吗?
3.2经过代码审阅和合并过程将修复 MR 合入 master
3.3将commits cherrypick到部署分支,再重新构建部署,并通知QA进行验证
4.QA验证通过后,将部署分支RC发布至线上,然后删除该分支

-从主干分支上线
:全自动化流程,适用于高频率的部署,以及自动化测试较为全面的项目
1.定时部署:每天或者每小时到了特定时间,部署机器人自动找到当前最新通过全部端到端测试的代码,然后将之部署上线
2.持续部署:每当有新代码合并到主干分支时,部署机器人自动验证新代码是否通过端到端的测试,以及是否与该项目相关,如果是则自动部署上线
为什么使用trunk-based development
1.允许持续的代码集成(CI)
在『基于主干的开发模式』中,源源不断的提交合入主干分支。
为每个提交添加自动化测试套件和代码覆盖率监控可以实现持续集成。
当新代码合并到主干中时,会运行自动集成和代码覆盖测试以验证代码质量。
2.确保持续的代码审查(CR)
『基于主干的开发模式』的快速、小型提交使代码审查成为一个更有效的过程。
借助小型分支,开发人员可以快速查看和审查小的更改。
与评审者阅读大面积代码变更的长期功能分支相比,这要容易得多。
3.支持连续的生产代码发布(CD)
团队应该每天频繁地合并到主分支。『基于主干的开发模式』努力使主干分支保持“绿色”,
这意味着它可以在每次提交合并后进行部署。
自动化测试、代码收敛和代码审查,保证了基于主干的项目可以随时部署到生产环境中。
4.更适用于大型 Monorepo 下的多人协作场景(scalable)
大型 Monorepo 下的多人协作场景更易出现代码冲突,不仅消耗的大量的人力解决冲突,
还增加了『长期分支』合入『主干分支』引入 bug 的可能性。与其它存在『长期分支』的功能分支策略相比,
开发者可以通过一些小提交创建『短期分支』进行快速迭代。
因此,随着代码库复杂性和团队规模的增长,『基于主干的开发模式』也能保证顺畅的多人协作。
5.线性的提交历史(Linear history)
5.1方便查看和跟踪历史记录
5.2方便回溯变更,比如:Feature A 是在 Bugfix B 之前或者之后引入的?
5.3方便排查 bug,比如:使用 Git bisect 二分排查,而非线性历史则难以操作
5.4撤销变更,比如:当你发现一个有问题的 commit,简单的 revert 对应的 commit 即可,
而非线性的历史会有很多跨分支的合并,使 revert 变得困难

git commit的type
chore: 日常事务、例行工作:注释、初始化、包的版本
style:样式
feat:新功能
docs:文档
refactor:代码重构
build:代码构建
fix:bug修复

git分支从prod-dev分支拉出来代码命名为什么?
dev-gmq-feature:dev名称当前功能
开发完成后提交到预发测试

git checkout -b 'xxx' 创建一个本地分支并切换到这个分支
git revert [HEAD|commitid] 撤销最近一次commit|撤销某一次commit
git revert [id] -m [1|2] revert掉上次的commit
git reset --soft HEAD^ 撤销本地上次commit
git reset --soft [commitid] 回退到这个分支得内容之后的内容都不见了

//本地分支和远程分支相互关联
git branch --set-upstream-to=origin/remote_branch yout_branch
1.远程新建了一个分支,本地没有该分支(vscode可以自动拉)
git checkout --trach origin/barnch_name 本地会新建一个分支名叫branch_name,会自动跟踪远程的同名分支branch_name
2.本地新建了一个分支,但是在远程没有
git push --set-upstream origin branch_name
3.本地分支和远程分支取消映射
git branch --unset-upstream
git diff barnch1 branch2 --stat //显示出所有有差异的文件列表
git diff barnch1 branch2 文件名(带路径) //显示指定文件的详细差异
git diff barnch1 branch2 //显示出所有有差异的文件的详细差异
git fetch//更新原创代码库

git merge --abort中断正在进行中得merging
//分支合并--no-f可以产生一条merge的commit记录
git merge --no-f test
mock数据stash,其他内容一定要commit
只要代码修改了就可以stash
https://blog.csdn.net/qq_38425719/article/details/107792754
stash存储的数据结构是一个栈,先进后出
stash的必须是add的数据,没有add的数据不行,stash里会是分支里面stash,其他不会stash
git stash save 'xx' //
gti stash list
git stash pop 删除缓存
git stash apply stash@{0} 不删除stash缓存,代码出来
git stash drop stash@{0} 删除单个缓存
git stash clear

feat:新功能
fix:修改bug
style:样式
docs:文档
refactor:重构

git master回滚
亲自测试通过;

1.首先备份当前的master分支,防止回滚失败。
方法为:从origin master中新建一个分支,名称随便,比如,master_backup。
2.备份完成后,将master回滚到指定的版本
注意这个地方,是将本地的master分支回滚到指定的版本。
方法:Git reset –hard commit-id
git push origin HEAD --force
3.回滚本地master完成后,
将回滚后的代码push到远端master,用于覆盖远端master分支。
方法为:通过git命令,必须通过命令来,sourcetree的方式不可行。
命令为:git push -f origin master。必须有-f,表示强制的意思。
此时,会要求用户输入远端仓库的用户名和密码,用于确认当前用户具有-f的权限。
4.push成功后,就可以删除备份的master了。

修改远程仓库url
git remote set-url origin http://10.100.10.22:8092/yishenghuo-web/ManageForHX.git
合并别人的commit到自己的分支
git cherry-pick 7351726fd9115f5baa00997e39471b94831ca24b

git config --global --list 查看全局变量
git config --global user.name "xxx"
git config --global user.email "xxx"
git config --global credential.helper store 不用每次push的时候输入userName和email

git pull
``fatal: Not possible to fast-forward, aborting
修复命令
git pull origin develop --rebase
可以在mybranch执行这个命令就可以拉远程develop的内容了
1.基于组内的开发分支checkout -b出自己的开发分支mybranch

git merge vs git rebase
git merge:

  • 记录下合并动作

git rebase:变基

  • 不会记录当前的合并动作

git config branch.develop.description '开发基线分支'
npm i -g git-br
git-br

test分支
git merge --no-f master
git revert -m 1
git merge --no-f master //会报错Already up to date
git cherry-pick -m 1

posted @ 2022-08-23 10:08  zeal666  阅读(74)  评论(0)    收藏  举报