最佳/不好的代码共享实践？

Question

我越探索Github，我就越喜欢它。我真的很喜欢编码变得越来越社会化。

我很好奇程序员在彼此共享代码时是否应该避免任何不好的做法。在命名不良实践时，代码共享的最佳实践是什么？

例如：

单个回购程序是否存在多个名为“MiscProjects”的脚本/项目？这个回购，顾名思义，是一个杂项的小脚本和项目的集合。这可能类似于程序员在他/她的本地存储上组织项目的方式，但它可能不是代码共享的最佳方式吗？

也许如果一个好的自述/文档被完成，它会更好吗？或者只要有很好的记录有什么进展吗？

Answer 1

虽然没有固定的“坏做法”，其他版本控制系统也是如此，但也有约定。

你的Git回购应该尽可能小。如果您来自CVS/SVN模块，通常会有一个结构化的单一存储库，它可以为多个项目组成多个存储库。Git的方法是将它们分开，并为每个项目提供单独的Git repos。原因如下：

• 对于较小的回购，Git更快。
• 由于其设计，每个操作影响整个回购。在必要的项目上执行Git操作是效率低下的，如果您只处理其中一个项目的话。

与往常一样，文件是必须的。虽然人们擅长阅读代码，但没有人比他们需要更多地想要解释代码。使用高层自述来描述项目和Git回购的结构，对于那些参与(或希望参与)项目的人来说总是一件好事。

GitHub上的大多数项目都符合这些约定。使用它们作为示例，说明如何构建未来的项目。