4

これは主に Git の効果的な使用法に関する質問です。まず、私は Rails の専門家ではなく (少なくともプロダクションの意味では)、Git の初心者であることは間違いありませんが、SVN を使用した経験があります。

私の問題は、Rails アプリケーションを作成しようとしているのですが、自分のコンピューターで開発をローカルに維持する最善の方法がわからず、Dreamhost の共有ホスティング アカウントにデプロイできることです。

私は Git でこれができると考えましたが、その方法は完全にはわかりません。サーバー上に Git リポジトリを作成し、各コミット後にローカルのものをそこにプッシュすることを考えていました。Git に関するいくつかのチュートリアルを読みましたが、何をすべきかについてまだ混乱しています。これに代わる方法は、FTP を使用してファイルをコピーすることですが、それは正しくないようです。

私が使用できる最初のステップやコマンドがいくつかありますか? この展開方法は怪しいですか、それともこれを行うためのより良い方法はありますか?

4

3 に答える 3

8

現在、hostingrails.com 以外で運営されていますが、ウィスコンシン州のブラス バンド用の Rails Web サイトを、あなたが説明しているものと非常によく似た設定で運営しています。私は自分のコードを githubでホストしていますが、非公開でホストできない理由はありません。私のフローはこの 1 年半で進化したので、ここから短期的に必要なものだけを取り出してください。

フローの中心で、デプロイを処理するためのやや精巧な Capistrano スクリプトをセットアップしました。これには、テスト用に本番データベースの完全なコピーを作成する別のステージング環境が含まれます。これを構築するにはしばらく (数日ではなく数時間) かかりましたが、その価値は十分にありました。

私のワークフローでは、少なくとも 2 つのブランチが保持されます。

  • current_release:ライブ プロダクション コード。緊急のバグ修正はここで行われます。
  • master:リリースの準備ができた完成した機能。これらの機能は、ここで実際にテストされるのを待っています。緊急バグ修正は からマージされcurrent_releaseます。
  • <feature_name>:開発中の機能。私は、いつでもこれらの未処理のものが 3 つを超えないようにしています。緊急のバグ修正がマージされ、master機能を最新の状態に保つために頻繁にマージされます。

このセットアップを使用すると、複数の作業を同時に行うことができます。毎週（これはフルタイムの職業にはほど遠いので）、私は次のことを行います。

  1. 機能ブランチで編集します。行ったり来たり、退屈したり、興奮したり、何でもします。一緒に成長する 2 つの機能をマージすることがあります。

    [edit]
    $ git commit
    $ git push github [feature]

  2. 差し迫った展開の準備が整った完成した機能は、一度に 1 つずつブランチにマージされmasterます。

    $ git checkout master
    $ git merge [feature]
    [fix immediate problems or inconsistencies]
    $ git commit
    $ git push github master
    $ git branch -d [feature]

  3. Web サイトをプライベート URL (たまたま stage.madisonbrass.com) にステージングします。ステージング環境は常にmasterブランチからプルします。

    $ cap staging deploy # master is now live at stage.madisonbrass.com

  4. バム、テスト中に、公開 Web サイトで緊急のバグを見つけました。幸いなことに、私はcurrent_release個別に作業しているため、個別に修正して展開できます。

    $ git checkout current_release
    [fix bug]
    $ git commit
    $ git push github current_release
    $ cap production deploy

  5. ブランチに戻りmaster、緊急修正プログラムをマージすることから始めます。

    $ git checkout master
    $ git merge current_release

  6. 私はテストを続けますmaster。新しい問題が発生しないことを願っていますが、問題が発生した場合はマスターで修正し、これらの変更をマージしcurrent_releaseて別の運用展開を行います。

    $ git checkout current_release
    $ git merge master
    $ git push github current_release
    $ cap production deploy

  7. 何らかの形で検索エンジンによってインデックスが作成されないように、ステージング環境を破棄します。

    $ git staging teardown

于 2010-06-28T23:06:26.667 に答える
4

私がしているのgit init --shared --bareは、「マスター」リポジトリであり、自分の作業をプッシュする場所である、共有された裸の Git リポジトリ (で作成) を持っていることです。ベア リポジトリには作業ディレクトリがありません。私の Web ディレクトリでは、マスター リポジトリのクローンを作成して、作業ディレクトリとすべてのファイルがそこにあるようにします。そこから、git pull私がコミットした新しい仕事。

私は常に、リポジトリのクローンとテスト開発環境を備えた別のマシンで開発作業を行っています。機能を完成させたら、それをマスターにプッシュしてから本番サーバーにログインし、そこの作業ディレクトリにプルします。

これは、それほど重要ではないプロジェクトのための私だけです。これをさらに多くのステップで拡張し、重要な仕事の抑制と均衡を図ることができます。

于 2009-08-07T03:25:17.423 に答える
0

Rails アプリを実行するために、GitHub を使用し、Dreamhost のリソースをできるだけ無料にしておくことをお勧めします (実際、プロジェクトによっては、共有ホスティングであるために必要なだけのリソースが必要になります)。 .

私の通常のワークフローでは、開発環境と GitHub アカウントが必要です。Capistrano (学習と理解が非常に簡単です) を使用して、GitHub へのプッシュを管理し、SSH/SCP を介してホスティング (この場合は Dreamhost) へのそれぞれのデプロイを管理します。

そうすれば、本番リポジトリに実際にあるものについて心配する必要も、メンテナンス タスクを実行する必要もありません。動作も非常に高速で、サーバーのホスティングを変更する場合にも簡単に適応できます。

于 2009-08-07T03:57:56.267 に答える