From 6541679f7b9781e3fb0c4e5560cab4d10d21386b Mon Sep 17 00:00:00 2001
From: M81 <110393729+ZhangZhanhaoxiang@users.noreply.github.com>
Date: Fri, 20 Jan 2023 21:05:01 +0800
Subject: [PATCH] translated

---
 ...� 11 tips for writing a good Git commit message.md | 185 ------------------
 ...� 11 tips for writing a good Git commit message.md | 185 ++++++++++++++++++
 2 files changed, 185 insertions(+), 185 deletions(-)
 delete mode 100644 sources/tech/20221228.1 ���� 11 tips for writing a good Git commit message.md
 create mode 100644 translated/tech/20221228.1 ���� 11 tips for writing a good Git commit message.md

diff --git a/sources/tech/20221228.1 ���� 11 tips for writing a good Git commit message.md b/sources/tech/20221228.1 ���� 11 tips for writing a good Git commit message.md
deleted file mode 100644
index ae6acb59d1..0000000000
--- a/sources/tech/20221228.1 ���� 11 tips for writing a good Git commit message.md	
+++ /dev/null
@@ -1,185 +0,0 @@
-[#]: subject: "11 tips for writing a good Git commit message"
-[#]: via: "https://opensource.com/article/22/12/git-commit-message"
-[#]: author: "AmyJune Hineline https://opensource.com/users/amyjune"
-[#]: collector: "lkxed"
-[#]: translator: " "
-[#]: reviewer: " "
-[#]: publisher: " "
-[#]: url: " "
-
-11 tips for writing a good Git commit message
-======
-
-Lately, I have been paying closer attention to the changelogs I get from products and services when updates are needed. Here are some examples:
-
-- Fixed some bugs.
-- Made some accessibility improvements.
-- We've made improvements and fixed bugs for a smoother ride.
-
-When I think about some of the first commit messages I made as a junior developer I have to hang my head in dismay:
-
-- Pointed and clicked around a bit and now things seem to work.
-- Did what programmer X told me to do and now the banner is blue.
-
-This can be frustrating! I asked our community of contributors the following questions:
-
-- What makes a good Git commit message?
-- What makes a bad one?
-- What rules do you think a project should have around what a commit message contains?
-
-Here are their answers:
-
-### Great writing is key
-
-As with anything you write, you should think about who is going to read it. Then adapt the amount and depth of information accordingly.
-
-Improving your natural language and writing skills is essential for a healthy career in software development. It's not just code that counts.
-
-**—[Camilla Conte][1]**
-
-### Be descriptive and don't assume
-
-I spend a lot of my time collaborating in the [OpenStack][2] community, and its code reviewers have some fairly exacting standards compared to what I see from other projects "in the wild."
-
-I'll often spend far longer composing a solid commit message than I do writing the actual code implementation or fix. Sometimes commit messages can end up many times longer than the diffs they're explaining.
-
-To summarize some of the contributor guidance:
-
-- Describe why a change is being made, not just what is changing
-- The first commit line is the most important (like the subject line of an email)
-- Don't assume reviewers understand the original problem you're fixing
-- Don't assume the reviewer has access to external web services or the site (summarize defect reports and other relevant discussions)
-- Don't assume the code is self-evident and self-documenting (though there is no need to repeat points you also make in your code comments)
-- Don't include information only relevant to earlier revisions of the change (we expect contributors to squash revisions together and edit their commit messages accordingly).
-
-There's a brief section on the topic in the OpenStack Contributors Guide: [https://docs.openstack.org/contributors/common/git.html#commit-messages][3]
-
-**—[Jeremy Stanley][4]**
-
-### Your future self will thank you
-
-I cannot agree more with Jeremy. +1000
-
-Jeremy said, "describe why a change is being made, not just what's changing."
-
-Imagine you're someone else, in a faraway future, trying to work out this commit.
-
-Put yourself in other people's shoes, as the old saying goes.
-
-**—[Leigh Morresi][5]**
-
-### Use the bug ID
-
-I recommend adding the bug ID at the start of the commit message so that it's easier to track the commits at a later stage using the [`grep` command][6].
-
-For example:
-
-```
-$ git commit -m "BZ#19xxxxx
-```
-
-To come up with thoughtful commits, consider the following:
-
-- Why have I made these changes?
-- What effect have my changes made?
-- Why was the change needed?
-- What are the changes in reference to?
-
-**—[Agil Antony][7]**
-
-### Tell the whole story
-
-I like to imagine there is a hidden prefix to every commit message that reads "By applying this."
-
-A good commit message includes exactly what will happen and why. It is insufficient to merely have the work ticket reference because that decentralizes the information; Git is decentralized. As a software developer, I want to know why the proposed changes are being considered. What specific problem is being addressed? What alternate solutions were considered (and discarded)? What unexpected things were discovered during the creation of the changeset that influenced the current content?
-
-There's no prize for shortest commit message. Your future self and future colleagues will appreciate you going into depth to explain the problem and why this changeset is the answer. Harness those cooking blogs where there's a five-paragraph life story. Here, however, make the problem the subject of the life story.
-
-**—[Lisa Seelye][8]**
-
-### But don't be overly verbose
-
-A good git commit message contains information about what was done, and nothing else. For instance, if you needed to update the .gitignore, just say "updated .gitignore." Folks can dive into the commit itself for more details. It doesn't need to be verbose.
-
-A bad commit message is something like, "oh crap" or "try this". Granted, I've been guilty of this, but it doesn't help anyone if they need to look at commits at a glance.
-
-Rules are very subjective. They can differ from lead to lead and team to team. But at the very least, give some contextual information about the commit. Especially if it's a large one. No one has time to skim through 1000+ files with a heavy change history.
-
-**—[Miriam Goldman][9]**
-
-### Use present tense
-
-I like project manager-styled commit messages written in present and not future terms (for example, "add" instead of "added"). However, it's usually only possible if commits are frequent. There's only so much "how did I do it" you can remember when you're faced with a deadline. Yet, well-written commits not only help collaborators, but are also helpful to the committer in recollecting history.
-
-**—[Chris Okpada][10]**
-
-### Don't rely on links
-
-One thing I like to remind colleagues of is that you're not just explaining to the people who are going to decide whether to approve your commit. You're also explaining to future developers and users who have found this commit in a bisect or blame operation and are trying to understand its relevance.
-
-If the only context supplied is a link to some external system, and that far in the future the system it links to is no longer in use or has otherwise become inaccessible to that individual, your commit message has been rendered useless and may just as well be blank.
-
-All too often, I go digging in the Git history of some open source project, and find commit messages which are nothing more than a bug ID or a link to some company's internal and private defect tracker.
-
-Don't be that project!
-
-**—[Jeremy Stanley][4]**
-
-### Clear and concise changelogs
-
-As a release communications manager, I often read the entire release board. I also met with developers to discuss any areas that weren't clear yet. Then I tested the release early. After that, I would write a release post by sourcing the changelogs and corresponding revised or new content.
-
-The changelogs are personal reminders for developers, but also have corresponding issues and tickets for them. You should capitalize product names appropriately, use a spell checker, be consistent with punctuation, and sentence structure. The lead developer should proofread these as well. Your customers, that are developers, are reading these. What information should they know before running the update to better serve their customers?
-
-**—[Courtney Robertson][11]**
-
-### Be specific
-
-As a frequent release manager, I like messages that name the component a commit touches, and a brief description of what was changed. Also having a reference back to where the request for this work came from helps to tie fixes together long after we forgot about your clever branch name.
-
-- "fix fatal error" is not ideal.
-- "ISS-304: Fix fatal error in Login Access Control function for users
-	with the Partner role" is better.
-- "ISS-304: Login Access Control: fix fatal error in getPartnerId()" is
-	better still.
-
-I can look at the entire relationship between a Git commit, branch, merge commit, and inspect the individual lines and files that were changed. But I don't have that kind of time in the middle of a release. I want to be able to relate back to the source of this work in the project management tool, have some idea of which components are being changed, and in what way.
-
-**—[Ryan Price][12]**
-
-### Make it a habit
-
-My favorite commit that I'm guilty of is, "commit before I switch branches" because I have to work on something else more urgent. Sometimes, I need to commit my current work to a totally different project. My manager's strategy is to have us work as we normally do. But then when we rebase, he wants us to squash commits where it makes sense and write better messages. I can't say we always do this, but his method does make sense.
-
-I have a lot of "this is broken don't know why" type messages too (haha) where I try things but want to commit that attempt before I try something else in case method A was closer to fixing the issue than method B. Writing code is a hot mess. And I've been writing it for over 10 years.
-
-**—[RachieVee][13]**
-
-What commit message advice or tips do you live by? Let us know in the comments.
-
---------------------------------------------------------------------------------
-
-via: https://opensource.com/article/22/12/git-commit-message
-
-作者：[AmyJune Hineline][a]
-选题：[lkxed][b]
-译者：[译者ID](https://github.com/译者ID)
-校对：[校对者ID](https://github.com/校对者ID)
-
-本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) �誉推出
-
-[a]: https://opensource.com/users/amyjune
-[b]: https://github.com/lkxed
-[1]: https://opensource.com/users/spotlesstofu
-[2]: https://opensource.com/resources/what-is-openstack
-[3]: https://docs.openstack.org/contributors/common/git.html#commit-messages
-[4]: https://opensource.com/users/fungi
-[5]: https://opensource.com/users/dgtlmoon
-[6]: https://opensource.com/downloads/grep-cheat-sheet
-[7]: https://opensource.com/users/agantony
-[8]: https://opensource.com/users/lisa
-[9]: https://opensource.com/users/miriamgoldman
-[10]: https://opensource.com/users/ojchris
-[11]: https://opensource.com/users/courtneyrdev
-[12]: https://opensource.com/users/liberatr
-[13]: https://opensource.com/users/rachievee
diff --git a/translated/tech/20221228.1 ���� 11 tips for writing a good Git commit message.md b/translated/tech/20221228.1 ���� 11 tips for writing a good Git commit message.md
new file mode 100644
index 0000000000..f78aab08dc
--- /dev/null
+++ b/translated/tech/20221228.1 ���� 11 tips for writing a good Git commit message.md	
@@ -0,0 +1,185 @@
+[#]: subject: "11 tips for writing a good Git commit message"
+[#]: via: "https://opensource.com/article/22/12/git-commit-message"
+[#]: author: "AmyJune Hineline https://opensource.com/users/amyjune"
+[#]: collector: "lkxed"
+[#]: translator: "ZhangZhanhaoxiang"
+[#]: reviewer: " "
+[#]: publisher: " "
+[#]: url: " "
+
+编写好 Git �交消�的 11 个技巧
+======
+
+最近，当需�更新时，我一直在密切关注从产�和�务获得的�更日志。以下是一些示例：
+
+- 修�了一些错误。
+- 进行了一些�访问性改进。
+- 我们已�进行了改进并修�了错误，以实现更顺畅地�行。
+
+当我想到我作为一��级开�人员�出的一些最�的承诺信�时，我�得�沮丧地垂下头：
+
+- 用鼠标点了一下，现在一切似乎都正常了。
+- 执行了程�员 X 告诉我的�作，现在横幅是�色的。
+
+这�能令人沮丧�我�我们的贡献者群体�出了以下问题：
+
+- 什么是好的 Git �交消�？
+- 什么是�的 Git �交消�？
+- 你认为一个项目应该有哪些关于�交消�所写内容的规则？
+
+以下是他们的答案：
+
+### 易阅读的文笔是关键
+
+与你写任何东西一样，你应该考虑�会阅读它。然�相应地调整信�的数�和深度。
+
+�高你的自然语言和写作技能对于软件开�的顺利�业生涯至关��。��的�仅仅是代�。
+
+**—[Camilla Conte][1]**
+
+### 具有�述性，���设
+
+我花了很多时间在 OpenStack[2] 社区中进行�作，与我在�“野外�一样��的其他项目中看到的相比，它的代�审查员有一些相当严格的标准。
+
+我撰写一���的�交消�的时间通常�比编写实际的代�实现或修�程�的时间长得多。有时，�交消�所需的时间�能会比它们解释的差异长很多�。
+
+总结一些贡献者指导：
+
+- �述为什么��出改�，而�仅仅是改�了什么
+- 第一个�交行是最��的（就�电�邮件的主题行）
+- ��自认为审查人员了解你正在修�的原始问题
+- ��自认为审查者�以访问外部 web �务或网站（总结缺陷报告和其他相关讨论）
+- ���设代�是�言自明的和自我记录的（尽管没有必���您在代�注释中也�出的观点）
+- ���包�与更改的早期修订相关的信�（我们希望贡献者将修订压缩在一起，并相应地编辑其�交消�）。
+
+《OpenStack 贡献者指�》中有一个关于该主题的简短章节：[https://docs.openstack.org/contributors/common/git.html#commit-messages][3]
+
+**—[Jeremy Stanley][4]**
+
+### 你未�的自己会感谢你
+
+我�常���里米的观点。1000 份地支�。
+
+Jeremy 说：“�述为什么��出改�，而�仅仅是改�了什么。�
+
+想象一下，你是�观者，在�远的未�，试图�解这个�交。
+
+正如��所说，设身处地为他人�想。
+
+**—[Leigh Morresi][5]**
+
+### 使用 bug 的 ID
+
+我建议在�交消�的开头添加 bug ID，以便��使用 [`grep` 命令][6] 更容易跟踪�交。
+
+例如：
+
+```
+$ git commit -m "BZ#19xxxxx
+```
+
+�写出深�熟虑的�交，请考虑以下事项：
+
+- 我为什么��这些更改？
+- 我的更改产生了什么影�？
+- 为什么有更改的必�？
+- 更改的��是什么？
+
+**—[Agil Antony][7]**
+
+### 讲述整个故事
+
+我喜欢想象�个�交消�都有一个��的�缀，上�写�“By applying this（通过应用这个）�。
+
+一个好的�交消�包括将��生的事情以�原因。仅仅有工作任务清�作�考是�够的，因为这分散了信�；Git 是去中心化的。作为一�软件开�人员，我想知�为什么当��考虑�出更改。正在解决的具体问题是什么？考虑（并放弃）了哪些替代解决方案？在创建�更集的过程中�现了哪些影�当�内容的�外情况？
+
+缩短�交消�没有什么用。你未�的自己和未�的�事会感激你深入解释问题，以�为什么这个�更集是解决方案。认真学习和利用那些有丰富“生活�验�的“烹饪��客。然而，在此，仅仅是把生活�验替��了项目的问题罢了（LCTT 译注：��是�认真学习和模仿优秀�详细的 commit）。
+
+**—[Lisa Seelye][8]**
+
+### 但��过于冗长
+
+一个好的 git �交消�包�有关所��作的信�，而��包�其他信�。例如，如果您需�更新.gitignore，�需写“updated .gitignore���。人们�以自行深入到�交本身中了解更多细节。它�需�冗长。
+
+令人�感的�交消�类似于“哦，废��或“试试这个�。当然，我对此感到内疚，但这对于任何需�看一眼�交的人�说都没有任何帮助。
+
+�交信�的规则�常主观。他们�能因领导和团队而异。但至少��供一些有关�交的上下文信�。特别是如果它是一个大的更改。没有人有时间�览 1000 多个具有�大更改历�的文件。
+
+**—[Miriam Goldman][9]**
+
+### 使用现在时
+
+我喜欢用现在时而�是将�时的术语编写项目��风格的�交消�（例如，“add�而�是“added�）。然而，这通常�有在频��交时�有�能。当你�临最�期�时，你能记�的�有“我是如何�的�而已。然而，写得好的�交�仅有助于�作者，而且有助于�交者回忆历�。
+
+**—[Chris Okpada][10]**
+
+### ���赖链接
+
+我想�醒�事的一件事是，你�仅仅是�给你的�交作批准的人解释。你还将�未�的开�人员和用户解释，他们会�现这�交有利有弊，或者指责�作，并试图了解其相关性。
+
+如果�供的唯一的上下文是指��个外部系统的链接，并且在未�很长一段时间内，它所链接的系统��使用，或者该用户无法访问，那么您的�交消�将�得无用，也相当于是空白的。
+
+我�常去挖掘一些开�项目的 Git 历�，�现有些�交消�无�就是一个 bug ID，或者是�个公�内部的和专用缺陷跟踪器的链接。
+
+���赖链接�
+
+**—[Jeremy Stanley][4]**
+
+### 清晰简�的�更日志
+
+作为一��行沟通��，我�常阅读整个�行版。我还与开�人员会�，讨论任何尚未明确的领域。然�我很早就测试了这个版本。之�，我将通过寻找�更日志和相应的修订或新内容�撰写�布帖�。
+
+�更日志是开�人员的个人�醒，但也有相应的�议和问题。您应该适当地将产��称大写，使用拼写检查器，与标点符�和��结构��一致。首席开�人员也应该校对这些。您的客户，�开�人员，正在阅读这些内容。在�行更新之�，他们应该了解哪些信�能更好地为客户�务？
+
+**—[Courtney Robertson][11]**
+
+### 具体一点
+
+作为一个频��布的管�者，我喜欢将组件命�为�交的消�，以�对更改内容的简��述。在我们忘记了你�明的分支�称之�，还�以�考一下这项工作的请求�自何处，这有助于将修�程��系在一起。
+
+- “fix fatal error�并�是�想的�交。
+
+- “ISS-304: Fix fatal error in Login Access Control function for users with the Partner role�更好。
+
+- “ISS-304: Login Access Control: fix fatal error in getPartnerId()�也是更好。
+
+我�以查看 Git �交�分支��并�交之间的整个关系，并检查更改的�个行和文件。但我在�布过程中没有这样的时间。我希望能够回到项目管�工具中这项工作的��，了解哪些组件正在被更改，以�以何�方�进行更改。
+
+**—[Ryan Price][12]**
+
+### 让它�为一�习惯
+
+我最喜欢犯的错误是“在我切�分支之��交�，因为我必须处�其他更紧急的事情。有时候，我需�把我目�的工作�交给一个完全��的项目。我的��的策略是让我们�平时一样工作。但当我们�新�动时，他希望我们在有�义的地方压缩�交，并编写更好的消�。我�能说我们总是这样�，但他的方法确实有��。
+
+我也有很多“这是�的，�知�为什么�类型的消�（哈哈），我�试了一些东西，但想在�试其他东西之��交该�试，以防方法 A 比方法 B 更接近解决问题。我已�写了 10 多年了。
+
+**—[RachieVee][13]**
+
+你生活中的�交信�建议或�示是什么？让我们在评论中知�。
+
+--------------------------------------------------------------------------------
+
+via: https://opensource.com/article/22/12/git-commit-message
+
+作者：[AmyJune Hineline][a]
+选题：[lkxed][b]
+译者：[ZhangZhanhaoxiang](https://github.com/ZhangZhanhaoxiang)
+校对：[校对者ID](https://github.com/校对者ID)
+
+本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) �誉推出
+
+[a]: https://opensource.com/users/amyjune
+[b]: https://github.com/lkxed
+[1]: https://opensource.com/users/spotlesstofu
+[2]: https://opensource.com/resources/what-is-openstack
+[3]: https://docs.openstack.org/contributors/common/git.html#commit-messages
+[4]: https://opensource.com/users/fungi
+[5]: https://opensource.com/users/dgtlmoon
+[6]: https://opensource.com/downloads/grep-cheat-sheet
+[7]: https://opensource.com/users/agantony
+[8]: https://opensource.com/users/lisa
+[9]: https://opensource.com/users/miriamgoldman
+[10]: https://opensource.com/users/ojchris
+[11]: https://opensource.com/users/courtneyrdev
+[12]: https://opensource.com/users/liberatr
+[13]: https://opensource.com/users/rachievee