我不确定一个项目何时足够远以首先提交到源代码管理。在项目“框架完成”之前，我倾向于推迟提交，并且从那时起我主要提交功能。 （我还没有做过足够大的个人项目，以至于没有一个太大的核心框架。）我觉得这不是最佳实践，尽管我不确定会有什么问题。
比方说，例如，我有一个包含单个代码文件的项目。要使该项目具有极其基本的功能（1个或2个功能），将需要大约10行样板代码和100行。我应该先签入：
空文件吗？
样板代码？
第一个功能？
在其他地方？
>
此外，在特定地点办理登机手续的原因是什么？
#1 楼
一旦有了明智的“单元”，就应该立即提交。什么是单元？这取决于你在做什么。例如，如果您要创建Visual Studio项目，则即使解决方案中没有任何内容，也要在其创建后立即提交解决方案。
从此开始，请尽可能多地提交，但仍只提交完整的“单元”（例如类，配置等）；这样可以在发生问题时使您的生活更加轻松（您可以还原少量更改），并减少发生冲突的可能性。
评论
我该死的不断靠近一个工作分支，然后将该分支合并到主线中。它提供了两全其美的优势，因为主线由具有少量要还原的更改集的单元组成，但是主题分支可以让我一次只备份一点。
– Jeff Ferland
2012年11月22日17:13
提交永远不会太小！不要克制自己所做的更改！
–莱昂纳多·埃雷拉（Leonardo Herrera）
2012年11月22日19:49
我想对许多小的，频繁的提交+1，具体取决于您的工作流程以及有多少人对您的回购感兴趣以完成他们的工作。 Git可以稍微重写历史记录的功能，这样在您推动之前，在FooSerializer上进行的15次提交就可以成为一件事。
– Tim Post
2012年11月23日下午0:28
@loldop：这取决于您使用的版本控制软件。假设您正在使用Git：您可以存储所做的工作，进行修复，提交，重新应用已隐藏的更改并重新开始进行处理。在Subversion中，您可以在另一个文件夹中对存储库进行另一次签出，修复错误并提交到那里的存储库，而不会影响您的重构。或创建补丁文件，恢复您的编辑，修复错误，提交，重新应用补丁。有很多方法可以做到这一点。
– Albireo
2012年11月23日10:52
也许这是对第二，第三提交等的一个很好的答案。但是第一个应该是空的。
–Felipe
2012年11月23日12:44
#2 楼
就我而言，您的源代码控制存储库是基本项目设置的一部分，因此我在生成空项目后立即提交。评论
提早提交，经常提交。
–莱昂纳多·埃雷拉（Leonardo Herrera）
2012年11月22日19:46
我比接受的答案更同意这一点。如果我把事情搞砸了，我还将源代码控制（我的意思是DVCS）视为一个很大的撤消按钮。我也强烈建议您使用semver（通过标签）并从版本0开始
– Antony Scott
2012年11月23日下午0:15
感谢@AntonyScott，我100％同意接受的答案，但是当我写这篇文章时，我有这样的愿景：用1500字的文章来混淆我如何管理源代码控制以及为什么。因此，我决定保持简单明了。
–约翰·麦金太尔
2012年11月23日在0:24
是的，+ 1。如果您对空的提交感到不满意，请以Xion在另一个答案[programmers.stackexchange.com/a/176845/5405]中写的.gitignore（或等效名称）开头。这是非常自然的第一次提交。
– Hanno Fietz
2012年11月23日9:13
我注意到问题上的“长答案”标志，不禁认为它是在指这个答案。 AFAIC我回答了“为什么？”问题与“源代码控制存储库是基本项目设置的一部分”的答案相同。就像我说的那样，我可以写一篇关于我如何使用源代码控制的完整哲学的文章，但这只会减损这个答案。如果有人对我的答案有特定的疑问，我会很乐意回答，但是否则我不想为了语而把这个答案弄虚作假。如果要删除它，请继续。
–约翰·麦金太尔
2012年11月23日在16:24
#3 楼
昨天...或者，如果您无法进行时间旅行...
（也许您的汽车无法达到88 mph的速度，或者您的磁通电容器刚被卡住）
现在
新项目应该在流血的地方进行，这是很疯狂的，并且当代DVCS系统只是删除了所有可能的借口以避免提交：
git init . ; git add * ; git commit -m initial-commit，在为时已晚之前，可能已经发生了。一个更明智，可争论的问题可能是：“我什么时候应该将提交的内容合并到已建立项目的团队托管存储库上的共享源代码控制中？” （请注意形容词，形容词很重要），我觉得大多数其他答案实际上都是在试图回答这个问题。
您的私人部门应该每天晚上一次，至少在睡前疯狂。您可能只是在第二天早上醒来，却不知道前一天晚上到底在做什么。 VCS应该可以解决这一问题，并且有机会回滚到一个最新的sub-sub-sub-version版本，该版本可以很好地编译，平稳运行和/或通过测试可能是您的最佳选择。
评论
我不介意提交无法编译的更改，尤其是在一天结束时。第二天，您会遇到一些无法编译的内容，但是您仍然拥有提交历史记录-如果您不希望历史记录“肮脏”，则每一个好的DVCS都有回滚选项（我认为我们都同意DVCS是唯一可以走。）
–莱昂纳多·埃雷拉（Leonardo Herrera）
2012年11月22日19:51
@LeonardoHerrera我了解您的POV，尽管在具有多个入口点的解释型语言项目中，您最终由于合理的原因（例如在其他入口点上共享错误修复程序）提交了一些未编译的分支，但肯定可以做得更好，也更好，但后来排序就变成了一个问题……和“古斯塔布斯”无害争议。
– ZJR
2014-09-17 22:25
#4 楼
我会说尽快提交。源代码控制的主要目的是允许您在出现问题的情况下返回，这与“尽早并经常提交”的做法产生共鸣。个人而言，我的第一次提交通常只包含.gitignore文件（或等效项），但我需要的过滤器很少，例如* .py [co]用于Python代码。通常会遵循基本的项目设置和/或第一个最简单的原型。
评论
我做类似的事情。由于我使用GitHub，因此我也始终拥有基本的README文件，即使该文件仅包含项目名称也是如此。我发现从一开始就拥有该文件，这使我将来很有可能会更新它的可能性更大：)。
– Tikhon Jelvis
13年1月26日在21:46
#5 楼
第一次提交可以是一个README文件，其中包含项目的一行摘要，或者有关该项目的第一个里程碑的足够信息。广泛的主题还可以包括：简介
项目描述
项目结构
编码约定
有关如何操作的说明：
构建
测试
部署
已知问题和解决方法
待办事项列表
使用条款
在对项目进行更改之前更新自述文件的做法也称为自述驱动开发，它使您可以在花费时间进行更改之前仔细考虑更改。
想要贡献或使用此软件的用户，将从README开始。
#6 楼
如果您完成了不想丢失的工作，那么它应该在源代码控制系统中。这当然适用于Git等分布式系统。如果您使用的是集中式系统，那么签入的唯一方法就是让所有人都可以看到它，那么您可能希望暂缓执行-或者您可以考虑建立自己的本地git存储库，然后提交给集中式系统准备就绪时。
评论
我的规则是这样，此外，我还希望它成为“代码编译的时间点”。如果您必须找出什么时候弄坏了东西，那么提交那些不能编译和平分的东西会变得更加烦人。
– Warren P
2012年11月23日下午0:55
至少对于git来说，临时分支不会地址吗？我没用过git bisect。
–基思·汤普森（Keith Thompson）
13年1月27日在20:34
我使用Mercurial无需重新设置基准，因此我将所有提交视为永久提交
– Warren P
13年1月29日，下午2:17
#7 楼
我的经验法则是，一旦解决方案文件（或其他构建脚本片段）完成，即使其中包含一些空文件，也要签入。对于一个以上的人从事该项目的情况，这是一个好习惯。该文件在开始时往往会遇到最严重的合并问题，因为人们正在向项目中添加内容，因此需要尽早且经常提交。即使您是唯一在项目上工作的人，也只有一个文件，我发现更容易遵循相同的工作流程并节省了眼前问题的思考。
#8 楼
不知道是否提到了它。但是请确保您提交的内容可以运行/编译！因此，没有语法错误等。
没有比检查已损坏的代码更令人沮丧的事情了。
评论
确实有道理！
– Aquarius_Girl
2012年11月28日在1:30
我不同意。如果我要提交的代码无法编译，请在提交消息中的某处写入WIP。然后，当我需要最新版本的编译时，我就可以忽略这些提交。
– Minthos
2012-12-12 12:27
#9 楼
一旦您拥有绿色的新测试用例，便会提交与软件测试（TDD方法）更相关的其他观点。这意味着您已经完成了一个新的代码“单元”。评论
要覆盖一个方法，您可能（通常）需要对其进行几个单元测试。说您是否通过测试并不是真的，这意味着您要完成一个工作单元。甚至说完成该方法也是一个工作单元都不是真的。
– Beehnam Rasooli
17年2月16日在4:33
#10 楼
在您做一些愚蠢的事情之前。对于我们这些没有魔法能力的人来说，这意味着很少而且经常。
如果您是一个人工作，那么每次得到它时，都要做喝酒之类的东西。
如果您在团队中工作，则可能需要确保该东西能够编译，这样，即使别人更新了，他们也不会得到错误。但是除此之外，您还可以尽力而为。
#11 楼
该项目大约需要2到3个小时。只是开个玩笑。没有一个适合所有情况的好答案。首先，如果您具有分布式版本控制系统（如git或Mercurial），那么在灾难性故障的情况下，提交给本地存储库将不会保留您的数据。但是，私人远程回购可能会花您很多钱，例如在github上您将保留提交历史记录，但是以我的经验，在您的项目进行一些高级之前，您将不需要它。
此外，您一开始可能并不需要太多的改动，特别是如果您正在移动文件。如果只是很小的一部分，那么进行更改将是一个负担。您甚至可能决定扔掉东西。但是，如果您丢失了难以复制的更改，那么您将错过制作备份副本的机会，而版本控制系统将使备份系统变得非常有价值。码。在项目开始时，这可能是一个很好的折衷方案，因为它的建立工作量为零。但是，在认真的软件开发中，这是一种野蛮的习惯，尤其是当几个人同时触摸代码时。
因此，我倾向于在有有价值的东西时就设置版本控制，即不容易复制。价值是主观的（取决于个人的能力），因此您将必须做出自己的判断。那时，我将第二个存储库存储在外部磁盘上，或者如果它是公共项目，则存储在github上，否则我的付费帐户将保存该存储库。
#12 楼
许多人已经回答“马上”，我100％同意。我也喜欢Xion的建议，从VCS的忽略模式（即.gitignore或等效的）开始。我认为已经非常同意早期提交没有不利之处。我想补充一点：
您不太可能提交您选择丢弃的东西，但仍然徘徊。当我开始一个新的开发时，我会快速编码并散布东西，而当我稍后提交时，当已经有很多文件时，我意外地提交了东西，只是在下一次提交中将其删除。与小的甚至是空的提交相反，这是历史上的真实声音。
如果您是系统的类型并且在项目中具有典型的第一步，那么将这些作为提交点可能对您或对其他人，甚至可能提供在某个点分支并创建可重复使用的项目存根的机会。我曾在基于Maven的项目中工作过，这很有用（因为在建立Maven项目时，一些小的第一步已经可以定义一个相当大的基础，尽管这些步骤没什么大忙，但他们可能需要足够的思考才能保证可重用性）。
#13 楼
这可能取决于您使用的是哪个VCS。使用Git，我提交了一个空目录（或使用几乎为空的README文件）。关键是，如果我仍想在开发过程的早期（在推向上游之前）完全重新开始，则可以返回并将分支重置为空状态。然后，我将提交“生成的”文件（例如，Visual Studio解决方案）。然后，当我实际编码时，我将像往常一样开始提交每个单元。
使用SVN，您将每次提交都推向上游，因此您真的无法像您一样从头开始用Git做。在这种情况下，如果您认为要在此过程中尽早进行重大修改，那么尽早提交可能没有好处。这将取决于编码人员。
#14 楼
当我开始一个新项目时，通常在添加任何代码之前先进行确认。我一直遵循的一般经验法则是：如果您的PC崩溃并擦除了所有数据，那么您将不需要从内存写入什么代码。十年之前，在TDD和更好的编程习惯之前，我对自己能记住的东西非常乐观。现在，我倾向于更加谨慎。正如许多其他发布者所说的那样，提早提交并经常提交。我并没有因此而失去任何东西。这样，如果我明天不去的话，那么我的同事们可以从我上次停下来的地方接电话。
我目前正在使用Tortoise / SVN。
#15 楼
立即提交空项目。您每小时花在项目上的次数要保持几次。即使代码没有编译也要提交。我在提交消息中用“ WIP”标记了这些提交，以跟踪它们。我还有一个脚本，可以每10分钟自动将我的所有项目提交到备份存储库，以防万一我忘记了手动提交。让我们称之为我的云备份撤消缓冲区。
在需要团队查看代码时，将项目检入（也称为推送）到团队仓库中。如果您像我一样，这可能早在代码可以被团队看到之前。
如果您希望对您的团队友好，请在将提交提交给团队之前先压扁他们的提交。回购。
#16 楼
我浏览了所有文章，我认为我们已经有了很多好的解决方案，但是我想与您分享我的方法。直到每个模块完成或完成为止。所以我总是有2个位置，一个叫做DYNAMIC，另一个是STATIC。在进行更改并且尚未完成框架时，将其提交到DYANMIC位置，一旦完成并完成，我将其移至STATIC位置。
所以我有一个完整的源代码管理。
感谢
#17 楼
对于任何应用程序，您都将花费一些时间来设计组件。您应该大致或完整地了解您的姓名空间，项目，外部引用，第三方库等。如果您是团队成员，我建议您担任领导，或者选择任何人，以创建基础项目，获取依赖项集，并检查其骨架（将在其上构建项目的基础）。
您还想确保自己拥有任务，发布，主干，等。签入之前指定分支，以便您的流程稳定。
如果您正在为一个已经在进行中的项目处理新的“任务”，并且您在自己的任务分支中，请每晚办理登机手续，以保存您的工作。
#18 楼
通常，每当我添加新内容时，我都会签入，但尝试将内容分离到离散的提交中。 -足够浪费从头开始重新进行操作的时间。如果我有更大的任务，则在有意义的情况下尝试多次提交（每个函数一次，每次使其编译并成功运行等）。我也会在需要时提交一个备份点（即“如果我现在尝试的操作不起作用或变得太复杂，我想回到现在的代码中”，或者当有人要求我放弃正在做的事情并解决一些紧急问题时） ）。
如果使用集中式源代码控制系统，则不能随意提交备份点，因为未编译/无法工作的提交会影响团队中的每个人。
通常，当我开始添加样板代码（例如，在django网站中添加新的webapp）时，我将执行我的所有操作。
如果我按照教程生成/编写代码，则使用步骤名称在教程中提交消息。这样，我可以比较修订版本，并在以后的任何步骤中查看指导步骤。
例如，假设我有一个项目，其中包含一个代码文件。要使该项目具有极其基本的功能（1个或2个功能），将需要大约10行样板代码和100行代码。
这取决于添加内容的难度是：
如果添加样板代码很简单，那么我会添加它并在开始其他代码之前就提交（这样，如果我出错或引入了后来出现了怪异的错误，我可以简单地还原为样板代码，然后重新开始。
如果代码不平凡，我每次添加新内容（每两行代码更改之间的任何地方）都会提交一次一百左右）。
评论
在您回家之前，您要提交自己的工作分支。在创建Sourceforge项目，设置网站，配置邮件列表以及对该项目进行博客撰写多年之后，应该始终进行第一次提交。 :)
太早或经常承诺的缺点是什么？
mkdir myproj; cd myproj; git init;开始工作。
我通过视频游戏中的“快速保存”按钮了解了如何管理进度保存。规则如下：我是否介意重做该部分？保存：SaveAnyway;我采用相同的方法进行源代码控制，我不等待某些工作正常进行或接近完成，我只是等到发现某件事或进行了足够的更改后才开始尝试再次退出或再次进行更改，然后我签入。这就是为什么人们建议在项目创建后进行保存；创建项目很烦人，请签入，这样就绝对不必再次执行此操作。