git 提交频率答案

【问题标题】：git commit frequencygit 提交频率
【发布时间】：2010-11-05 14:31:15
【问题描述】：

自从我从 svn 切换到 git 后，我开始在每次重新编译并且测试通过时进行更多提交，我提交了我的工作。最后我最终逐个提交函数。

我还使用 git 跟踪其他一些项目，例如 emacs、wordpress 等。我发现他们不经常提交。所以我想知道你多久提交一次？

【问题讨论】：

【解决方案1】：

Git 项目本身（以及 Linux 项目 AFAIK）的指导方针是每个“逻辑上独立的变更集”提交一次。

这有点模棱两可，但如果您一直在处理一个项目，您可能不想每隔几天提交一次，并且您可能不想在每个函数之后提交更改 - 如果您在多个不同文件中编辑了多个函数，您希望尽可能将所有相关功能一起提交，并提供有用的提交消息。每次提交中修改的所有代码都应该是相关的，但它可以（并且可能应该）跨多个文件。

您可能要记住的是代码审查。如果有人试图决定他们是否应该合并您的工作，如果您将每个提交逻辑包含并彼此分开，那么他们处理所引入的工作会容易得多。这可以让你（或其他人）有效地挑选工作——如果你有三个提交，每个提交修改了一个函数，但它们都以某种方式耦合——你不能在不破坏代码库的情况下应用一个而没有另外两个——那么它们可能应该被压缩到一个提交。

【讨论】：

Als 您希望每个提交的版本都能正常工作（这有助于平分查找错误）。
如果您拥有该项目，请随时提交。如果您正在编辑其他人的项目，请在补丁完成后提交
代码审查的要点，如果有人查看提交，他们应该查看单个决定或更改，该更改可以在一个或多个文件中，但它们由单个相关功能或改进。

【解决方案2】：

我还使用 git 跟踪其他一些项目，例如 emacs、wordpress 等。我发现他们不经常提交。

关于 git 的好处之一是您可以随意提交，然后当您想要进行上游提交时，您可以使用 git-rebase 将几个相关的提交压缩到一个干净的提交中。

【讨论】：

应该注意，git rebase 虽然很棒，但如果你不小心的话，它是一个非常危险的工具。
@baudtack：一点也不。 Rebase 不受惩罚，如果你完全搞砸了，只需使用 git reflog 和 git reset 回到原来的位置！
@baudtack 你的陈述有什么论据吗？（我不使用它，但为了别人而好奇）。
git rebase 一点也不危险。如果您在执行 rebase 之前想要一个简单的安全网，请使用 git branch branchname.bck 创建当前 HEAD 的备份分支。如果您对 rebase 不满意，请使用 git reset --hard branchname.bck 返回之前的状态。如果您想返回重新定位的版本，重新定位的提交仍然存在，但由于它们存储为未引用的对象，您需要git reflog 或git fsck --no-reflogs 才能找到正确的 sha1 值。
拜托，让我们都停止“变基非常危险”的模因。危险的？不，几乎是魔法？是的！不同的共享历史是一种痛苦，是的。但是应该鼓励重新定位自己的分支以明确提交！例如jeffkreeftmeijer.com/2010/the-magical-and-not-harmful-rebase

【解决方案3】：

最后我最终逐个提交函数

别忘了你可以一个接一个地“git add”，只提交一次：

为给定任务编写或修复所有函数后
或者一旦您意识到当前函数太大/太复杂而不能很快成为提交的一部分：然后您可以提交当前“在舞台上”（“git added”）的内容，其中不包括您当前的修改在工作目录中。

那么，提交的次数可以与分支的目的相关：

本地分支：发疯，随时提交
“公共”分支（您将推送的分支）：
- 对于本地存储库（针对选定的人群）：您至少可以重新组合非常小的“中间”提交
- 对于公共存储库（供所有开发人员或其他项目查看）：您可以进行交互式变基，以便按“活动”或“任务”重新组合您的提交，以提高可读性。

简而言之，在 DVCS（如“分布式”中）中，“发布考虑”可以指导您为正确的理由。

【讨论】：

【解决方案4】：

您提交的越多，使用git bisect 查找错误就越容易

【讨论】：

只要提交所有编译和现有测试通过。
@MariusK 是的，我有点假设您没有将完全损坏的代码提交到规范分支。

【解决方案5】：

一旦测试通过，或者当一个功能单元被添加/删除/修改时。

【讨论】：

【解决方案6】：

这真的取决于。

我所做的是我经常在本地提交，就像你正在做的那样，但我只在积累了几个有影响力的更改后才推送我的更改。

这可以确保我保存我的工作，但它也不会让其他用户的 repo 变得混乱。

【讨论】：

嗯，你可以经常运行“git add”来保存你的工作，但只有在功能完成时才提交。
但是如果你不提交那些本地更改，你就不能回去查看你自己的工作。

【解决方案7】：

我们的业务需求让我们在程序编译的时候提交到不稳定的分支，当它通过单元测试并且已经被客户审查时提交到稳定的分支（当它在不稳定的分支下时）。

【讨论】：

【解决方案8】：

我在添加或更改功能并成功测试后提交。或者当我要从台式机切换到笔记本电脑并想要下载代码时，我会提交并推送。

【讨论】：

【解决方案9】：

你正在做的事情对我来说听起来很正确。任何时候你有一个工作设置，如果你把事情搞砸了，你希望能够回到这个位置，这是一个提交的好时机。如果您有一个很好的设置，可以快速轻松地运行回归测试，我可以看到这种情况相当频繁。对我来说，我很幸运能每周制作一个。

【讨论】：

【解决方案10】：

1- 提交应该频繁；应经常将代码提交到远程存储库（不仅仅是本地），以便备份代码以防万一丢失；这种情况发生的频率比您预期的要高，因此必须在一天结束前推送您的更改，以避免潜在的返工并确保远程存储库始终是最新的。

2- 提交应该是细粒度的，因此不应包括对代码库的太多更改。更改过多的提交更难恢复，并且不能从“历史”的角度用作参考，因为提交消息必须太长才能涵盖全部范围。

3- 提交应该有一个适当的标题；标题应以大写字母开头，不应以句点结尾。一般来说，标题应该简短而中肯。

4- 提交描述是可选的，但很好。

【讨论】：

【解决方案11】：

我的承诺相距甚远。 git 并不是要“备份”您的代码，您应该使用 tarball 或 Dropbox 或其他东西来确保您不会丢失代码。

如果您不经常提交，您可以更好地准确判断应该在什么提交中进行，并且它为您提供比 50 次提交更流畅的历史记录

“糟糕”、“该死”、“忘记了那个文件”

你可以变基，但如果你从不暂存/提交，就没有必要撤消你的工作

【讨论】：

我认为这是一种反模式。经常在本地提交早期提交，然后在向上游推送之前压缩。你不想失去你的工作。备份是针对硬件故障的，git 是以一种可以轻松审核和恢复的方式保存您所做的每一个逻辑更改。