再会！
碰巧除了我之外还有几个人加入了开发一些软件。问题是，小组发展如何运作？整个小组都可以访问源代码，还是每个人都将自己的部分切成 dll 供其他人使用？它是如何优化的，以便您可以随时构建应用程序，而无需试图通过敲门敲打削减某些部分的人，以便他抛出或纠正错误。事实是我之前没有在团队中工作过，网上也没有详细的系统。我将领导整个过程（谁在削减什么，等等）而且我需要完全访问所有编写的代码，以便我可以随时更正某些内容等。告诉我看哪个方向，我将非常感激
RError.com
再会！
碰巧除了我之外还有几个人加入了开发一些软件。问题是，小组发展如何运作？整个小组都可以访问源代码，还是每个人都将自己的部分切成 dll 供其他人使用？它是如何优化的，以便您可以随时构建应用程序，而无需试图通过敲门敲打削减某些部分的人，以便他抛出或纠正错误。事实是我之前没有在团队中工作过，网上也没有详细的系统。我将领导整个过程（谁在削减什么，等等）而且我需要完全访问所有编写的代码，以便我可以随时更正某些内容等。告诉我看哪个方向，我将非常感激
顺便说一句，这是一个非常有趣的问题。我会尽力回答。
确实，需要做些什么才能让一个小团队开发项目？
至此，我相信你已经有了职权范围或对最终结果应该是什么样子的想法。
概念/设计/建筑
可以说，团队发展的第一步也是最重要的一步是制定概念或顶层设计。当您独自工作时，您的脑海中始终保持着大局：输出应该出现什么应用程序，它将包含哪些模块，项目具有哪些一般质量和完整性标准。在团队中工作时，此视图对于所有开发参与者来说都是一致的，这一点很重要。例如，划分为“用户登录”、“订单篮”、“商品主清单”等模块。也就是说，它必须被记录并修复。本文档和以下所有内容都可以放在源代码旁边。
配对模块
一旦定义了模块，重要的是要捕获它们相互交互的方式。至少在一般情况下。这是必要的，因此编写模块或多或少是一项孤立的任务。例如，您将这些模块的责任分配给您的同事，但其中一个突然失败 - 虽然希望一个开发人员的文件对其他模块的影响最小，但是失败的模块可以简单地再次重写而无需触及其余模块的代码库。
核心服务
最有可能的是，当您编写模块时，您将使用某种通用代码，一个通用库，例如，用于记录、访问数据库、管理用户访问。这是一个非常重要的部分，我建议将其委托给最有经验的开发人员（或开发人员）。这里也可以建议你提前准备好编程接口（也就是坐下来和团队一起把这些服务的接口扔进去）。有了预先准备好的接口，您就可以在开发人员之间分担实现这些接口的责任。在这种情况下拥有接口非常重要，因为
样本
此任务也适用于一组或最有经验的开发人员 - 准备一个近似概念或模块实现的示例。这样做的目的是为其他开发人员展示一个模板，如何编写你的模块，它们应该由哪些部分组成。例如，如果您正在规划一个 3 层架构，那么您可以演示如何结合上述核心服务来实现它。顺便说一句，在这里你可以根据你的架构做出选择，它是由层组成，还是一个 CQRS 或其他东西。
任务
所以，你有主要服务的接口，你有一个高级架构。现在您可以启动任务列表。许多事情都需要任务列表，例如，了解大概的工作量。与您的团队一起创建待办事项清单。这里的重点是每个团队成员都了解这个或那个任务的用途。您可能还不了解这些任务将如何完成，但您应该了解为什么需要这些任务。
这里尽量避免技术问题，至少在一开始是这样。一个糟糕任务的示例：“为订单编写存储库，以便在订单模块中使用它。” 这项任务基本上没有说明它带来了什么价值以及如何执行它。一个更好的任务示例：“在用户的个人帐户模块中，添加查看他的活动订单列表的功能，其中包含指向特定订单页面的过渡链接。” - 也就是说，在形成任务列表时，我建议首先从使用该系统的人将如何使用该系统开始。如果您愿意，可以使用此类用户故事。
避免大型任务，将任务分开，以便在最多几天内完成其中任何一项。在创建任务时，还需要指出其实施的大致时间。
正确划分任务。不要编写跨模块的任务——如果一个任务需要多个模块的参与——把它分成几个任务。
如果可能，尽量保持任务隔离。请记住，程序员可以伪造任何任务，这对您和您的系统的影响应该很小，您只需将任务委托给另一个程序员并由他执行。
代码约定
所以，你有一个示例模块，你有任务，你有核心模块。你几乎准备好了。但是你应该明白，除了明确划分模块/任务/职责之外，如果在代码上有一些约定是很好的。这是必要的，因为每个程序员对于如何命名变量和类、何时捕获/抛出异常等等都有自己的想法。尽量使项目保持大致相同的风格。例如，我有不同的案例和要求，从项目中的每个文件甚至不应该有来自 Resharper 的警告这一事实，以一篇关于类型命名的多页论文结束。由于您使用 C# 编写，我可以建议您从这里开始。以相同风格编写的模块更容易理解。
开发过程
有了以上所有，你就可以开始工作了。如何开始团队合作有许多不同的技术，我不想说一种技术比另一种更好。我只会描述我的经验和有效的方法。
近年来我一直在使用Scrum，但描述这种方法远远超出了答案的范围。
由于您的团队中只有少数人，因此我将简单地给出要做什么以及如何组织工作的基本概念。即使您一个人或一个人工作，这也会很有用。
我建议从定义工作间隔开始。冲刺，如果你愿意的话。也就是说，您将展示团队工作结果的最短时间。这通常是一周或两周。也就是说，在冲刺开始时，您与团队以及（可能）与客户一起，在冲刺期间完成一系列最重要的任务。由于每个任务都有完成的截止日期，因此收集一两个星期的任务并不难。此外，我建议至少 70% 的时间都在做任务，不要再多了。也就是说，1周，4个工作日，2周-整个团队8天。这是必要的，以便您有时间进行操作，如果任务提前结束，那么您总是可以采取更多措施。在冲刺结束时，您向客户展示这些任务，总结冲刺的结果，讨论进展顺利的地方，在这个过程中可以改进什么并计划下一个冲刺。理论上，这里一切都清楚了，除了给客户演示。看，一开始就计划一个 sprint，最后展示一下工作是非常重要的，它不仅可以帮助团队看到结果，还有助于了解您所做的是否正是客户需要的工作。这不能被高估，我见过太多的案例，程序员解决了客户不需要的问题，或者没有按照客户期望的方式解决。如果您刚刚开始开发并且对自己的能力没有信心，您甚至可以邀请客户参加日常会议（见下文）并收集客户的反馈。开始的冲刺计划和结束的工作演示非常重要，它不仅可以帮助团队看到结果，还有助于了解您所做的工作是否正是客户需要的工作。这不能被高估，我见过太多的案例，程序员解决了客户不需要的问题，或者没有按照客户期望的方式解决。如果您刚刚开始开发并且对自己的能力没有信心，您甚至可以邀请客户参加日常会议（见下文）并收集客户的反馈。开始的冲刺计划和结束的工作演示非常重要，它不仅可以帮助团队看到结果，还有助于了解您所做的工作是否正是客户需要的工作。这不能被高估，我见过太多的案例，程序员解决了客户不需要的问题，或者没有按照客户期望的方式解决。如果您刚刚开始开发并且对自己的能力没有信心，您甚至可以邀请客户参加日常会议（更多内容见下文）并收集客户的反馈。客户不需要或没有按照客户期望的方式解决。如果您刚刚开始开发并且对自己的能力没有信心，您甚至可以邀请客户参加日常会议（更多内容见下文）并收集客户的反馈。客户不需要或没有按照客户期望的方式解决。如果您刚刚开始开发并且对自己的能力没有信心，您甚至可以邀请客户参加日常会议（更多内容见下文）并收集客户的反馈。
之后，每个开发人员接受一个任务并开始执行。尝试让一个开发人员执行高度相关的任务，并由不同的开发人员执行松散相关的任务。这是必要的，以便开发人员在不同的代码库上工作并尽可能少地重叠，这样他们就不会互相等待，也不会使用相同的类。
在 sprint 期间，我建议每天举行小型会议，以便您了解谁在做什么，如果有人遇到问题。对于开发者来说，有典型的时刻，他等待某事而浪费时间，但只有他自己知道问题所在。尽量避免这种情况。
还需要有一个被纳入 sprint 的任务板，以便任何人（包括客户）在任何时候都可以查看这个板并了解哪些任务正在进行，哪些已经完成，哪些还没有开始了。
划分任务、创建任务板等可以在办公室的常规板上完成（如果整个团队和客户都在附近），或者在互联网上有专门的工具。
使用代码
使用代码也是一个复杂的话题。
在团队开发中，通常假设整个团队必须在同一个代码库上工作。您应该始终能够下载最新的源代码并构建。
在切换到 GIT 之后，我再也看不到回去的路了，尽管我在共享资源上拥有 SVN、SourceSafe、TFS-CVS、Mercurial 甚至爸爸的经验。
说到 GIT，有不同的工具（例如我使用免费的SourceTree）和如何使用它的模型。我更喜欢保留一个单独的主分支（master），一个单独的开发分支（develop），一个单独的任务分支（功能/任务），一个单独的发布分支，修补程序等。但对于一个小团队来说，这是一笔开销。有一种非常简单的GIT 特征分支技术。这里的想法尽可能简单：
当然，当几个程序员在同一个文件上工作时，冲突是不可避免的。GIT 对避免此类冲突没有任何帮助，它只会帮助解决它们。有助于避免的是划分成独立的模块和不相关的任务。如果你注意到了，那么上面我们尝试将代码分成各处的模块，而在不可能做到这一点的地方，那么至少将接口和实现分开。您的代码与其余代码的隔离程度越高，发生冲突的可能性就越小，因为在这种情况下，为了发生冲突，程序员必须处理高度相关的任务，我在上面建议避免这种情况。
持续集成
使用共享源代码存储库，确保代码仍在编译、测试不会失败、在任何给定时间您都可以下载最新版本而无需等待任何人，这一点非常重要。其实这就是所谓的持续集成。每次有人对共享开发分支进行更改时，持续集成服务器都必须为您的程序创建一个新版本并运行所有自动化测试。
测试台
要了解您的程序是否有效，您不仅希望能够构建应用程序，而且还希望能够将应用程序部署到某个测试环境。例如，如果您正在编写一个网站，您应该有一个测试服务器，您可以在其中部署您的代码，并通过单击构建服务器上的按钮查看您的系统的外观。理想情况下，最好有两个测试环境，一个给您，第二个给客户。因此，在 sprint 结束时的每个演示期间，您可以在客户的测试环境中部署您的应用程序，以便客户自己在您不知情的情况下进入他的环境（例如，进入他的网站）并检查实施的功能。
快结束了
我试图了解团队开发的基础知识。大多数主题我没有详细介绍，但我希望你对如何以及应该如何工作有一些基本的了解。
工具
有现成的服务已经包含任务列表、冲刺计划板、源代码管理功能和构建服务器。
例如，
如果您不想弄乱自己的服务器（而且您不想:)
有许多其他工具既可以作为服务使用，也可以作为托管解决方案使用。但是，由于你们只有 3 个，我建议不要发明太多并在以下位置创建存储库：
我会非常简短，以便您推迟最重要的事情。
对于最小的协作开发，您需要三个组件：
所有其他好东西 - 这可以在调试主干之后添加。例如，测试台非常方便，但您也可以在本地计算机上削减功能。
在那之后，我已经建议阅读来自@tym32167 的完整答案 - 那里的所有内容都写得更详细，并且有提示继续前进的方向，深入挖掘的地方。
这些是您的具体问题的答案：
如果您不是Microsoft，其源代码达到千兆字节并且您的安全服务没有特定要求，您很可能会拥有它，以便每个开发人员都可以访问所有源代码，但将代码剪切为单独的功能在单独的分支中，不打扰其他人。
该功能尚未完成 - 它不会打扰任何人，该功能已完成，经过测试 - 其他所有人将在下次更新源时收到它。
再会！
您所说的称为“版本控制系统”（VCS）。除了简单地共享源代码之外，此类技术还允许您存储所有文件的更改历史记录、在多个单独的“分支”中开发、合并“分支”等。
我推荐你使用最广泛使用的版本控制系统 Git，它是由 Linus Torvalds 在 2005 年为开发 Linux 内核而创建的。
该系统非常易于使用，但您需要留出一些时间来学习它。为此，请使用这一系列俄语课程。
您还可以通过阅读俄语的官方在线书籍来学习完整而详细的 Git 课程。它包含您需要了解的有关 Git 系统的所有信息。
请注意，本教程系列使用
touch在 UNIX 兼容平台上使用的命令来创建文件。Windows 中没有这样的命令，因此您甚至可以在记事本中创建文件。您在 Visual Studio 中创建的所有文件都需要使用命令添加到存储库git add .（将当前目录中的所有文件添加到存储库，先阅读下一段，然后才运行命令）。自定义 Visual Studio 文件（.suo 等）以及已编译的可执行文件及其随附文件（.exe、.dll、.lib、.pdb、.xml 等）除外。为此，您需要在存储库的根目录中创建一个文件，
.gitignore并将 Git 应忽略的所有文件的掩码粘贴到其中（对于 C# 和 Visual Studio 项目，此处提供此类文件的示例）。对于协作，您需要使用 Git 服务。您有以下三种选择：
如果您在使用 Git 时需要任何帮助，请在评论中提出问题。我省略了本教程中未涵盖的 Git 的许多重要方面，以免使答案变得不必要地大。