Git 你什么时候做出第一次承诺？

问题：

基本上我想知道，何时是第一次提交源代码/版本控制的最佳/正确时间

背景：

我自己写和维护一些项目，主要是作为业余爱好或志愿者工作。当开始一个新项目时，我通常会非常快速地迭代，以获得网站/应用程序的外观/感觉。一旦“框架”完成，我就开始处理各个部分或页面

在过去，直到我完成了第一个“alpha”构建（几乎所有最初想要的功能都在那里），我才进行了第一次提交。我从来没有担心过把事情搞砸，因为我在写东西的时候一直在测试（例如，从远程开发服务器提供的网页），如果我把事情搞砸了，我可以立即恢复。我从不担心丢失工作，因为文件存储在两个地方（本地机器和远程开发服务器）

尽管最近我一直在想，也许我应该在项目一开始就做出我的第一个承诺。然后在框架完成时，在每个页面/功能块完成时进行提交。这种方法可以让我更好地了解所做更改的历史，但我想知道，在项目早期提交这种更改是否还有其他好处

---

我发现的两个最相关的帖子，和，似乎没有给出一个很好的答案/解释什么时候做出第一次承诺以及为什么

第一次承诺不应该比你的任何其他承诺更重要；这就像回购协议中的任何其他承诺一样

你应该在觉得合乎逻辑的地方做你的第一次承诺，也就是说，无论你在哪里做的工作合乎逻辑，足以证明一次，而且只有一次，承诺；就像您在正常工作流程中所做的那样

我的第一次提交通常是空的项目IDE文件或初始.gitignore

---

不要害怕承诺。事实上，你应该有相反的感觉：经常承诺帮助你。把官僚神经症留给合并和标记：）

你的承诺越多越好。您只需打开一个新的“dev”分支，开发并提交到该分支中，最后将其合并到master分支中并去掉dev分支。如果某件事情起作用，或者如果我把它称为一天（通常在那之后我会把它推到原点），我会提交它。

我通常喜欢提交一个

.gitignore

文件作为第一次提交的唯一内容

---

然后，在我将某个东西敲入某种原型形状之后，我可能会进行一次完全新的回购，而不包含所有的垃圾，或者进行大量的再基础挤压，或者其他任何操作。这取决于提交历史记录中的内容是否有用。

我通常在一开始提交第一次初始化提交时使用基本的

.gitignore

（在极少数情况下，这甚至可能是空白）和/或解释项目的

自述文件。这发生在我开始项目工作之前

我能很好地理解你在从头开始时决定你的第一个真正承诺应该是什么的困难。毕竟，我们希望做出有用的承诺，这些承诺实际上包含一些有用的、已经在工作的东西。但特别是在一开始，这真的不可能，也不容易。但这是完全正常的。所以，你不应该为自己所拥有的东西感到羞耻。也许可以尝试将其打包成语义步骤，如“添加基本应用程序框架”、“添加布局草稿”，但即使这样有时也是可能的，所以请继续并提交一些内容

如果您真的想稍后清理，您仍然可以在发布项目之前重新设置基础，因此即使那些“WIP”提交也将被重写为实际有用的包。
我假设您在谈论启动新功能时的第一次提交，而不仅仅是回购中的第一次提交。我还认为，您（和我一样）曾经使用SVN或CVS，或者在其中提交是不可变的，并且会立即与其他人共享

使用git的好处之一是可以使用私有的rebase工作流。在此工作流下，我将提交视为不同的“类型”提交：


检查点-一个保存点，因为我想保存我的位置，例如，我要重构一些我想轻松退出的东西，或者我需要切换到其他任务，或者我只是晚上离开工作

开发里程碑-达到了开发中的一个重要点，例如，您完成了功能的编码或修复了某个bug

功能里程碑-达到开发过程中的一个重要点，例如，功能（或功能的一部分）代码已完成并通过初始测试


我的检查点提交是非常临时的-我将重置它们，修改它们，重新设置它们的基础，并在工作时挤压它们。我的开发和功能里程碑承诺将一直保留，直到我完成该功能。一旦我完成了该功能，我会清理我的历史记录，并在合并和推送时决定我认为在项目历史记录中保留哪些内容是重要的——我会重新排序并压缩一小部分重要的历史提交，甚至是该功能的单次提交）

我的观点是，在开发过程中，不要让你的第一个承诺流汗——根据需要频繁地进行检查点。一旦您在完成特性后拥有更多的历史记录并清理了分支，就可以更容易地决定特性分支中的“第一个”（可能只有一个）提交内容


Linus关于专用重基工作流：




人们可以（也可能应该）重新定位他们的私人树木（他们自己的）
工作）。那是一次大扫除。但从来没有其他民族的代码。那是“毁灭”
“历史”


现在“干净”部分有点微妙，尽管第一条规则是
非常明显和简单：


保持你自己的嗨