实施 Web 开发的版本控制
随着我的项目变得越来越大，我正在尝试转向版本控制。目前我的开发是这样的：
- 我有在线托管的“实时”版本
- 我有一个本地版本，以及一个本地网络服务器
- 我编辑本地版本并在本地网络服务器上进行测试
- 最后，我将运行 Unison 从我的本地版本更新实时版本（以及用实时版本的任何更改）
我的本地平台是Gentoo，Linux。我对 SVN 进行了一些研究，但我认为它可能不适合我的需求，因为我的本地网络服务器（和 Unison）只能访问当前签出的代码，等等。我可能是错的，但我对此了解不多。
有人可以引导我对现有代码设置某种版本控制，这将导致本地网络服务器可以访问最新版本，并且不会影响未编辑文件的访问时间吗？ （我不希望每次更改时 Unison 都会上传每个文件）
I'm trying to make the move into version control, as my projects are getting larger. Currently my development goes something like this:
- I have the "live" version hosted online
- I have a local version, as well as a local webserver
- I edit the local version and do testing on my local webserver
- Finally, I'll run Unison which updates the live version from my local version (as well as updating my local version with any changes to the live version)
My local platform is Gentoo, Linux. I've looked a little into SVN, but I think it might not suit my needs, in that my local webserver (and Unison) would only be able to access currently checked-out code, and so on. I might be wrong, but I don't know very much about this.
Could someone please walk me through setting up some kind of version control on existing code, which would result in the latest version being accessible to a local webserver and which doesn't clobber access times for unedited files? (I don't want Unison uploading every single file every time I make a change)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
扩展@Nathon 的答案。您想要执行的操作：
在 ~/code 中进行开发，并使用本地服务器进行检查。只要你愿意，就可以承诺。当你得到有用的东西时，标记它。然后执行：
我的印象是您还希望本地服务器从暂存区域运行，但这似乎是一个坏主意，因为您想使用它来检查您的工作。如果你想要某种 QA 环境，你可以从 staging 运行第二个网络服务器，但我只会在开发之外而不是优先这样做。
To expand on @Nathon's answer. You want to do:
Do your development in ~/code, checking it with your local server. Commit whenever you like. When you get something that works, tag it. Then do:
I get the impression that you also want your local server to run from the staging area, but this seems like a bad idea, since you want to use it to check your work as you go along. If you want a sort of QA environment, you could run a second webserver from staging, but i would only do that in addition to, not in preference to, dev.
Mercurial 风格：
这将为您提供一个可用的 Mercurial 存储库。阅读链接以获取有关如何使用它的更多信息。
您可以从本地 Web 服务器和实时 Web 服务器进行克隆，以保持最新状态。
Mercurial style:
That will get you a working mercurial repository. Read the link for more info on how to use it.
You can clone from your local web server and your live web server to keep things up to date.
这是我当前的设置，我相信你可以做类似的事情：
我使用 SVN，它托管在主服务器上。有两台服务器，开发服务器和生产服务器。我在开发服务器上的结帐上完成所有工作编辑，然后当更改准备好上线时，我将它们提交，然后更新生产服务器（即实时站点）上的结帐。
Here's my current setup, i'm sure you could do something similar:
I use SVN, which is hosted on the main server. There are two servers, development and production. I do all of my work editing on a checkout on the development server, then when changes are ready to go live, I commit them up, and then update the checkout on the production server, which is the live site.
我为此使用了 subversion，效果很好。
通常我会继续开发，直到我清理了一些东西以便发布。
那时，我将创建一个名为release-之类的分支。我将跳上生产系统并检查我新创建的分支。对于几个项目，我将有一个在生产系统上运行的暂存区域。
例如，我可能有一个如下所示的目录树：
“stage”和“live”是符号链接，并且是 Apache 对于虚拟主机 www.example.com 和 stage.example.com 的 DocumentRoot 的内容）
此设置允许我在实际生产环境中非常仔细地测试，然后通过交换符号链接进行切换。
通过在部署之前进行分支，我可以在极少数需要这样做的情况下对生产进行紧急修复。然后，只要方便且合适，我就可以将这些更改合并回主干。
最后一点提示：如果您在生产环境中使用 subversion 项目的工作副本，则需要阻止 apache 允许人们浏览项目中的 .svn 目录：
在 httpd.conf 中：
I use subversion for this, and it works well.
Typically I develop away, until I have something cleaned up for a release.
At that point, I'll create a branch named something like release-. I'll hop on the production system and check out my newly created branch. For several projects, I'll have a staging area that runs on the production system.
For instance, I might have a directory tree that looks like this:
"stage" and "live" are symbolic links, and are what Apache has for DocumentRoot for virtualhosts www.example.com and stage.example.com)
This setup allows me to test things pretty carefully in the actual production environment, and then cut over by swapping symlinks.
By branching before deployment, I can make emergency fixes on production in the rare case I need to do so. I can then merge those changes back to the trunk whenever it's convenient and appropriate.
One last tip: If you use working copies of subversion projects in a production environment, you need to keep apache from allowing people to browse the .svn directories in your project:
in httpd.conf: