Drupal 6：在我的 Drupal 项目中使用 bitbucket.org 作为真正的版本控制系统虚拟
这是一个真正的版本控制系统假人！合适的新入门者！
到目前为止我的工作方式：
我有一个 Drupal-6 Web 项目 www.blabla.com 并在 www.blabla.com/beta 下进行开发。我直接在服务器上的 blabla.com/beta 上工作。我当地什么都没有，其他地方也没有。仅时不时地备份到本地。我知道可怕且不安全的方式：/
从现在开始我想要的新工作方式：
我决定使用Mercurial。我还有一位开发人员与我一起从事同一个项目。我在 bluehost 上有一个 blabla.com Drupal-6 项目，并在 blabla.com/beta 上进行开发。我发现 http://bitbucket.org/ 用于 Mercurial 托管。我已经创建了一个帐户。
那么现在我该如何设置呢？阅读数十篇文章后我完全困惑了：/
- bitbucket 仅用于托管修改后的文件？那么如果我或我的开发人员朋友编辑index.php，bitbucket 将仅托管index.php？
- 从现在开始，我必须在本地主机上工作并将更改上传到 blueshost 吗？不再直接在 blabla.com/beta 进行编辑吗？或者我仍然可以在 blabla.com/beta2 下的 bluehost 上工作吗？
- 当我需要编辑任何文件时，我是否首先从 bitbucket 下载更新，在本地主机上进行更改，更新编辑文件的 bitbucket，然后上传到 bluehost？
抱歉提出了愚蠢的问题，我真的需要指导......
感谢帮助很大！多谢！
Here is a real version control system dummy! proper new starter!
The way I have worked so far:
I have a Drupal-6 web project www.blabla.com and making development under www.blabla.com/beta . I'm directly working on blabla.com/beta on server. nothing at my local, nothing at anywhere else. Only taking backup to local, time to time. I know horrible and not safe way :/
The new way I want to work from now on:
I decided to use Mercurial. I have one more developer to work on same project with me. I have a blabla.com Drupal-6 project on bluehost and making development blabla.com/beta. I found out http://bitbucket.org/ for mercurial hosting. I have created an account.
So now how do I set up things? I'm totally confused after reading tens of article :/
- bitbucket is only for hosting revised files? so if I or my developer friend edit index.php, bitbucket will host only index.php?
- from now on do I have to work at localhost and upload the changes to blueshost? no more editing directly at blabla.com/beta? or can I still work on bluehost maybe under blabla.com/beta2?
- When I need to edit any file, do I first download update from bitbucket, I make my change at localhost, update bitbucket for edited files, and uploading to bluehost?
Sorry for silly questions, I really need a guidance...
Appreciate helps so much! thanks a lot!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
bitbucket 的主要服务是在修订控制下托管文件，但也有一种方法可以在那里存储任意文件。
在我的一个典型项目中，属于该产品的每个文件都被纳入修订控制，而不仅仅是index.php。 查看此示例
Mercurial 不规定修复工作流程。但我建议您在编辑文件的地方安装 Mercurial。例如，您可以直接查看自上次提交以来所做的更改，而无需将文件从服务器复制到本地存储库。
我绝对推荐一个工作流程，其中存储库中的某个位置有一个脚本，该脚本生成传输到服务器的存档文件，其中包含创建存档时存储库的修订版本。此修订信息也应该存储在服务器上的某个位置（不一定在公共可访问区域），因为当出现问题时此信息可以非常方便。
有几种不同的方法可以将数据获取到服务器：
hg archive production.tar.bz2），这是最安全的变体，因为它不依赖于服务器上的任何额外软件。此外，根据存档的大小，这种方法可能会浪费大量带宽。hg导出本地到生产区域hg fetchhg推送 从本地工作副本到服务器（然后在服务器上进行hg update）最后两点可以将存储库公开给公众。这种阐述可能有好有坏，具体取决于您的存储库包含的内容以及您是否想要共享内容。当您想要共享内容，或者可以限制访问www.blabla.com/beta/.hg时，您可以直接从网络服务器进行克隆。
另请注意，即使您对存储库进行了访问限制，您也不应该签入任何包含密码或关键机密的文件。签入模板文件（名称与生产中的名称不同）并在服务器上复制和编辑这些文件要节省得多。
The main service of bitbucket is to host files under revision control, but there is also a way to store arbitrary files there.
I a typical project every file which belongs to the product is cheked into revision control, not only index.php. see this example
Mercurial does not dictate a fix workflow. But I recommend that you have mercurial installed where you edit the files. For example then you can see direct which changes you did since the last commit, without to need to copy the files from your server to your local repository.
I absolutely recommend a workflow where somewhere in the repository is a script which generates the archive file which is transmitted to the server, containing the revision of the repository when the archive got created. This revision information should also be somewhere stored on the server (not necessarily in a public accessible area), since this information can get very handy when something went wrong.
There are several different approaches to get the data to the server:
hg archive production.tar.bz2), this is the most secure variant, since it does not depend on any extra software on the server. Also depending on how big the archive is this approach can waste lots of bandwidth.hg exportlocally there into the production areahg fetchfrom bitbucket(or any other server-accessible repository)hg pushfrom your local working copy to the server (andhg updateon the server afterwards)The last two points can expose the repository to the public. This exposition can be both good and bad, depending on what your repository contains, and if you want to share the content. When you want to share the content, or you can limit the access to www.blabla.com/beta/.hg, you can clone directly from your web server.
Also note that you should not check in any files with passwords or critical secrets, even when you access-limit the repository. It is much more save to check in template files (with a different name than in production), and copy-and-edit these files on the server.