1

私はどこかで読んだことがあります*このようなセットアップはいいでしょう:

各サーバーに 1 つずつ、2 つのメイン ブランチ。

マスターにプッシュすると、変更がライブに送信されます。

dev/stage (またはそれを何と呼ぶか​​) にプッシュすると、変更がステージングに送信されます。

ワークフロー:

  • dev からブランチを作成します。

  • テストの準備が整うまでローカルで作業します。

  • dev にマージします。

  • 変更を開発/ステージング サーバーに送信する Hub にプッシュします。

それらを公開する準備ができたら、次の手順を実行します。

  • 開発からマスターへのマージ、

  • 次にマスターをハブにプッシュし、それらの変更をライブ サーバーに送信します。

各サーバーに 1 つずつ、2 つのメイン ブランチ。

したがって、「webroot/myliveapp/」に 1 つのブランチ「production」があり、「webroot/devapp/」に別のブランチ「development」があります。

リポジトリはどこにありますか?

アップデート：

つまり：

このフローによると、次のようになります。

  • プライムレポ;

  • ベア レポ ハブ。

  • クローン;

開発ブランチと本番ブランチは 1 つのリポジトリに属する​​必要がありますよね?

これが正しい場合、最初の git init コマンドを発行する必要がありましたか? 私たちのプライムレポで？

したがって、次のようになります。

"webroot/myliveapp/" - 本番ブランチ;

"webroot/devapp/" - 開発ブランチ;

"webroot/.git" - プライム リポジトリ。

これは理にかなっていますか？

Or should the Prime repository correspond to our production branch location ?

*Note: if you need a context about what workflow I'm trying to implement, is this one: http://joemaller.com/990/a-web-focused-git-workflow/

4

1 に答える 1

11

あなたの質問の更新をありがとう、それは今より明確です。

あなたが抱えている問題は、Git ワークフローの誤解に基づいていると思います。Git はディレクトリをブランチと同一視するのではなく、ファイルシステムのビューをブランチと同一視します。これは強力ですが、自分の足を撃ち落とすのは簡単です。説明させてください。

Git は、データベースに支えられた、差分バージョン管理された履歴追跡ファイルシステムのように機能します。ファイルシステムの「一部」ではなく、ファイルシステムの「上」にあります。ファイルシステムを使用してブランチを表すのではなく、別のブランチをチェックアウトすると、ファイルシステム内のすべてのファイルがそのブランチ内のファイルに変更されます。ファイルシステムがそのブランチの別の現実を表すように Git に依頼しています。

branch にいて、コミットされmasterたファイルがあり、コミットされていないroot/foo.txtbranch をチェックアウトすると、そのファイルを探すと、そのファイルがなくなっていることがわかります。ではなくの一部であるため、ファイルシステムには存在しません。これが、Git がブランチを切り替える前に現在のブランチがコミットされることに本当にうるさい理由です。Git が知らないファイルシステムにステージングされていない変更がある場合、Git はそれらを別の現実で上書きして吹き飛ばすことを拒否します。最初に物事を正しくするために介入する必要があります。experimentroot/foo.txtmasterexperiment

したがって、質問に答えるには、「myliveapp」と「devapp」のサブディレクトリを作成しないでください - 別のブランチを作成してください。「webroot」の下に 1 つのコードベースを配置するだけです。次に、たとえば「不安定な」ブランチをハックして、通常どおり変更をコミットします。次に、「devapp」ブランチに切り替えることで、リポジトリ内のすべてのファイルを開発サーバーのファイルのバージョンに切り替えることができます。同様に、いつでも「unstable」に戻すことができます。

開発サーバーの更新など、ブランチを更新する場合は、merge「不安定化」して「devapp」にすることができます。これにより、「devapp」のすべてのファイルが「unstable」のもののようになり、最新の状態になります。

注意すべきもう 1 つの点: プライム リポジトリ、ベア リポジトリ、およびクローンの違いはほとんどありません。ソフトウェアにはほとんど違いはありません。むしろ、「Linus のカーネルは正規の Linux カーネルである」と言うのが人間の慣例です。その理解で：

  • プライム リポジトリは、ソフトウェアの「正規」バージョンを保持することに誰もが同意する 1 つのリポジトリにすぎません。つまり、開発者が変更を加えるたびに、「自分のバージョンの devapp をプルしてください」と言うのではなく、「自分の変更をプライム リポジトリに公開しました」と言うことができます。それは単に、人々が集まるための簡単な慣習です。
  • クローンは、他のリポジトリのコピーです。プライム リポジトリを複製して変更を加えると、私のリポジトリを複製できます。変更を加えた場合、マージが有効で、コンピューターに対するアクセス許可がある限り、それらをプライム リポジトリまたは私のリポジトリにプッシュできます。
  • ベアリポジトリには「作業コピー」がありません。そのコンピューターには「webroot」ディレクトリはありません。ディレクトリのみで空.gitです。これは、誰もファイルを変更する必要がないサーバーには適しています。

最後に、.gitdir はリポジトリのファイルを保持するのではなく、git 構成とデータベースを保持します。これは、データベース形式のリポジトリ全体の履歴であり、残りのリポジトリにソフトウェアの特定のバージョンを入力するために使用されます。それが私がコメントした理由です。ネットワーク通信なしで、リポジトリの代替現実の任意のバージョンをローカルでいつでもチェックアウトできます-すべてが.gitディレクトリにあるためです。必要な唯一のネットワーク通信は、またはを使用して、ローカル リポジトリを他のリポジトリと同期する場合です。pushpull

于 2012-03-12T21:55:26.337 に答える