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

Proper Way To Use Git/GitHub - PHP System with Dev/Testing/Production servers

提问by Kerry Jones

I apologize if this is obvious or easy, I have looked at a good number of git/github tutorials and read other articles, but I want to make sure what I'm doing is right.

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

I want to incorporate VC (for obvious reasons) into my development team and process.

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

Current development process (using Dreamweaver):
* Receive a ticket (or work order)
* Download file on Development server
* Make changes to the file
* Upload file back to development server
* Changes tested/verified
* Send to production server

当前的开发过程（使用 Dreamweaver）：
* 接收工单（或工作订单）
* 在开发服务器上下载文件
* 对文件进行更改 * 将文件
上传回开发服务器
* 测试/验证的更改
* 发送到生产服务器

---

---

I'm trying to figure out how to make our new development process with using Git.

我试图弄清楚如何使用 Git 来完成我们的新开发过程。

I am switching over to PHPStorm (which is an actual PHP IDE with direct integration with Git).

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

Would it be something like

会不会像

• Receive a ticket (or work order)
• Checkout/Update/Download file(s)
• Change Files
• Upload file (which I assume is also the current working directory...?)
• At the end of the day, do a commit
• Have build script send data to testing server (nightly build)

• 收到一张票（或工单）
• 签出/更新/下载文件
• 更改文件
• 上传文件（我认为这也是当前的工作目录......？）
• 在一天结束时，做一次提交
• 让构建脚本将数据发送到测试服务器（每晚构建）

Or would it be better to do something like

或者做类似的事情会更好

• Receive a ticket (or work order)
• Checkout/Update/Download file(s)
• Change Files
• Upload file/commit
• Have build script send data to testing server (nightly build)

• 收到一张票（或工单）
• 签出/更新/下载文件
• 更改文件
• 上传文件/提交
• 让构建脚本将数据发送到测试服务器（每晚构建）

Or is there another way? Having a bit of trouble understanding what would be the optimal flow?

或者还有其他方法吗？在理解什么是最佳流程时遇到了一些麻烦？

Any help would be greatly appreciated.

任何帮助将不胜感激。

---

---

Edit

编辑

I'm trying see if it is best to have a version of the server locally (every developer), and if so, how does that work if you have 7 or so branches?

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

If not, how do you deal with 7 or so branches with them on the web? Do you FTP files up or use Git Hooks to make them auto update?

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

Update 07/26/2012

2012 年 7 月 26 日更新

After working successfully with Git for quite a while now I've been following this branching model with great success: A Successful Git Branching Model

在成功地使用 Git 工作了很长一段时间之后，我一直在遵循这个分支模型并取得了巨大的成功： 一个成功的 Git 分支模型

The answer to the above was yes -- should definitely have a local version of the server.

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

回答by hoppa

Assuming you have a live server and a development server I would do something along these lines.

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

Before even starting with a development cycle I would at least have two branches:

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

1. Master - the development server runs on this branch
2. Stable - the live server runs on this branch.

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

So if a developer gets a ticket or a work order he/she will perform the following actions:

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

1. git pull origin master
2. git branch featureBranch (named as the ticket id or as a good description for the work order)
3. git checkout featureBranch
4. Make changes which will accomplish the desired change. Commit as often as is necessary. Do this because you will create valuable history. For instance you can try an approach to a problem and if it doesn't work, abandon it. If a day later you see the light and want to re-apply the solution, it is in your history!
5. When the feature is fully developed and tested locally, checkout master.
6. git merge featureBranch
7. git push origin master
8. Test the pushed changes on your development server. This is the moment to run every test you can think of.
9. If all is working out, merge the feature or fix into the stable branch. Now the change is live for your customers.

1. git pull 原点大师
2. git branch featureBranch（命名为工单 ID 或作为工作订单的良好描述）
3. git checkout 功能分支
4. 进行更改以实现所需的更改。根据需要经常提交。这样做是因为您将创造宝贵的历史。例如，你可以尝试一种解决问题的方法，如果它不起作用，就放弃它。如果一天后您看到了曙光并想重新应用该解决方案，那就是您的历史！
5. 当该功能在本地完全开发和测试后，结帐 master。
6. git合并功能分支
7. git push origin master
8. 在您的开发服务器上测试推送的更改。这是运行您能想到的每个测试的时刻。
9. 如果一切正常，请将功能或修复合并到稳定分支中。现在，您的客户可以进行更改。

Getting the code on the server

在服务器上获取代码

The updating of servers shouldn't be a problem. Basically I would set them up as users just like you're developers are. At my company we've setup the servers as read-only users. Basically that means the servers can never push anything but can always pull. Setting this up isn't trivial though, so you could just as well build a simple webinterface which simply only allows a git pull. If you can keep your developers from doing stuff on live implementations you're safe :)

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

[EDIT]

[编辑]

In response to the last questions asked in the comments of this reaction:

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

I don't know if I understand your question correctly, but basically (simplified a bit) this is how I would do this, were I in you shoes.

我不知道我是否正确理解了您的问题，但基本上（稍微简化）这就是我会这样做的方式，如果我是您的话。

The testing machine (or the webroot which acts as testing implementation) has it source code based in a git repository with the master branch checked out. While creating this repository you could even remove all other references to all other branches so you'll be sure no can checkout a wrong branch in this repository. So basically the testing machine has a Git repository with only a master branch which is checked out.

测试机器（或充当测试实现的 webroot）的源代码基于 git 存储库，并检出 master 分支。在创建此存储库时，您甚至可以删除对所有其他分支的所有其他引用，这样您就可以确保没有人可以在此存储库中检出错误的分支。所以基本上测试机器有一个 Git 存储库，只有一个主分支被检出。

For the live servers I would do exactly the same, but this time with the stable branch checked out. Developer should have a local repository cloned in which all branches exist. And a local implementation of the software you guys build. This software gets its source from a the local git repository. In other words: from the currently checked out branch in this repository.

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

Actual coding

实际编码

When a new feature is wanted, a local feature branch can be made based on the current master. When the branch is checked out the changes can be made and checked locally by the developer (since the software is now running on the source of the feature branch).

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

If everything seems to be in order, the changes get merged from feature branch to master and pushed to your "git machine". "your github" so to speak. Testing can now pull the changes in so every test necessary can be done by QA. If they decide everything is ok, the developer can merge the changes from master to stable and push again.

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

All thats left now is pulling form your live machines.

现在剩下的就是拉动您的现场机器。