在本地主机上使用源代码管理的基本逻辑 +水银
我是 Mercurial 的新手 - 实际上是源代码管理方面的新手。
我在本地主机上有项目，即 ~/mamp/htdocs。我想在本地工作。有一点我很困惑：
我应该将存储库保存在与我认为的 htdocs 不同的路径中，因此我创建了“/reps/”文件夹并为此处的每个项目创建文件夹，并从 htdocs 项目文件夹复制所有文件给代表。
例如；项目01
将文件从
~/mamp/htdocs/project01/复制到/reps/project01/
但我在 localhost (htdocs) 工作以更改文件等，那么如何将这些更改与 /reps/ 相关联？
显然我错过了一些关于源代码控制的非常明显的观点。难道我的开始就错了？
我想我在网上找到的所有教程都需要某种基础知识；他们都没有从零开始讲述任何事情！ :/
I'm pretty new at Mercurial - actually new at source control.
I have projects at localhost, which is ~/mamp/htdocs. I want to work all local. There is a point I'm confused about:
I should keep repository at a different path than my htdocs I think, so I created "/reps/" folder and creating folders for each project under here, and copy all files from htdocs project folder to reps.
for example; project01
copy files from
~/mamp/htdocs/project01/to/reps/project01/
But I work at localhost (htdocs) for changing files, etc. so how do I relate these changes to /reps/?
Obviously I'm missing some very obvious point about Source Control. Did I make a wrong start?
All the tutorials I found online requires some kind of base knowledge, I guess; none of them tells anything from meaning zero point! :/
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
最简单的方法是，如果您想在
~/mamp/htdocs/project01/中编辑文件（因为我也同意拥有某种可以测试更改的暂存区域会很好）在将它们部署到生产服务器之前，但也许正是您的计算机是暂存区域，所以一切都可以:-)) 是：cd ~/mamp/htdocs/project01/hg inithg add *.html subdir *.css（无论你想管理什么）hg commit -m"initial version"之后完成
hg init后，~/mamp/htdocs/project01/下的.hg目录中有一个存储库！使用 hg 不可能（至少）避免这种情况：如果您在project01中有源代码，则需要在project01中有一个存储库。这已经足够了，因为您可以从版本控制中受益，只要您更改文件，您就可以提交它并给出一条日志消息来告诉系统您做了什么，例如hg status（会告诉你当前修改的文件）hg diff（会告诉你与保存版本的差异）hg commit -m"what-has-changed-message"（保存新版本）即使没有必要在其他地方（例如，在 /reps 中）拥有另一个存储库（如果您想要） ，例如要将您的数据保存在备份区域中，那么您只需在 $HOME 中克隆该数据即可：
cd /repshg clone /home/name/mamp/htdocs/project01/ project01这将在
/reps/project01中获得您所做操作的精确副本：所有更改和所有日志消息。现在，如果您这样做，每当您执行"hg commit"来保存主存储库中的更改时，您还需要执行"cd /reps/project01"和 < code>"hg pull" 以便将更改转发到 /reps（如果您希望它保持同步）。希望它足够简单..
The simplest way, if you want to edit your files in
~/mamp/htdocs/project01/(because I also agree that it would be good to have some kind of staging area where you could test your changes before deploying them to the production server, but maybe it is precisely your machine which is the staging area, so everything's ok then :-)) is to:cd ~/mamp/htdocs/project01/hg inithg add *.html subdir *.css(whatever you want to manage)hg commit -m"initial version"After you have done
hg init, there is a repository in a.hgdir under~/mamp/htdocs/project01/! It is not possible to avoid this (yet at least) with hg: if you have sources in project01 you need to have a repo in project01. And it's sufficient because you can benefit from version control with just that, whenever you change a file, you can commit it and give a log message to tell the system what you have done, e.g.,<edit> a.htmlhg status(will tell you the currently modified files)hg diff(will tell you the differences with the saved version)hg commit -m"what-has-changed-message"(save a new version)Even if it is not necessary to have another repo elsewhere (e.g., in /reps) if you want to, for instance to have your data in a backuped zone, then you could just clone the one in $HOME:
cd /repshg clone /home/name/mamp/htdocs/project01/ project01Which will get in
/reps/project01an exact copy of what you have done: all your changes and all your log messages. Now if you do that, whenever you do"hg commit"to save a change in your primary repo, you also need to do"cd /reps/project01"and"hg pull"in order to forward the changes to /reps if you want it to stay synchronized.Hope it is simple enough..
有许多不同的途径/方法。以下是我的工作方式：
开发：我将文件检查（在 Mercurials 情况下克隆）到我的“开发环境”以对其进行处理，然后提交/推送等。
下一阶段：一旦我认为他们已准备好进行用户测试/生产/或无论您的下一阶段是什么，那么您可以将代码作为
2a。包（可以是最新文件的简单 zip）或
2b。将它们签入下一阶段目录。
其他用法：一旦您熟悉了主要使用场景，那么您应该考虑其他修订控制用法，例如标记、分支和合并
There are many different approaches / methods. Here is how I work:
Development: I check (clone in mercurials case) out my files to my 'development environment' to work on them then commit/push/etc. at the same place.
Next Stages: Once I think they are ready for user testing / production / or whatever your next stage is, then you can either distribute your code as a
2a. package (could be a simple zip of your latest files) or
2b. check them out into that next stage directory.
Other Usages: Once you are comfortable working with the main use scenarios, then you should consider other revision control usages like tagging, branching and merging
通常，您应该将 VCS（版本控制系统）及其文件与生产 Web 服务器环境分开（鉴于提到了 htdocs，我推断您正在询问这个问题）。
许多（至少是旧时代的）网络系统都有一个暂存区域，您可以在其中从源系统复制材料，您可以使用第二个（不可公开访问的）网络服务器仔细检查。当您确信代码正确时，您可以将其投入生产。
该场景分为三个区域：
听起来有点像是您将这三者混为一谈——这是我有限经验中的常见情况。即使您决定不使用临时区域，您也确实需要将开发系统和生产系统分开。工作区域使用VCS（Mercurial）。
You should normally keep your VCS (version control system) and its files separate from your production web server environment (which is what I infer you are asking about given the mention of htdocs).
Many (at least old time) web systems have a staging area where you copy the material from the source system, which you can check carefully using a second (not publicly accessible) web server. When you're confident that the code is correct, you can move it into production.
This scenario has three areas:
It sounds a bit as if you are conflating these three - a common scenario in my limited experience. Even if you decide to do without the staging area, you do need to separate your development and production systems. And the VCS (Mercurial) is used in the working area.