背景

git过去，我曾经使用VCS（主要是）来管理许多现有项目，并且效果很好。通常，对于现有项目，我会检入对代码进行的所有更改，以优化或更改整体功能（您知道我的意思是，在适当的步骤中，并不是我更改的每一行）。

问题

我没有太多练习的一件事是创建新项目。我正在启动一个自己的新项目，该项目可能会变得很大，但是我发现在前几天/几小时/几周/整个时期内，还有很多事情要做，并且有很多变化直到产品以其最基本的形式实际起作用为止。

与现有项目一样，我在流程的每个步骤中是否都需要检查？我没有用所做的更改破坏项目，因为它尚无法正常工作。当我离开计算机时，每天结束时我只是一直在使用VCS作为备份。

我最初的几次提交是诸如“适当的基本目录结构”和“已创建数据库表”之类的内容。开始新项目时应如何使用VCS？

从简单开始

git init

提前入住，经常入住

只需执行您通常对任何项目进行的操作即可：“签入”与特定任务或一组动作相关的每组更改。如果您使用问题跟踪器，则每次在任务处于稳定状态时都提交与任务相关的更改（有关此问题，请参阅SO的提交频率）。它可能不是处于完成状态，而只是处于稳定状态，其中软件不会运行失败或站点无法呈现。正如Jeff Atwood在他的帖子中所说：

如果未将代码检入源代码管理，则该代码不存在。[...]

我不是在建议开发人员检入损坏的代码-但我也认为，损坏的代码和不完整的代码之间存在很大的差异。

经常提交，以后完善，发布一次

如果产品甚至还没有达到可行的状态，那么只要按照自己认为合适的方式检查更改，并运用良好的判断力和常识将它们组合在一起即可。您不需要一次提交每个文件的行更改，但是将所有内容作为大块提交将使您在必要时更难以回滚。

最后，您的VCS可以为您提供帮助。因此，请帮助您的VCS来帮助您！

不要想太多

您的第一次提交很好。不要想太多。最重要的是它们已签到。如果您查看所有从头开始而不是从现有代码库开始的现有在线开源项目，则它们的第一个修订版类似于：

创建了目录结构（是的！）

养成习惯

在每天结束时，请尝试根据提交日志生成您所做操作的日志。如果从得到的产出git shortlog和git log别看满意和有用的，但白天你投入的精力显著量项目，并检查这些更改，那么您可能没有这样做的权利。

• git shortlog应该像您所做的工作的概述一样阅读。
• git log应该看起来像您的项目的历史和故事。

您正在做的是正确的方法。

从第一天开始就使用源代码管理-这将确保您拥有源代码管理中所需的一切，并且毫无用语：

我应该使用源代码管理，但是第一次检查所有这些东西将花费太长时间。

对于后来来源代码控制的人们来说，这是一个主要障碍，因为他们认为使用“太难了”。通过尽早开始并进行更改，您通常可以将障碍减少到一小步，并且与您一起参与项目的其他任何人都可以立即开始工作。