问题：
基本上我想知道，第一次提交源代码/版本控制的最佳/正确时间是什么时候？
背景：
我自己写并维护一些项目，主要是作为一种爱好或志愿者工作。当开始一个新项目时，我通常会非常快速地迭代，以使网站/应用程序的外观/感觉达到我想要的位置。一旦"框架"完成，我就开始处理各个部分或页面。
在过去，直到我完成了第一个"阿尔法"构建，我才进行第一次提交，其中几乎所有最初想要的功能都在那里。我从来没有担心会把事情搞砸，因为我在写作的过程中不断地进行测试（例如，从远程开发服务器提供的网页），如果我把事情弄砸了，我几乎可以立即恢复。我从来没有担心丢失工作，因为文件存储在两个地方（本地机器和远程开发服务器）。
不过最近我一直在想，也许我应该在项目一开始就做出第一次承诺。然后在框架完成时，在每个页面/功能块完成时进行提交。这种方法可以让我更好地了解我所做的更改，但我想知道在项目早期进行更改是否还有其他重大好处。
我发现的两个最相关的帖子，使用源代码管理和源代码管理-如果，为什么，如何开始？，似乎并没有给出一个很好的答案/解释何时做出第一次承诺以及为什么。
我通常在一开始就提交第一个初始化提交，其中包含一个基本的.gitignore（在极少数情况下，它甚至可能是空白的）和/或一个解释项目的README。这发生在我开始做这个项目之前。
我能很好地理解你在从头开始时决定第一个真正的承诺应该是什么的困难。毕竟，我们希望做出有用的提交，这些提交实际上包含一些有用的并且已经在工作的东西。但尤其是在刚开始的时候，这真的不可能，也不容易。但这是完全正常的。所以你不应该因为犯下你所拥有的东西而感到羞愧。也许可以尝试将其打包成语义步骤，如"添加基础应用程序框架"、《添加布局草案》，但有时这也是可能的，所以继续执行并提交一些内容。
如果您以后真的想清理，您仍然可以在发布项目之前重新建立基础，因此即使是"WIP"提交也会被重写为实际有用的包。
第一次提交不应该比您的任何其他提交更重要；这只是一个承诺，就像你回购中的任何其他承诺一样。
你应该在任何感觉合乎逻辑的地方进行第一次提交，也就是说，无论你在哪里所做的工作符合逻辑，足以证明一次也是唯一一次提交是合理的；就像您在正常工作流程中所做的那样。
我的第一次提交通常是空的项目IDE文件或初始的.gitigner.
不要害怕承诺。事实上，你应该有相反的感受：经常承诺帮助你。把官僚主义的神经症留给合并和标记：）
你的承诺越多越好。您可以打开一个新的"dev"分支，开发并提交到该分支，最后将其合并到master分支，并去掉dev分支。如果某个东西有效，或者我称之为一天（通常在那之后我会将其推到原点），我会提交
我通常喜欢提交.gitignore文件作为第一次提交的唯一内容。
然后，在我把一些东西打成某种原型形状后，我可能会制作一个全新的repo，里面没有所有的垃圾，或者做很多重新基础的挤压，或者其他什么。这取决于提交历史记录中的有用内容。
我假设您谈论的是启动新功能时的第一次提交，而不仅仅是回购中的第一次交付。我还认为，您（和我一样）曾经使用SVN或CVS，或者提交是不可变的并立即与他人共享的东西。
使用git的好处之一是可以使用私有的rebase工作流。在这个工作流程下，我认为提交是不同类型的提交：
-
checkpoint-一个保存点，因为我想保存我的位置，例如，我要重构一些我想轻松退出的东西，或者我需要上下文切换到其他任务，或者我只是晚上下班
-
开发里程碑-达到了开发中的一个重要点，例如，您完成了功能编码或修复了某个错误
-
功能里程碑-达到了开发中的一个重要点，例如一个功能（或功能的一部分）是代码完成并通过了初始测试
我的检查点提交是非常临时的——我会在工作时重置它们，修改它们，重新设置它们的基础，并压缩它们。我的开发和功能里程碑提交一直持续到我完成功能为止。一旦我完成了该功能，我就会清理我的历史记录，并在合并和推送时决定我认为在项目历史记录中保存什么是重要的——我会重新排序并压缩少量历史上重要的提交，甚至减少到该功能的一次提交）。
我的观点是，不要在开发过程中为第一次提交而流汗——根据需要经常检查点。一旦您在完成功能并清理分支后有了更多的历史记录，就可以更容易地决定什么应该是功能分支中的"第一个"（可能是唯一的）提交。
Linus关于私有数据库工作流：
- http://lwn.net/Articles/328438/
人们可以（也可能应该）为他们的私有树（他们自己的工作）。这是清理。但从来没有其他人编码。这是"毁灭"历史"
现在，"干净"部分有点微妙，尽管第一条规则是非常明显和简单：
-
保持您自己的历史记录可读
有些人只是先在脑子里想清楚，然后不犯错误。但这是非常罕见的，对于我们其他人来说当我们处理问题时，请使用"git-rebase"等。
所以"git-rebase"并没有错。但只有当它是你自己的才是正确的私有git树。
-
不要暴露你的垃圾。
这意味着：如果您仍处于"git rebase"阶段，则不推它出来了。如果它还没有准备好，你可以四处发送补丁，或者使用私有git树（就像"补丁系列替换"一样）公众对。