MetMan's Blog

标签搜索

搜索到 9 篇与的结果 ———

日常开发场景Git使用技巧记录

日常开发场景Git使用技巧记录

记录日常开发场景中常遇到的Git使用技巧备查。撤销修改场景工作区文件修改了，但还没有进入版本管理，现在不想要了，如何回退、撤销已有的修改# 建议使用restore命令 git restore file # 也可以使用checkout git checkout -- file 合并本地多次提交记录场景场景：有时开发某一个功能时会提交很多次commit，这样会显得版本日志很乱，尤其是在多人协作的开发场景中。这时可以将多个紧密相关的commit合并成一个。简单情况：只是对最新一次的commit进行修正的话，可以使用git commit -v --amend更复杂情况：git rebase -i HEAD~4 # 合并最近4次提交记录 # 进入vi编辑模式，根据提示对相应commit选择命令，常用的包括pick,edit,squash,fixup s cacc52da add: qrcode s f072ef48 update: indexeddb hack s 4e84901a feat: add indexedDB floder p 8f33126c feat: ad...

2025年09月10日

13 阅读

0 评论

Git commit提交信息规范

Git commit提交信息规范

在一个多人开发团队中，使用统一的Git commit提交规范有助于后续的代码评审、版本发布及日志自动化生成。基于阮一峰的文章及其它资料构建Git comit提交规范。注意：不要使用git commit -m message方式提交记录，建议使用git commit打开编辑器窗口进行多行记录撰写。Commit message格式message由三部分组成：Header，Body和Footer。<type>(<scope>): <subject> // 空一行 <body> // 空一行 <footer>其中，Header 是必需的，Body 和 Footer 可以省略。不管是哪一个部分，任何一行都不得超过72个字符（或100个字符）。这是为了避免自动换行影响美观。HeaderHeader由一行构成，包括三个字段：type（必需）、scope（可选）和subject（必需）。typetype用于说明commit的类别，只允许定义的标识。- feat：新功能（feature） - fix：修正bug - docs：文档（do...

2025年09月10日

12 阅读

0 评论

Git使用p4merge作为diff和merge工具

Git使用p4merge作为diff和merge工具

我们团队之前使用Perforce作为版本管理软件，其提供的图形界面的diff/merge工具非常好用。因此在切换到Git版本管理后，希望Git合并版本时能够继续使用这些工具。下面是配置p4merge作为Git的diff/merge工具方法。安装从Perforce网站下载免费的二进制包。通过浏览器下载，安装包网址：https://www.perforce.com/downloads/visual-merge-tool 这里我们选择和操作系统匹配的2019版本(Centos 8.4)。或者直接使用wget下载。$ wget https://cdist2.perforce.com/perforce/r19.1/bin.linux26x86_64/p4v.tgz如果下载最新版本，会因为缺少依赖动态库报错。p4merge.bin: error while loading shared libraries: libOpenGL.so.0: cannot open shared object file: No such file or directory解压缩安装包并配置PATH变量$ mkd...

2024年12月03日

191 阅读

0 评论

Git合并请求的思考

Git合并请求的思考

前两天将开发的一个特性（feature）分支内容通过PR(Pull Request)合并请求方式合并到主线develop开发分支上。合并完成后复盘整个过程发现了一个问题：合并到develop分支的提交记录太多了。下面介绍了合并过程以及一些思考。在个人特性分支上开发过程中，非常频繁的提交，虽然有意识的使用amend修补提交方式合并提交，但结果提交记录仍然过多。对于一个特性分支来说，它的使命就是为了完成一个feature的开发，理论上应该只有一个commit提交记录。实际情况可能会有几个commit记录，但不应该太多。为了保持develop分支开发记录是一个线性记录，先通过变基（rebase）操作使个人特性分支变基到develop分支最新提交上，使特性分支看起来像是在develop最近提交基础上开始开发的。将个人特性分支推送到远程仓库，通过网页界面的PR按钮申请合并到develop分支。然后仓库管理员通过变基后快进方式合并特性分支内容。以上就是基于分支策略的工作流。这种变基后快进方式会将特性分支开发提交记录都会保存下来并维护develop分支线性记录特点。但这也带来一个问题：如果没有...

2024年12月03日

230 阅读

0 评论

Git commit提交粒度的思考

Git commit提交粒度的思考

