blocks|key|4886094|text|我倾向于按照您的建议提交:提交是一个逻辑连接的更改集。我的提交可以是任何东西，从一行代码到所有文件中的更改(例如，在源文件中添加/更改版权声明)。改变的原因不一定是我正在实现的完整任务，但它通常是任务中的一个里程碑。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4886095|如果我修改了与当前提交无关的内容，我倾向于进行交互式添加，以分离出不相关的更改-即使是空格整理。|4886096|我发现，简单地将工作状态转储到存储库的提交会使它们变得不那么有用:如果提交到处都是，我就不能将错误修复移植到较早的版本，也不能在另一个分支中轻松地包含实用程序功能。|4886097|这种方法的一种替代方法是在功能分支中使用许多微小的提交，一旦整个功能完成，就进行繁重的历史重写，将提交整理到一个逻辑结构中。但我发现这种方法是浪费时间的。|4886098|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I tend to commit as you propose: a commit is a logically connected change set. My commits can be anything from a one-liner to a change in all files (for example add/change a copyright notice in the source files). The reason for change need not be a full task that I am implementing, but it is usually a milestone in the task.

If I have modified something that is not related to my current commit, I tend to do an interactive add to separate out the unrelated changes, too - even when it is a whitespace tidy up.

I have found that commits that simply dump the working state to repository makes them a lot less useful: I cannot backport a bugfix to an earlier version or include a utility functionality in another branch easily if the commits are all over the place.

One alternative to this approach is using a lot of tiny commits inside a feature branch, and once the whole feature is done, do heavy history rewriting to tidy up the commits into a logical structure. But I find this approach to be a time waster.

blocks|key|97140|text|这正是在git中引入了index+(临时区域)的用例。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|97141|您可以自由地做尽可能多的彼此无关的更改。然后选择所有相关的内容，然后一次完成多个原子提交。|97142|我一直在这么做。如果您使用git-gui或任何其他图形用户界面客户端，您不仅可以选择要提交的文件，还可以选择hunks+within+the+files，因此您的提交尽可能是原子的。|97143|entityMap|0|LINK|mutability|MUTABLE|url|http://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository^0|B|5|B|5|0|0|0|D|7|1I|M|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]]|D|@$9|U|A|V|1|W]]|E|$]]|$1|F|3|G|5|6|7|X|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|Y|8|@$9|Z|A|10|B|C]|$9|11|A|12|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|13|8|@]|D|@]|E|$]]]|K|$L|$5|M|N|O|E|$P|Q]]]]

This is exactly the use case, for which the <a href="http://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository" rel="nofollow noreferrer"><code>index</code></a>, the staging area, was introduced in git.

You can feel free to do as many changes unrelated to each other as possible. Then you choose what all are related and then make several atomic commits in one shot.

I do it all the time. If you use <code>git-gui</code> or any of the other GUI clients, you can choose not only the file that you want to commit, but also <code>hunks within the files</code>, so your commits are as atomic as possible.

blocks|key|4886229|text|我试着按顺序遵循这些练习……|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4886230|4886231|提交不能使构建失败。最重要的是！|ordered-list-item|4886232|它应该由一个逻辑更改单元组成-无论是单行/字符还是整个文件/类，并在代码的其他部分进行相应的更改，仍然遵循#1。|4886233|4886234|什么是更改的逻辑单元？在git方面，如果您可以在一句话(当然不包括and+)中用最少的字符数指定提交消息中的更改，并且您不能将该描述进一步拆分成更小的单元，我称之为一个单元。|offset|length|style|CODE|4886235|提交消息应该清楚地指定提交的本质。|unordered-list-item|4886236|
|4886237|提交消息应该很小，通常不超过80个字符。任何更多的细化都应该是description.|4886238|
的一部分|4886239|entityMap^0|0|0|0|0|0|C|3|0|0|0|V|B|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|10|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|11|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|12|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|14|8|@$K|15|L|16|M|N]]|9|@]|A|$]]|$1|O|3|P|5|Q|7|17|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|18|8|@]|9|@]|A|$]]|$1|T|3|U|5|Q|7|19|8|@$K|1A|L|1B|M|N]]|9|@]|A|$]]|$1|V|3|W|5|6|7|1C|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|Y|$]]

I try and follow these practices in the order...

<ol>
<li>A commit must not fail a build. Most important!</li>
<li>It should be made of one logical unit of change - whether a single line/character or a whole file/class with corresponding changes in other parts of code, still following #1.

What is a logical unit of change? In terms of <code>git</code>, if you can specify the changes in the commit message in least number of characters, in one sentence (without ANDs of-course), and you can not break that description further into smaller units, that I call one unit.</li>
<li>Commit message should clearly specify the essence of the commit.</li>
<li>Commit message should be small, typically no greater than 80 chars. Any more elaboration should be part of the <code>description</code>.</li>
</ol>

