美丽寮步网站建设极致发烧,如何把qq音乐导入到wordpress,网络营销方式对比分析论文,做外贸网站渠道为什么我们应该关心编写干净的提交消息#xff1f; 提交是程序员技术的有形构建块。它们充当代码的锦上添花#xff0c;如果编写正确#xff0c;它们会带来巨大的价值。编写良好的提交消息变得不可或缺#xff0c;因为它们提供了上下文——否则一开始就不需要提交消息。 良… 为什么我们应该关心编写干净的提交消息 提交是程序员技术的有形构建块。它们充当代码的锦上添花如果编写正确它们会带来巨大的价值。编写良好的提交消息变得不可或缺因为它们提供了上下文——否则一开始就不需要提交消息。 良好的提交表明开发人员是否是良好的合作者 - Peter HuttererLinux。 开发人员中的一个常见错误是将 Git 存储库视为备份系统。随机承诺捕获代码的当前状态可能会妨碍您在将来检查代码库时理解过去更改的能力。提交诸如“WIP”、“吃午餐”、“今天代码结束”、“我累了 AF”、“团队周末快乐”和“首先提交”之类的消息只会让你的 Git 日志变得混乱让你的工作变得困难。了解您所做的重要承诺因为这些消息都不包含任何附加价值。 以下是尝试提交到远程存储库时要避免的一些关键错误 切勿分别对不同文件提交更改 在查看提交历史记录或与其他团队成员协作时单独提交对不同文件的更改可能会导致出现问题。理解变化的完整背景及其相互关系变得具有挑战性。 例如我正在建立一个网上商店。我不应该做的是 # Committing changes to header.js separately
git add header.js
git commit -m Improve header layout# Committing changes to footer.js separately
git add footer.js
git commit -m Optimize footer design 查看您的 Git 日志这种提交结构可能会变得混乱尤其是随着您的提交历史记录的增长。 提交应该清晰、简洁并组织成逻辑单元。例如完成代码的布局部分并处理页眉和页脚部分后在提交这些更改之前完成这些更改后合并这些更改会更清晰 # Staging changes to both header.js and footer.js
git add header.js footer.js# Committing related changes together
git commit -m Enhance UI: Header and Footer Improvements 我知道这在理论上听起来可能比在实践中容易。这就是为什么在通过压缩将这些更改合并到主分支之前维护一个专门用于提交的私有分支是一个很好的做法。 为私有提交创建专用分支 提交代码并不一定意味着它必须成为无尽的 git 日志中的永久固定装置。将私人分支机构视为您个人程序员的画板 - 您可以自由地进行实验而不必担心其他人审查您的工作。 想象一下场景您正在编码需要暂时离开一下或者您可能要去吃晚饭。对失去当前进度的恐惧促使您提交更改 - 私人分支机构的完美用例。无论您是要结束当天的编码会议还是只是想进行自发的提交这些更改都可以在您的私人分支中找到它们的家。 commit [commit-hash]
Author: Your Name your.emailexample.com
Date: [Timestamp]WIPcommit [commit-hash]
Author: Your Name your.emailexample.com
Date: [Timestamp]commiting before i eventually lose my filescommit [commit-hash]
Author: Your Name your.emailexample.com
Date: [Timestamp]about to go for dinnercommit [commit-hash]
Author: Your Name your.emailexample.com
Date: [Timestamp]toilet time! 在协作环境中使私有分支的命名显而易见非常重要。因为您不能让此类提交消息出现在您的公共分支中。 无论是通过明确的分支命名还是与队友直接沟通都要明确表明该分支的内容并不旨在作为正在进行的工作的基础。私有分支的一个好命名可以是“private/do-not-use-this” 成为公共分支一部分的每个提交都必须体现一个精心设计、独立、可逆且描述良好的工作单元。 案例研究开发在线商店的购物车功能 让我们看一下我们一直在开发的在线商店项目。在这种情况下您作为前端开发人员负责向商店添加购物车功能。您的旅程将按如下方式展开 您通过增强购物车部分的 CSS 呈现方式开始了努力并做出了相应的提交。随着您的进步您向购物车引入了 JavaScript 功能从而导致了另一次提交。在追求完美的过程中您注意到文本对齐问题并投入时间来完善 CSS然后进行了额外的提交。 继续您的工作您发现并解决了与将产品添加到购物车时计数器行为相关的错误。这个快速修复也在提交中得到了体现。最后您试图通过在单击结帐按钮时合并加载动画来提升用户体验并以结论性提交作为结束。 现在我们看一下git日志 commit [commit-hash-1]
Author: Your Name your.emailexample.com
Date: [Timestamp]Enhance CSS presentation of cart sectioncommit [commit-hash-2]
Author: Your Name your.emailexample.com
Date: [Timestamp]Introduce Javascript functionality to cartcommit [commit-hash-3]
Author: Your Name your.emailexample.com
Date: [Timestamp]Refine CSS to resolve text alignment issuecommit [commit-hash-4]
Author: Your Name your.emailexample.com
Date: [Timestamp]Fix counter bug related to cart behaviorcommit [commit-hash-5]
Author: Your Name your.emailexample.com
Date: [Timestamp]Incorporate loading animation for checkout button 如果这些更改需要与与在线商店相关的其他提交一起纳入主要功能分支则审核过程可能会变得具有挑战性。 这是修复这些提交日志的方法 首先切换到您的功能分支 # Checkout the feature branch named feature/cart-section
git checkout feature/cart-section 然后将分支中的所有提交压缩private/do-not-use-this为feature/cart-section使用单个提交消息 # Merge and squash all commits from the private branch to the feature branch using a single commit
git merge - squash private/do-not-use-this 合并和压缩后您需要制作一条清晰且描述性的提交消息 编写完美提交消息的 7 个标准规则 这些规则提供了指南和最佳实践以确保您的提交消息格式正确并传达清晰的信息。虽然具体规则可能因不同来源而异但总体目标是增强 Git 版本控制系统内提交消息的可读性和可理解性。 规则 1限制为 50 个字符最多。 在设计提交消息的主题行时建议保持简洁和重点突出。主题行用作提交目的的快速摘要理想情况下应限制为最多 50 个字符。 难以满足 50 个字符的限制可能表明提交的意图不够明确。提交消息应该清晰、简洁并且能够独立存在。通过遵守此字符限制您将被迫优先考虑最关键的信息从而使您的团队和未来的您更容易一目了然地了解变更的性质。 规则 2仅将主题行的第一个字母大写。 撰写提交消息时请使用标题大小写将主题行的第一个字母大写就像编写简洁的句子一样。将消息的其余部分包括任何其他详细信息保留为小写。 规则 3不要在主题行末尾添加句号 主题行不以句点结束的原因部分是历史原因部分是为了保持一致的风格。惯例是将主题行视为标题或命令这就是为什么它以祈使语气编写例如“添加功能”或“修复错误”而不是“添加功能”或“修复错误”。省略末尾的句号有助于强化这一惯例并保持主题行简洁。 git commit -v -m Create the Cart Feature with a Nice Animation规则 4在主题行和正文之间放置一个空行 虽然该指南可能看起来不寻常但它植根于实用性。许多开发人员使用 Git 命令行界面但该界面通常缺乏自动换行功能。因此引入了有意的格式化规则以确保一致且清晰的提交消息。 git commit -v -m Create the Cart Feature with a Nice AnimationBody...规则 5提交正文在 72 个字符处换行 需要澄清的是遵守本指南并不涉及传统的自动换行而是涉及传统的自动换行。相反这种做法是因为考虑到命令行用户可能会遇到超过 72 个字符的截断提交正文。 大多数时候您的消息长度会超过 72 个字符。在这种情况下建议中断文本并在下一行继续您的句子如下面的提交消息所示 git commit -v -m Create the Cart Feature with a Nice AnimationEnhanced the CSS layout of the cart section, addressing text
alignment issues and refining the layout for improved aesthetics
and readability. 总之表示要点的标准做法是使用连字符或星号后跟一个空格。此外保持悬挂缩进以提高组织清晰度也很重要。 规则 6使用祈使语气 一个有价值的实践涉及在编写提交消息时具有基本的理解即提交在实施时将实现精确的操作。以逻辑上完成句子“如果应用此提交将......”的方式构建提交消息。例如不要git commit -m Fixed the bug on the layout page使用 ❌而是使用这个git commit -m Fix the bug on the layout page✔ 换句话说如果应用此提交确实可以修复布局页面上的错误。 规则 7解释“什么”和“为什么”但不解释“如何”。 将提交消息限制为“内容”和“原因”可以为每个更改创建简洁而信息丰富的解释。寻求“如何”实现代码的开发人员可以直接参考代码库。相反突出显示更改的内容以及更改的理由包括受影响的组件或区域。 案例研究Angular 的提交消息实践 Angular 是有效提交消息传递实践的一个突出例证。Angular 团队提倡在制作提交消息时使用特定的前缀。这些前缀包括“chore:”、“docs:”、“style:”、“feat:”、“fix:”、“refactor:”和“test:”。通过合并这些前缀提交历史记录成为了解每次提交性质的宝贵资源。 提示 请记住通过提交消息优先考虑清晰且有意义的沟通。精心设计的提交消息就像一个故事解释“什么”、“为什么”但不解释“如何”进行更改。请记住您的提交历史记录是您和您的团队未来将依赖的协作资源。养成创建内容丰富、简洁且一致的提交消息的习惯。
