在单个应用程序上具有多个开发人员的开发环境
Development environment with multiple developers on a single application
我正在寻找一种好方法来 optimise/improve 我和我的同事处理我们的应用程序的方式。
我们目前都在 MacBook Pro (2016) 上的 PhpStorm 中工作，这是我们网络中的一个 Ubuntu 服务器和一个映射到我们机器的 SMB 共享上的工作副本（我们有时会编辑相同的文件，使这个不方便）。我们使用 Git 作为源代码控制，并且有 1 个我们都在其中工作的分支。
我们注意到通过网络共享使用 PhpStorm 时出现性能问题，我们的应用程序非常大，PhpStorm 对所有内容进行索引会使它一直冻结并且感觉无响应。
我们正在寻找一种方法来改进我们的工作方式，简化我们应用程序的开发并消除我们在网络 share/working 复制组合方面遇到的性能问题。
我们正在考虑每个人在我们的机器上本地有一个工作副本，有一个虚拟化的网络服务器（Vagrant）和所有 运行 应用程序彼此分开。这将解决网络问题，但会带来其他问题，例如，如果我更改数据库，这些更改也必须在我同事的工作副本上完成。
此外，我们一直在更改相同的文件，我们最不想要的就是每次更改时都修复文件冲突，然而不得不拉取另一个开发人员在白天所做的每一次提交，而且还必须做他们的数据库手动更改。
TL;DR，什么是与 3 个开发人员一起开发 1 个应用程序的好方法。
一个很好的改进肯定是在您自己的应用程序本地副本上运行。正如您所描述的那样，这将解决性能问题，但会给您带来有关数据库更新的问题。
管理数据库更新的一种方法是为每个数据库架构更改使用迁移文件。假设您进行了更改，您将此更改添加到一个新的迁移文件中，该文件被添加到 git 存储库中。有了这些文件，每个人都可以在他们的本地开发数据库之上应用所有迁移，以保持他们的数据库是最新的。它还使测试变得非常容易，因为您可以随时重置数据库并再次应用迁移。
你可以看看别人是怎么应用的。有开箱即用的后端框架（例如 Laravel 对应 PHP）。
我能想到的一个解决方案是使用像 git 这样的版本控制系统。在我看来，你希望所有人都在同一时间从事同一个项目，可能还从事相同的功能。
为了尽量减少合并冲突，我建议创建一个开发分支，并且对于每个功能，它应该从开发分支分支出来并隔离，直到有更新（有人合并或您完成了该功能并合并）。然后其他开发人员可以从 dev 中提取这些更改并继续他们的功能。
如果问题是基于环境的，您可以使用 JetBrains ides 中的 docker 功能来创建一个通用的工作环境。
在对原始回复添加评论后，我认为必须提供此作为答案：
- 正确使用git作为版本控制工具。通过让所有开发人员都在同一个资源上工作，您肯定没有利用版本控制的全部意义。让每个开发人员在他们自己的工作树上工作（如果你想保持这种方式，可以在本地或服务器上工作）这样他们就可以利用 git 的本地开发功能（创建自己的分支、快速操作、不要搞乱其他人正在做的事情），然后在准备就绪时将东西合并到上层开发分支中。这应该可以解决您的很多问题。
这是我的首要任务。
虽然我个人更喜欢使用 Git 及其分支，the deployment feature of PhpStorm could be a solution for you. So instead of using a network bound share, you can have a local copy which will be updated from the external resource. Here are the configuration tutorial and the tutorial 如何使其自动更新。
您应该将 GIT 存储库存储在集中位置，例如在 Github 中，或在您的本地服务器之一中。任何开发人员都可以 pull/push 更改 from/to 中央存储库并使用本地副本（无 SMB 网络）。
考虑使用 Docker 个容器。这将使你们拥有完全相同的开发环境。
可以使用数据库迁移来完成数据库更改。查看此库 doctrine/migrations。
https://www.atlassian.com/git/tutorials/comparing-workflows
注意它说的部分："Developers start by cloning the central repository. In their own local copies of the project, they edit files and commit changes as they would with SVN; however, these new commits are stored locally—they’re completely isolated from the central repository. This lets developers defer synchronizing upstream until they’re at a convenient break point."
我想，一旦你有了这个想法，接下来的事情就会接踵而至。
- 在签入之前始终从 master 和测试更新您的本地分支
- 经常打卡！一天多次。请参阅第 1 点。每次签入都应包含相关代码和 SQL 脚本代码（以及任何其他资源），并且应该编译并运行！
- 会发生合并冲突。没有魔杖，也没有策略。一般来说，尝试协调，以便开发人员通常在孤立的区域工作（这假定你的代码结构很好，可以这样做。这通常是个好主意，但这里的话题太大了）。我建议将更改保存在一个文件中，其中包含任何自动生成的代码，一次只提供给一个开发人员。 （这是经验！）。
- 所有数据库更改都应该是一个脚本，因此也是一个代码文件，在版本控制方面的处理方式与所有其他代码相同，开发人员应该在提交之前测试他们自己的本地数据库副本。您可能需要有人在发布前监督脚本，以查找冲突。您可以规定每个数据库对象（table、视图、sp）有一个脚本文件，这样更容易！
我正在寻找一种好方法来 optimise/improve 我和我的同事处理我们的应用程序的方式。
我们目前都在 MacBook Pro (2016) 上的 PhpStorm 中工作，这是我们网络中的一个 Ubuntu 服务器和一个映射到我们机器的 SMB 共享上的工作副本（我们有时会编辑相同的文件，使这个不方便）。我们使用 Git 作为源代码控制，并且有 1 个我们都在其中工作的分支。
我们注意到通过网络共享使用 PhpStorm 时出现性能问题，我们的应用程序非常大，PhpStorm 对所有内容进行索引会使它一直冻结并且感觉无响应。
我们正在寻找一种方法来改进我们的工作方式，简化我们应用程序的开发并消除我们在网络 share/working 复制组合方面遇到的性能问题。
我们正在考虑每个人在我们的机器上本地有一个工作副本，有一个虚拟化的网络服务器（Vagrant）和所有 运行 应用程序彼此分开。这将解决网络问题，但会带来其他问题，例如，如果我更改数据库，这些更改也必须在我同事的工作副本上完成。
此外，我们一直在更改相同的文件，我们最不想要的就是每次更改时都修复文件冲突，然而不得不拉取另一个开发人员在白天所做的每一次提交，而且还必须做他们的数据库手动更改。
TL;DR，什么是与 3 个开发人员一起开发 1 个应用程序的好方法。
一个很好的改进肯定是在您自己的应用程序本地副本上运行。正如您所描述的那样，这将解决性能问题，但会给您带来有关数据库更新的问题。
管理数据库更新的一种方法是为每个数据库架构更改使用迁移文件。假设您进行了更改，您将此更改添加到一个新的迁移文件中，该文件被添加到 git 存储库中。有了这些文件，每个人都可以在他们的本地开发数据库之上应用所有迁移，以保持他们的数据库是最新的。它还使测试变得非常容易，因为您可以随时重置数据库并再次应用迁移。
你可以看看别人是怎么应用的。有开箱即用的后端框架（例如 Laravel 对应 PHP）。
我能想到的一个解决方案是使用像 git 这样的版本控制系统。在我看来，你希望所有人都在同一时间从事同一个项目，可能还从事相同的功能。
为了尽量减少合并冲突，我建议创建一个开发分支，并且对于每个功能，它应该从开发分支分支出来并隔离，直到有更新（有人合并或您完成了该功能并合并）。然后其他开发人员可以从 dev 中提取这些更改并继续他们的功能。
如果问题是基于环境的，您可以使用 JetBrains ides 中的 docker 功能来创建一个通用的工作环境。
在对原始回复添加评论后，我认为必须提供此作为答案：
- 正确使用git作为版本控制工具。通过让所有开发人员都在同一个资源上工作，您肯定没有利用版本控制的全部意义。让每个开发人员在他们自己的工作树上工作（如果你想保持这种方式，可以在本地或服务器上工作）这样他们就可以利用 git 的本地开发功能（创建自己的分支、快速操作、不要搞乱其他人正在做的事情），然后在准备就绪时将东西合并到上层开发分支中。这应该可以解决您的很多问题。
这是我的首要任务。
虽然我个人更喜欢使用 Git 及其分支，the deployment feature of PhpStorm could be a solution for you. So instead of using a network bound share, you can have a local copy which will be updated from the external resource. Here are the configuration tutorial and the tutorial 如何使其自动更新。
您应该将 GIT 存储库存储在集中位置，例如在 Github 中，或在您的本地服务器之一中。任何开发人员都可以 pull/push 更改 from/to 中央存储库并使用本地副本（无 SMB 网络）。
考虑使用 Docker 个容器。这将使你们拥有完全相同的开发环境。
可以使用数据库迁移来完成数据库更改。查看此库 doctrine/migrations。
https://www.atlassian.com/git/tutorials/comparing-workflows
注意它说的部分："Developers start by cloning the central repository. In their own local copies of the project, they edit files and commit changes as they would with SVN; however, these new commits are stored locally—they’re completely isolated from the central repository. This lets developers defer synchronizing upstream until they’re at a convenient break point."
我想，一旦你有了这个想法，接下来的事情就会接踵而至。
- 在签入之前始终从 master 和测试更新您的本地分支
- 经常打卡！一天多次。请参阅第 1 点。每次签入都应包含相关代码和 SQL 脚本代码（以及任何其他资源），并且应该编译并运行！
- 会发生合并冲突。没有魔杖，也没有策略。一般来说，尝试协调，以便开发人员通常在孤立的区域工作（这假定你的代码结构很好，可以这样做。这通常是个好主意，但这里的话题太大了）。我建议将更改保存在一个文件中，其中包含任何自动生成的代码，一次只提供给一个开发人员。 （这是经验！）。
- 所有数据库更改都应该是一个脚本，因此也是一个代码文件，在版本控制方面的处理方式与所有其他代码相同，开发人员应该在提交之前测试他们自己的本地数据库副本。您可能需要有人在发布前监督脚本，以查找冲突。您可以规定每个数据库对象（table、视图、sp）有一个脚本文件，这样更容易！