blocks|key|95531|text|将我们的存储库组织转移到由Git+Flow+extension推广的“功能分支”模型中，这在很大程度上帮助了我弄清楚我要提交的内容和原因。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|95532|通过让分支描述正在处理的每个功能(或更新、错误修复等)，提交变得更少关于功能，而更多地是关于如何实现该功能。例如，我最近在自己的bugfix分支中修复了一个时区bug+(例如bugfix/gh-87)，提交被分成了完成的部分，或者服务器端和前端，以及测试内部。因为所有这一切都发生在一个专门针对该bug的分支(with+a+GitHub+issue+number+too,+for+clarity+and+auto+closing)上，我的提交被视为解决该问题的增量步骤，因此需要更少的解释来解释我为什么要这样做。|95533|entityMap|0|LINK|mutability|MUTABLE|url|http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/|1|https://stackoverflow.com/questions/1687262/link-to-github-issue-number-with-commit-message^0|D|I|0|0|4B|1O|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@$A|U|B|V|1|W]]|C|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]]]

Something that very much helped me in working out what I was committing, and why, was moving our repository organisation over to the 'feature branch' model, as popularised by the <a href="http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/" rel="nofollow noreferrer">Git Flow extension</a>. 

By having branches describing each feature (or update, bugfix etc) that is being worked on, commits become less about the feature and more about how you are going about implementing that feature. For example, I was recently fixing a timezone bug within its own bugfix branch (bugfixes/gh-87 for example), and the commits were split up into what was done or the server side and the front end, and within the tests. Because all of this was happening on a branch dedicated to that bug, (<a href="https://stackoverflow.com/questions/1687262/link-to-github-issue-number-with-commit-message">with a GitHub issue number too, for clarity and auto closing</a>), my commits were seen as the incremental steps in solving that problem, and so required less explanation as to why I was doing them.

blocks|key|95537|text|有时，当您进行大型重构时，不可避免地会在一次提交中更改许多文件。当你改变一个类的接口时，你必须在一次提交中改变头部、实现和所有使用该接口的地方，因为没有中间状态可以工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|95538|然而，推荐的做法是在不引入任何新功能的情况下更改接口，首先测试您没有破坏现有功能并提交。而不是实现需要更新接口的实际功能，并单独提交。在使用交互式rebase进行第一次提交的过程中，您可能最终会对重构进行一些调整。|95539|这样就有了一个大的提交，但它不会做任何困难的事情，只是打乱代码，所以它应该很容易理解，即使它很大，而且比第二次提交(或者更多，如果功能很大)不是太大。|95540|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Sometimes when you do big refactoring, it's inevitable that you change many files in one commit. When you change interface of a class, you have to change the header, the implementation and all places that use the interface in one commit, because no intermediate state would work.

However, the recommended practice is to change the interface without actually introducing any new functionality first, test that you didn't break existing functionality and commit that. Than implement the actual feature that needed the updated interface and commit that separately. You will probably end up doing some adjustments to the refactoring in the process that you'll squash to the first commit using interactive rebase.

That way there is a big commit, but it does not do anything hard, just shuffles code around, so it should be mostly easy to understand even though it's big and than second commit (or more, if the feature is big) that is not too big.

blocks|key|4886355|text|免责声明:我也在试图弄清楚提交应该是什么，以及最终的历史应该是什么样子。然而，我想分享我在自己的研究过程中遇到的一些资源。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4886356|首先，Linux+Kernel项目在Merge+Strategies上有一个很棒的页面，可以让您的代码上游合并。他们谈到了进行一口大小的提交；在你想要的实际添加之前进行一个或多个重构提交(当然，重构应该是为了让你的功能更干净;)以及其他事情。|offset|length|4886357|我另一个最喜欢的页面是赛斯·罗伯逊写的Git+Best+Practices。这不仅是一个关于使用git的最佳实践的页面，而且也是一个巨大的资源，它包含了大量关于各种git主题的信息，使得googling搜索更深入的信息变得微不足道。|4886358|entityMap|0|LINK|mutability|MUTABLE|url|http://kernelnewbies.org/UpstreamMerge/MergingStrategy|1|http://sethrobertson.github.com/GitBestPractices/^0|0|I|G|0|0|J|I|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]|P|$5|K|L|M|A|$N|Q]]]]

Disclaimer: I too am in the process of trying to work out what commits should be, and how the final history should end up looking. However, I wanted to share some of the resources that I've come across during my own research.

First off, the Linux Kernel project has a great page on <a href="http://kernelnewbies.org/UpstreamMerge/MergingStrategy" rel="noreferrer">Merge Strategies</a> for getting your code merged upstream. They talk about making bite-sized commits; doing one or more refactoring commits before the actual additions you want (the refactorings are supposed to make your feature cleaner of course ;) and other things.

My other favorite page is <a href="http://sethrobertson.github.com/GitBestPractices/" rel="noreferrer">Git Best Practices</a> by Seth Robertson. This is not only a page on a lot of best practices for using git, but it also is a tremendous resource, containing enough information about a broad variety of git topics to make googling for more in-depth information trivial.

