logo标签列表

Git提交频率

gitversion-controlcommit
55

自从我从svn转换到git后，每次我重新编译并且测试通过时，我都会提交我的工作。最终，我会逐个函数地进行提交。

我也使用git来跟踪其他项目，如emacs、wordpress等。我发现他们不那么频繁地提交。所以我想知道你们提交的频率是多少？

11个回答
64

Git项目本身（以及Linux项目，据我所知）的指导方针是每个“逻辑上分离的更改集”提交一次。

这有点模糊，但如果您在不断地进行项目工作，您可能不想每隔几天提交一次，可能 您也不想在每次函数更改后提交 - 如果您在多个文件中编辑了多个函数，则希望一起提交所有相关功能（如果可以的话）并提供有用的提交消息。每个提交中修改的所有代码都应该相关，但肯定可以（并且可能应该）跨越多个文件。

您可能要记住的是在代码审查中。如果有人正在尝试决定是否合并您的工作，如果您的每次提交都是逻辑上包含和相互分离的，那么他们处理引入的工作就会容易得多。这使您（或其他人）能够有效地挑选工作 - 如果您有三个提交，其中每个提交都修改了一个函数，但它们都以某种方式耦合在一起 - 您不能只应用其中一个而不另外两个而不破坏代码库- 那么它们可能应该被压缩成一个提交。

11
您希望每个提交版本都能够正确运行（这有助于二分查找找到错误）。 - Jakub Narębski
3
如果你拥有这个项目，就在你觉得合适的时候提交。 如果你正在编辑别人的项目，就在补丁完成后再提交。 - Tyler Gillies
代码审查方面的观点非常好，如果有人查看提交记录，他们应该只关注一个决策或更改，这个更改可以在一个或多个文件中，但它们都与单个功能或改进相关。 - ChristoKiwi
26

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

Git的一个好处就是你可以随时提交，然后当你想要做上游提交时，你可以使用git-rebase将几个相关的提交合并成一个干净漂亮的提交。

22
需要注意的是，尽管非常强大，但如果不小心使用，git rebase 是一个非常危险的工具。 - baudtack
4
完全没有问题，可以毫无顾虑地使用变基操作，如果出现完全失误的情况，只需要使用 git reflog 和 git reset 命令就能回到之前的状态！ - Zaz
@baudtack 您的说法有什么论据吗？（我不使用它，但出于他人的考虑而好奇）。 - MasterMastic
@Ken，我的评论来自旧版的Git使用经验。但是，如果你尝试对已经推送到其他人使用的外部仓库的内容进行rebase操作，那么这可能会给你带来严重的后果。这样做会引起天上的火焰降下，烧毁你，并警示所有其他人不要做这种可怕的事情。 - baudtack
4
git rebase一点也不危险。如果您想在执行rebase之前有一个简单的安全保障，请使用git branch branchname.bck创建当前HEAD的备份分支。如果您对rebase不满意，请使用git reset --hard branchname.bck返回到先前的状态。如果您想返回到rebase版本，重新安装的提交仍然存在，但由于它们存储为未引用的对象，因此您需要git reflog或git fsck --no-reflogs来查找正确的SHA1值。 - sunny256
2
请大家停止“rebase非常危险”的梗。危险吗？不，近乎神奇！分歧的共享历史确实很痛苦。但是为了清晰地提交，应该鼓励对自己的分支进行rebase操作！例如：http://jeffkreeftmeijer.com/2010/the-magical-and-not-harmful-rebase/ - spazm
14
最终，我最终通过逐个函数提交来完成。
不要忘记你可以通过逐个函数地执行“git add”命令，只进行一次提交：
- 在给定任务的所有函数都编写或修复完成后； - 或者当你意识到目前的函数太大/复杂，无法很快地作为提交的一部分时：此时，你可以提交当前“在舞台上”的内容（即“已添加到git”），这不包括你当前在工作目录中的修改。
因此，提交的数量可以与分支的目的相关：
- 本地分支：随心所欲，随时提交 - “公共”分支（你将要推送的分支）：
- 对于本地存储库（针对选定的人群）：你可以至少重新组合非常小的“中间”提交。 - 对于公共存储库（供所有开发人员或其他项目查看）：你可以进行交互式变基，以便按“活动”或“任务”重新组合你的提交，使其更易读。
简而言之，“发布”考虑因素可以在分布式版本控制系统中指导你正确地进行提交，以实现正确的提交数量。
10

你提交得越多，使用git bisect查找缺陷就会更容易。

9
只要所有提交都编译通过并且现有的测试也通过了。 - Marius K
2
@MariusK 嗯，我有点假设你没有将完全错误的代码提交到主分支。 - baudtack
8
一旦测试通过，或者添加/删除/修改了一个功能单元。
3

这取决于具体情况。

我个人的做法是，像你现在正在做的一样，经常在本地提交代码，但只有当我累积了多个重要的更改时，才会将它们推送到远程仓库。

这样可以确保我保存我的工作，但也不会为其他用户造成仓库混乱。

你可以经常运行 "git add" 来保存你的工作，但只有当一个功能完成时才提交。 - Marius K
2
但是如果您不提交这些本地更改，您将无法返回并审查自己的工作。 - samoz
"它也不会为其他用户使repo混乱。虽然这是一段时间以前的事情，但您希望尽快将更改合并到主干，以便其他人可以集成。在每次提交之前始终存在并通过测试。" - ocodo
3
我们的业务需求要求我们在程序编译时提交到不稳定分支，在通过单元测试并经过客户审核后（在不稳定分支下）再提交到稳定分支。
2

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

1

我认为你正在做的事情是正确的。每当你有一个可用的设置，如果你弄错了什么想要回到之前的状态，那么就是提交的好时机。如果你有一个很好的设置，可以快速轻松地运行回归测试，那么提交的频率可能会相对较高。对于我来说，一周提交一次已经很幸运了。

1
1- 提交应该频繁进行；将代码提交到远程仓库（而不仅仅是本地）应该经常进行，以防代码不小心丢失；这种情况比你想象的更加频繁，所以在一天结束时推送更改是必要的，以避免潜在的重复工作，并确保远程仓库始终是最新的。
2- 提交应该粒度适当，因此不应包含太多对代码库的更改。具有太多更改的提交难以还原，并且不能从“历史”角度用作参考，因为提交消息必须太长才能涵盖全部范围。
3- 提交应具有适当的标题；标题应以大写字母开头，不应以句点结尾。通常，标题应简短明了。
4- 提交说明是可选的，但很好拥有。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接