PHP Web 项目的版本控制
我们有一个 PHP 项目，我们想要对其进行版本控制。 现在，我们三个人正在开发该项目的开发版本，该版本位于一个外部文件夹中，我们所有的 Eclipse IDE 都链接到该文件夹，因此没有版本控制。
版本控制的正确方法和最佳方法是什么？
我们已经设置了 SVN，但我们只需要找到一种签入和签出的好方法，以便我们可以在开发服务器上进行测试。 有任何想法吗？
We have a PHP project that we would like to version control. Right now there are three of us working on a development version of the project which resides in an external folder to which all of our Eclipse IDEs are linked, and thus no version control.
What is the right way and the best way to version control this?
We have an SVN set up, but we just need to find a good way to check in and out that allows us to test on the development server. Any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
您可以用于构建的另一个工具是 TeamCity，它免费提供 20 种构建配置（足以满足大多数人的需要）小公司/项目。）这样您就可以运行测试并安排构建。
Another tool you can use for the builds is TeamCity which is free for 20 build configurations (enough for most small companies/projects.) This way you can run your tests as well as schedule builds.
Beanstalk 具有内置的提交后挂钩，用于部署到开发、登台和生产服务器。
Beanstalk has built-in post-commit hooks for deploying to development, staging, and production servers.
使用 Subversion 进行 PHP 开发的一种方法是为一个或全部三个开发人员设置一个存储库，并使用此存储库，更多地作为同步工具，而不是真正的版本控制。
您可以，
创建一个存储库
添加项目的整个 PHP 文档结构
签出此存储库的副本到您的开发服务器上的正确位置
使用 svn 钩子，在提交时激活
这个钩子，每当团队中的任何人签入任何代码时，都会自动更新开发服务器的内容。
钩子位于：
可能看起来像：
这会将开发服务器上的工作副本更新为最新签入。
One way to use subversion for PHP development is too setup a repository for one or all three developers, and use this repository, more as a syncing tool, than true version control.
You could,
Make a repo
Add your entire PHP document structure of your project
Checkout a copy of this repo into the correct spot on your dev server
Use an svn hook, that activates on commit
This hook, will automatically update the contents of the dev sever, whenever anybody on the team checks in any code.
Hook resides in:
And could look like:
That will update your working copy on the dev server to the latest check in.
分布式的东西怎么样？ 例如，您可以从 Mercurial 开始，尝试不同的工作流程，然后看看哪一个最适合您。
What about something distributed? You can start for example with Mercurial, try different workflows, and see which one fits you the best.
你们每个人都可以在本地运行它，或者在您自己的开发服务器上运行它（甚至是具有不同端口的同一服务器......）。
Each of you could run it locally, or on your own dev server (or even the same one with a different port...).
一种可能的方法（可能有更好的方法）：
你们每个人都应该有自己的项目签出版本。
在您的计算机上拥有服务器的本地副本并全天在那里进行测试。 然后在每天结束时（或任何时候），您将准备测试的所有内容合并在一起，然后将其签出到开发服务器上并进行测试。
One possible way (there are probably better ways):
Each of you should have your own checked out version of the project.
Have a local copy of the server on your computer and test it there throughout the day. Then at the end of each day (or whenever), you merge together whatever you are ready to test, and you check it out onto the dev server and test it.
我们的做法如下：
在项目开始时，用户创建一个分支并在其个人虚拟机上检查它，并获取数据库的干净副本。 他们做自己的工作，边走边承诺。
一旦他们在自己的个人空间中完成了所有事情，他们就会登录到集成服务器并检查他们的分支，运行他们的测试等。当所有通过的分支都被合并到主干中。
重建主干，运行全套测试，如果一切顺利，它就会获得批准，在 SVN 中标记，并在晚上结束时升级到生产环境。
如果其他人在任何时候进行了提交，我们都会收到一封电子邮件，并且可以将这些更改合并到我们单独的分支中。
Here is what we do:
At the beginning of a project, the user makes a branch and checks it out on their personal VM as well as grabs a clean copy of the database. They do their work, committing as they go.
Once they have finished everything in their own personal space they log into the integration server and check out their branch, run their tests, etc. When all that passes their branch is merged into Trunk.
Trunk is rebuilt, the full suite of tests are run, and if all is good it gets the big ol' stamp of approval, tagged in SVN, and promoted to Production at the end of the night.
If at any point a commit by someone else is made, we get an e-mail and can merge those changes into our individual branches.
我们遇到了类似的情况，这就是我们最终所做的：
您还可以在每个团队成员的工作站上设置单独的开发服务器。 我发现它加快了速度，尽管您确实有更多的设置时间。
我们必须使用单个开发服务器，因为我们使用专有的 CMS 并遇到了许可问题。 所以我们的提交后挂钩是一个简单的 FTP 机器人。
We were in a similar situation, and here's what we ended up doing:
You can also set up individual development servers for each of the team members, on their workstations. I find that it speeds things up a bit, although you do have some more setup time.
We had to use a single development server, because we were using a proprietary CMS and ran into licensing issues. So our post-commit hook was a simple FTP bot.