php - 使用 Git/GitHub 的正确方法 - 带有开发/测试/生产服务器的 PHP 系统

Question

如果这很明显或很容易，我深表歉意，我已经查看了大量的 git/github 教程并阅读了其他文章，但我想确保我所做的是正确的。

我想将 VC(出于显而易见的原因)纳入我的开发团队和流程。

目前的开发过程(使用Dreamweaver):
* 收到工单(或工单)
* 在开发服务器上下载文件
* 修改文件
* 将文件上传回开发服务器
* 更改测试/验证
* 发送到生产服务器

---

我正在尝试弄清楚如何使用 Git 来制定我们的新开发流程。

我正在切换到 PHPStorm(这是一个与 Git 直接集成的实际 PHP IDE)。

会不会是这样的

• 收到工单(或工单)
• checkout /更新/下载文件
• 更改文件
• 上传文件(我假设它也是当前工作目录...？)
• 在一天结束时，做一个 promise
• 让构建脚本将数据发送到测试服务器(每晚构建)

或者做类似的事情会更好吗

• 收到工单(或工单)
• checkout /更新/下载文件
• 更改文件
• 上传文件/提交
• 让构建脚本将数据发送到测试服务器(每晚构建)

或者有别的办法吗？难以理解什么是最佳流程？

如有任何帮助，我们将不胜感激。

---

编辑

我正在尝试查看是否最好在本地(每个开发人员)拥有一个服务器版本，如果是这样，如果您有 7 个左右的分支机构，那将如何工作？

如果没有，您如何在网络上与他们处理 7 个左右的分支？您是通过 FTP 上传文件还是使用 Git Hooks 让它们自动更新？

2012 年 7 月 26 日更新

在成功使用 Git 一段时间后，我一直在遵循这个分支模型并取得了巨大成功: A Successful Git Branching Model

上面的答案是肯定的——绝对应该有一个本地版本的服务器。

Answer 1

假设您有一个实时服务器和一个开发服务器，我会按照这些思路做一些事情。

在开始开发周期之前，我至少会有两个分支:

1. Master - 开发服务器运行在这个分支上
2. 稳定 - 实时服务器在此分支上运行。

因此，如果开发人员获得工单或工单，他/她将执行以下操作:

1. git pull origin master
2. git branch featureBranch(命名为工单 id 或作为工单的良好描述)
3. git checkout 功能分支
4. 进行更改以完成所需的更改。尽可能多地提交。这样做是因为您将创造宝贵的历史。例如，您可以尝试解决问题的方法，如果不起作用，请放弃它。如果一天后您看到了曙光并想重新应用该解决方案，那您的历史就在眼前!
5. 当功能在本地完全开发和测试后，checkout master。
6. git merge 功能分支
7. git push origin master
8. 在您的开发服务器上测试推送的更改。现在是运行您能想到的所有测试的时刻。
9. 如果一切正常，请将功能 merge 或修复到稳定分支。现在，更改已为您的客户生效。

获取服务器上的代码

服务器的更新应该不是问题。基本上，我会将它们设置为用户，就像您是开发人员一样。在我的公司，我们将服务器设置为只读用户。基本上这意味着服务器永远不能推送任何东西，但总是可以 pull 。不过，设置它并非易事，因此您也可以构建一个简单的 web 界面，它只允许 git pull。如果您可以阻止您的开发人员在实时实现上做任何事情，那么您是安全的:)

[编辑]

针对此 react 的评论中提出的最后一个问题:

我不知道我是否正确理解了您的问题，但基本上(简化了一点)这就是我会这样做的方式，如果我是你的话。

测试机器(或作为测试实现的 webroot)拥有基于 git 存储库的源代码，其中 master 分支已 checkout 。在创建此存储库时，您甚至可以删除对所有其他分支的所有其他引用，这样您就可以确定没有人可以在此存储库中 checkout 错误的分支。所以基本上测试机器有一个 Git 存储库，只有一个被 check out 的主分支。

对于实时服务器，我会做同样的事情，但这次是 checkout 稳定的分支。开发人员应该克隆一个本地存储库，其中存在所有分支。以及你们构建的软件的本地实现。该软件从本地 git 存储库获取其源代码。换句话说:来自此存储库中当前 checkout 的分支。

实际编码

当需要一个新特性时，可以基于当前的master做一个本地特性分支。 checkout 分支后，开发人员可以在本地进行更改和检查(因为软件现在在功能分支的源上运行)。

如果一切似乎都井井有条，更改将从功能分支 merge 到主分支并推送到您的“git 机器”。 “你的 github”可以这么说。测试现在可以 pull 入更改，因此每个必要的测试都可以由 QA 完成。如果他们认为一切正常，开发人员可以将更改从 master merge 到 stable 并再次推送。

现在剩下的就是从你的现场机器中 pull 出。