blocks|key|2773506|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2773507|我问的是哲学部分。|blockquote|2773508|2773509|2773510|我想我可以回答这个问题，因为我最近参与了一些个人研究。|2773511|人们应该专注于创建一个atomic+commit。这意味着在提交时需要格外注意一些事情：|offset|length|2773512|2773513|它不应该有任何值如果部分地完成了|unordered-list-item|2773514|它不应该破坏构建代码代码它应该包含一个良好的消息和正文来保证可追溯性(尽可能使用票证引用)|2773515|它不应该包含很多不同的噪声(空格和样式改变，除非提交是特定的)|2773516|<>F212>|2773517|提交应该集中在one+change,+and+one+change+only中。任何超过这一点的事情都会有不良的副作用。|2773518|有些人可能会认为这太多了，这是不实际的。但是支持它的最好的论点是，即使对于小公司来说，构建原子提交将迫使您的设计更加解耦和一致，因为实现完全最佳的原子提交的一个要求是拥有一个健康的、不混乱的代码库。|2773519|如果您一致地强制执行良好的提交实践，您将能够将工程文化和代码本身推向更好的状态。|style|BOLD|2773520|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/Atomic_commit|1|https://medium.com/@fagnerbrack/one-commit-one-change-3d10b10cebbf^0|0|0|0|0|0|B|D|0|0|0|0|0|0|0|7|V|1|0|0|0|14|0^^$0|@$1|2|3|-4|4|5|6|1D|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|1E|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|1F|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|1G|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|1H|7|@]|8|@]|9|$]]|$1|H|3|I|4|5|6|1I|7|@]|8|@$J|1J|K|1K|1|1L]]|9|$]]|$1|L|3|-4|4|5|6|1M|7|@]|8|@]|9|$]]|$1|M|3|N|4|O|6|1N|7|@]|8|@]|9|$]]|$1|P|3|Q|4|O|6|1O|7|@]|8|@]|9|$]]|$1|R|3|S|4|O|6|1P|7|@]|8|@]|9|$]]|$1|T|3|U|4|5|6|1Q|7|@]|8|@]|9|$]]|$1|V|3|W|4|5|6|1R|7|@]|8|@$J|1S|K|1T|1|1U]]|9|$]]|$1|X|3|Y|4|5|6|1V|7|@]|8|@]|9|$]]|$1|Z|3|10|4|5|6|1W|7|@$J|1X|K|1Y|11|12]]|8|@]|9|$]]|$1|13|3|-4|4|5|6|1Z|7|@]|8|@]|9|$]]]|14|$15|$4|16|17|18|9|$19|1A]]|1B|$4|16|17|18|9|$19|1C]]]]

<blockquote>
 What I am asking is the PHILOSOPHY part.
</blockquote>

I think I can answer this because I have been involved in some personal research recently.

One should focus in creating an <a href="https://en.wikipedia.org/wiki/Atomic_commit" rel="noreferrer">atomic commit</a>. Which means that it's necessary to take some extra care in a few things for a commit:

<ul>
<li>It shouldn't have any value if done partly</li>
<li>It shouldn't break the build</li>
<li>It should contain a good message and body for traceability (with tickets reference whenever possible)</li>
<li>It shouldn't contain a lot of diff noise (whitespace and style changes, unless the commit is specific for that)</li>
</ul>

Commits should be focused in <a href="https://medium.com/@fagnerbrack/one-commit-one-change-3d10b10cebbf" rel="noreferrer">one change, and one change only</a>. Anything more than that can have bad side-effects.

Some people might argue that this is too much, that it is not practical. But the best argument in favor of it, even for small companies, is the fact that bulding atomic commits will force your design to be more decoupled and consistent, because one requirement to achieve full optimal atomic commits is to have a healthy codebase that is not a mess.

If you force good commit practices consistently, you will be able to drive the engineering culture and the code itself to a better state.

I am using git to manage a C++ project. When I am working on the projects, I find it hard to organize the changes into commits when changing things that are related to many places. 

For example, I may change a class interface in a <code>.h</code> file, which will affect the corresponding <code>.cpp</code> file, and also other files using it. I am not sure whether it is reasonable to put all the stuff into one big commit.

Intuitively, I think the commits should be modular, each one of them corresponds to a functional update/change, so that the collaborators could pick things accordingly. But seems that sometimes it is inevitable to include lots of files and changes to make a functional change actually work.

Searching did not yield me any good suggestion or tips. Hence I wonder if anyone could give me some best practices when doing commits.

PS. I've been using git for a while and I know how to interactively add/rebase/split/amend/... What I am asking is the PHILOSOPHY part.

Update: Thanks for all the advices. Maybe this should be learned from practicing. I will keep the problem open for some time to see if there is more suggestions.

git commit best practices

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我正在使用git来管理一个C++项目。当我在项目中工作时，我发现当更改与许多地方相关的事情时，很难将更改组织到提交中。例如，我可能会更改.h文件中的类接口，这将影响相应的.cpp文件，也会影响使用它的其他文件。我不确定将所有东西放在一个大承诺中是否合理。直观地说，我认为提交应该是模块化的，每个提交都对应一个功能更新/更...

问git提交最佳实践
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问git提交最佳实践EN