Git / Rails / 共享主机 (Dreamhost) 工作流程
这主要是关于有效使用 Git 的问题。 首先我应该说，我不是 Rails 方面的专家（至少在生产意义上），而且绝对是 Git 新手，但是，我有一些使用 SVN 的经验。
我的问题是，我正在尝试创建一个 Rails 应用程序，但不知道在我的计算机上保持本地开发但能够部署到 Dreamhost 上的共享托管帐户的最佳方法。
我认为 Git 可以让我做到这一点，但我不完全确定如何做。 我正在考虑在服务器上创建一个 Git 存储库，并在每次提交后将本地内容推送到它上面。 我已经阅读了一些关于 Git 的教程，但仍然对该怎么做感到困惑。 另一种方法是仅使用 FTP 并复制文件，但这似乎不对。
有人有我可以使用的一些初步步骤和/或命令吗？ 这种部署方法是否可疑或者是否有更好的方法来做到这一点？
This is primarily a question about effective Git usage. I should first say I'm not an expert in Rails (at least in a production sense) and definitely a Git newbie, however, I have had some experience using SVN.
My problem is that I am trying to create a rails application but do not know the best way to keep development local on my computer but be able to deploy to my shared hosting account on Dreamhost.
I figured that Git would allow me to do this, but I am not completely sure how. I was thinking of creating a Git repo on the server and having my local stuff pushed onto it after each commit. I have read a few tutorials on Git, but am still confused on what to do. The alternative to this would be to just use FTP and copy over the files but that doesn't seem right.
Does anybody have a few first steps and/or commands that I can use? Is this deployment method fishy or is there a better way to do this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我为 威斯康星州的铜管乐队 运行一个 Rails 网站，其设置与您所描述的内容，尽管它目前在 Hostingrails.com 之外运行。 我将我的代码托管在 GitHub 上，但您没有理由不能托管我的代码不要私下主持它。 我的流程在过去一年半中不断发展，因此仅从中获取您短期内需要的内容。
在流程的中心，我设置了 一个半复杂的 Capistrano 脚本来处理部署，包括 一个单独的临时环境，用于制作生产数据库的完整副本以进行测试。 这花了一些时间（几个小时，而不是几天）来构建，但它是非常值得的。
我的工作流程保持至少 2 个分支：
current_release： 实时生产代码。 此处进行了紧急错误修复。master：已完成的功能已准备好发布。 这些功能在这里等待现场测试。 紧急错误修复已从current_release合并进来。master以保持功能最新。有了这个设置，我就可以同时处理几件事。 每周（因为这远不是全职工作），我会执行以下操作：
我在功能分支中进行编辑。 我来回切换，感到无聊，感到兴奋，等等。 有时我会合并两个共同发展的功能。
<代码>
[编辑]
$ git 提交
$ git Push github [功能]
准备好立即部署的已完成功能将一次合并到
master分支。<代码>
$ git checkout master
$ git merge [功能]
[修复当前问题或不一致]
$ git 提交
$ git push github master
$ git 分支 -d [功能]
我将网站暂存到私有 URL（恰好是 stage.madisonbrass.com）。 登台环境始终从
master分支中提取。<代码>
$ cap staging deploy #
master现已在 stage.madisonbrass.com 上线Bam，当我测试时，我在公共网站上发现了一个紧急错误。 幸运的是，我有
current_release单独工作，因此可以单独修复和部署它。<代码>
$ git checkout current_release
[修复错误]
$ git 提交
$ git push github current_release
$上限生产部署
我返回到
master分支，并从合并紧急修复开始。<代码>
$ git checkout master
$ git 合并 current_release
我继续测试
master。 希望不会出现新问题，但如果出现了，我会在 master 中修复这些问题，并将这些更改合并到current_release中，并进行另一个生产部署。<代码>
$ git checkout current_release
$ git 合并大师
$ git push github current_release
$上限生产部署
我拆除了我的临时环境，以免它以某种方式被搜索引擎索引。
<代码>
$ git 暂存拆解
I run a Rails website for a brass band in Wisconsin in a very similar setup to what you're describing, though it currently operates out of hostingrails.com. I host my code on github, though there's no reason you couldn't host it privately. My flow has evolved over the last year and a half, so take from this only what you need in the short term.
At the center of my flow, I have set up a semi-elaborate Capistrano script to handle the deployment, including a separate staging environment that makes a whole copy of the production database for testing. This took a while (hours, not days) to build, but it has been so worth it.
My workflow keeps at least 2 branches:
current_release: Live production code. Emergency bugfixes are made here.master: Finished features ready for release. These features wait here to be tested live. Emergency bugfixes are merged in fromcurrent_release.<feature_name>: Features under development. I try not to have more than 3 of these outstanding at any given time. Emergency bugfixes are merged in, andmasteris frequently merged in to keep the feature current.Having this setup allows me to work on several things concurrently. Week-to-week (as this is nowhere near a full-time occupation), I do the following:
I edit in feature branches. I switch back and forth, get bored, get excited, whatever. Sometimes I merge two features that grow together.
[edit]
$ git commit
$ git push github [feature]
Finished features ready for iminent deployment are merged one-at-a-time to the
masterbranch.$ git checkout master
$ git merge [feature]
[fix immediate problems or inconsistencies]
$ git commit
$ git push github master
$ git branch -d [feature]
I stage the website to a private URL (happens to be stage.madisonbrass.com). The staging environment always pulls from the
masterbranch.$ cap staging deploy #
masteris now live at stage.madisonbrass.comBam, while I'm testing, I find an emergency bug on the public website. Fortunately, I have
current_releaseworking separately, and thus can separately fix and deploy it.$ git checkout current_release
[fix bug]
$ git commit
$ git push github current_release
$ cap production deploy
I return to the
masterbranch, and start by merging the emergency fix.$ git checkout master
$ git merge current_release
I continue testing
master. Hopefully no new issues appear, but if they do I fix them in master, I merge these changes intocurrent_releaseand do another production deployment.$ git checkout current_release
$ git merge master
$ git push github current_release
$ cap production deploy
I tear down my staging environment, lest it somehow get indexed by a search engine.
$ git staging teardown
我所做的是拥有一个共享的裸 Git 存储库（使用 git init --shared --bare 创建），它是“主”存储库，也是我推动工作的地方。 裸存储库没有工作目录。 对于我的 Web 目录，我克隆了主存储库，因此它有一个工作目录并且所有文件都在那里。 从那里，我
git pull我已经提交的任何新工作。我总是在具有存储库克隆和测试开发环境的单独计算机上进行开发工作。 当我完成一个功能时，我将其推送到主服务器，然后登录到生产服务器并将其拉到那里的工作目录。
这只是我的一些不太重要的项目。 人们可以通过更多的步骤以及对重要工作的制衡来扩展这一点。
What I do is have a shared, bare Git repository (created with
git init --shared --bare) which is the "master" repository and is where I push my work. A bare repository does not have a working directory. For my web directory, I clone the master repository so it has a working directory and all the files are there. From there, Igit pullany new work that I've committed.I always do development work on a separate machine with a clone of the repository and a test development environment. When I've finished a feature, I push it up to the master and then log in to the production server and pull it to the working directory there.
This is just me for not-terribly-important projects. One could extend this with many more steps and checks and balances for Important Work.
我建议使用 GitHub 并尽可能免费地保留 Dreamhost 资源来运行 Rails 应用程序（事实上，根据您的项目，我需要尽可能多的资源来配合它，作为共享托管） 。
我通常的工作流程涉及拥有一个开发环境和一个 GitHub 帐户。 我们使用 Capistrano（相当容易学习和理解）来管理对 GitHub 的推送，然后通过 SSH/SCP 分别部署到托管（在您的示例中为 Dreamhost）。
这样，您就不必担心生产存储库中的实际内容，也不必对其执行维护任务。 工作速度也非常快，并且当您决定更改服务器托管时可以轻松进行调整。
I'd recommend using GitHub and keep your Dreamhost resources as free as you can to run your Rails app (in fact, depending on your project, I'll need as much as it can have to coup with it, being a shared hosting).
My usual workflow involves having a development environment and a GitHub account. We use Capistrano (which is fairly simple to learn and understand) to manage the push to GitHub, and then the respective deployment to the hosting, in your case Dreamhost, through SSH/SCP.
That way, you won't have to worry about what it's actually on your production repository, neither having to do maintenance tasks on it. Works pretty fast too and can easily be adapted for when you decide to change hostings o servers.