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

Question

我很抱歉,如果这很明显或很容易,我已经看了很多git/github教程并阅读了其他文章,但我想确保我所做的是对的.

我想将VC(出于显而易见的原因)合并到我的开发团队和流程中.

当前开发过程(使用Dreamweaver):
*接收票证(或工作单)
*在开发服务器上下载文件
*对文件进行更改
*将文件上载回开发服务器
*更改已测试/验证
*发送到生产服务器

---

我正试图弄清楚如何使用Git进行新的开发过程.

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

它会是什么样的

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

或者做一些类似的事情会更好

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

或者还有另一种方式吗？理解什么是最佳流程有点麻烦？

任何帮助将不胜感激.

---

编辑

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

如果没有,你如何在网上处理7个左右的分支？你是FTP文件还是使用Git Hooks使它们自动更新？

更新07/26/2012

在与Git成功合作了很长一段时间后,我一直在关注这个分支模型取得了巨大的成功: 一个成功的Git分支模型

上面的答案是肯定的 - 应该有一个本地版本的服务器.

Answer 1

假设你有一个实时服务器和一个开发服务器,我会沿着这些方向做点什么.

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

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

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

1. git pull origin master
2. git branch featureBranch(命名为故障单ID或作为工单的良好描述)
3. git checkout featureBranch
4. 进行更改以完成所需的更改.尽可能经常地提交.这样做是因为您将创造有价值的历史.例如,您可以尝试解决问题的方法,如果它不起作用,请放弃它.如果一天之后您看到了灯光并希望重新应用解决方案,那么它就在您的历史中!
5. 当该功能在本地完全开发和测试时,结帐主人.
6. git merge featureBranch
7. git push origin master
8. 测试开发服务器上推送的更改.这是运行您能想到的每个测试的时刻.
9. 如果一切正常,请将功能合并或修复到稳定分支.现在,改变对您的客户来说是现实的.

获取服务器上的代码

服务器的更新应该不是问题.基本上我会像用户一样将它们设置为开发人员.在我的公司,我们将服务器设置为只读用户.基本上这意味着服务器永远不会推送任何东西,但总能拉动.尽管如此,设置它并不是一件容易的事,所以你也可以构建一个简单的web界面,它只允许git pull.如果你可以让你的开发人员在现场实施中做些什么,你就安全了:)

[编辑]

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

我不知道我是否正确地理解了你的问题,但基本上(简化了一点)这就是我如何做到这一点,如果我在你的鞋子里.

测试机器(或作为测试实现的webroot)具有基于git存储库的源代码,其中检出了主分支.在创建此存储库时,您甚至可以删除对所有其他分支的所有其他引用,这样您就可以确定无法检出此存储库中的错误分支.所以基本上测试机器有一个Git存储库,只有一个主分支被检出.

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

实际编码

当需要新功能时,可以根据当前主设备创建本地功能分支.签出分支时,开发人员可以在本地进行更改并进行检查(因为软件现在在功能分支的源上运行).

如果一切看起来都是有序的,那么更改会从功能分支合并到主分支并推送到您的"git机器"."你的github"可以这么说.测试现在可以进行更改,因此每个必要的测试都可以通过QA完成.如果他们认为一切正常,开发人员可以将更改从master合并到stable并再次推送.

现在剩下的就是拉动你的现场机器了.