提交粒度考虑在Git项目开发过程中经常需要考虑的一个问题，即修改提交COMMIT的粒度如何选择。如果粒度太细，很多提交可能没有意义，合并到开发分支（如果保持线性记录的话）太多这种提交会给团队其它人员造成困扰；但如果太粗，又会导致查看前面某个节点的版本快照以及版本回退困难。所以COMMIT提交粒度应该把握”适中“原则。我认为一个COMMIT提交应该是一个完整的子任务（subtask），比如按照函数级别的提交粒度，同时要保证提交时程序完整、能够正常运行。善用amend补救提交在开发过程中我们经常遇到这样一个场景：完成一部分代码的开发，虽然完成度还不高，但希望放进Git版本库中保存，中途可能有其他事去做。当后续继续开发时下一次提交实际上内容和上一次提交紧密相关的，使用新的COMMIT提交没有必要，此时可以考虑使用补旧时提交。$ git add file # 将文件添加到暂存区 $ git commit --amend # 进入COMMIT信息编辑窗口，编辑提交信息在git commit时加上参数--amend可以合并上一个COMMIT提交内容，需要注意的是此时会生成一个新的COM...

2024年12月03日

276 阅读

0 评论

Git Workflow学习（四）

Git Workflow学习（四）

下面继续介绍分叉工作流（forking workflow）。原文见文后链接。分叉（Forking）工作流与其他流行的 Git 工作流有着根本的不同。它不是使用单个服务器端存储库作为“中央”代码库，而是为每个开发人员提供自己的服务器端存储库。这意味着每个贡献者不是一个，而是两个 Git 存储库：一个私有的本地存储库和一个公共服务器端存储库。分叉工作流最常见于公共开源项目中。分叉工作流的主要优点是可以集成贡献，而无需每个人都推送到单个中央存储库。开发者推送到自己的服务器端仓库，只有项目维护者才能推送到官方仓库。这允许维护者接受来自任何开发人员的提交，而无需授予他们对官方代码库的写入权限。分叉工作流通常遵循基于Gitflow工作流的分支模型。这意味着完整的功能分支将用于合并到原始项目维护者的存储库中。其结果是一个分布式工作流，为大型团队（包括不受信任的第三方）提供了一种灵活的方式来安全地进行协作。这也使其成为开源项目的理想工作流程。工作方式与其他Git工作流一样，分叉工作流从存储在服务器上的官方公共存储库开始。但是当新开发人员想要开始处理项目时，他们不会直接克隆官方存储库。取而代之的是...

2024年11月19日

179 阅读

0 评论

Git Workflow学习（二）

Git Workflow学习（二）

功能分支工作流背后的核心思想是，所有功能开发都应该在一个专用的分支中进行，而不是在main分支中进行。这种封装使多个开发人员可以轻松地在不干扰主代码库的情况下处理特定功能。这也意味着main分支永远不会包含损坏的代码，这对于持续集成环境来说是一个巨大的优势。封装功能开发还可以利用拉取请求（pull requests），这是围绕某个分支发起讨论的一种方式。它们让其他开发人员有机会在将功能集成到正式项目之前确认该功能。或者，如果你开发某个功能遇到困难，你可以打开一个拉取请求，向你的同事征求建议。关键是，拉取请求使您的团队可以非常轻松地对彼此的工作发表评论。Git 功能分支工作流是一个可组合的工作流，可由其他高级 Git 工作流利用。Git Feature Branch Workflow 以分支模型为中心，这意味着它是管理和创建分支的指导框架。其他工作流更侧重于存储库。Git 功能分支工作流可以合并到其他工作流中。Gitflow工作流和Git forking工作流传统上在其分支模型方面使用 Git 功能分支工作流。工作方式Feature Branch Workflow 假定一个中央存储...

2024年11月19日

174 阅读

0 评论

Git Workflow学习（一）

Git Workflow学习（一）

本文内容主要翻译自Atlassian公司的GIT Tutorial系列文章。A Git workflow is a recipe or recommendation for how to use Git to accomplish work in a consistent and productive manner.Git工作流是关于如何使用 Git 以一致且高效的方式完成工作的秘诀或建议。目前市面上有很多Git工作流，需要根据开发特点选择定制适合团队的Git工作流，从而保证研发协助的高效。什么是成功的Git工作流在评估团队的工作流程时，最重要的是考虑团队的文化。我们希望工作流程能够提高团队的效率，而不是成为限制生产力的负担。评估Git工作流时要考虑的一些事项包括：此工作流程是否随团队规模可扩展？使用此工作流程撤消失误和错误是否容易？此工作流程是否强加给团队任何不必要的认知开销？关于第一个问题，一般团队规模稳定的话，这个不是太大问题。关于第三个问题，我认为这是很重要的问题，可能会导致工作流无法在团队内部被采用。集中式工作流程集中式工作流是一个适合团队从集中式版本管理软件（比如SV...

2024年11月19日

217 阅读

0 评论

查看更多

MetMan博主

访问 100791 ℃

153 文章数

5 评论量

互动读者

标签云

最新回复

tqymnonccc打酱油
2024-09-27

怎么收藏这篇文章？
toibdpojay打酱油
2024-09-22

博主真是太厉害了！！！
yvctxyevvw打酱油
2024-09-22

博主真是太厉害了！！！
frezhwzwuq打酱油
2024-09-22

博主真是太厉害了！！！

繁

登录

X