問題タブ [git-workflow]

git を使用した Web 開発のワークフローに苦労して整理した後、最後の 1 秒でステージング サーバーを追加することになりました。私たちはローカルで開発/テストし、レポにプッシュします。他の部門の人々が何かを壊すことなく遊んだり、新しいことを試したりできるように、その間にサンドボックスが必要です。

リモート リポジトリには、マスターと開発の 2 つの長期実行ブランチ (nvie のブランチ モデルの精神による) が必要です。

1 つのリポジトリにプッシュし、develop ブランチを test.site.com docroot にチェックアウトし、準備ができたら、develop を master にマージし、master を site.com docroot にチェックアウトできるようにする必要があります。

では、サーバー上で...

そして、私たちのローカルマシンでは...

サーバーに戻ってコードをライブにする

そして地元で

疑問符または別の提案を歓迎します。

編集： これまでのところ、いくつかの答えを試しています。その間に完全にハックなアイデアを思いついたので、共有したいと思いました：

それらすべてを支配する 1 つの post-receive フック。

ベアレポのクローンを作成し、開発を追跡します。開発をオリジン/開発にプッシュします。

受信後 - GIT_WORK_TREE を test.site.com に設定し、チェックアウト -f 開発します

コミット メッセージに「merge_master」が含まれている場合、GIT_WORK_TREE を site.com docroot に設定します。

マスターを開発にマージし、ローカルでプルします

ほこりが落ち着いたら、difflog で電子メールを送信し、手を絞って、強いものを一口飲みます。

それはいくつの異なる方法で壊れる可能性がありますか?

私は転覆のバックグラウンドを持っており、最近私の会社は git に切り替えました。以前はラップトップで cron エントリを使用して、夜間に多数のチェックアウトを更新していました。このようにして、システムのさまざまなコンポーネントの現在のバージョンに対して実行することになります。特に、私が積極的に開発していなかった部分ですが、依存関係がありました。gitで同じことを達成したいと思います。

svn を使用した古い更新プロセスは次のとおりです。

このトピックに関する多くのブログ投稿を読み、質問しましたが、一貫した回答はあまり見つかりませんでした。また、これまで見てきたソリューションのどれも、探しているほど完全なものではありません。私はこれらすべての意見を取り入れて、以下のスクリプトを作成しました。

サブモジュールはどのように処理すればよいですか?

私が説明していない状況や落とし穴はありますか?

ありがとうございました。

「Verified Accounts」というプロジェクトでデザイナーと協力しています。

私は というブランチで開発してverified_accountsおり、デザイナーは というブランチにいchris_verified_accountsます。私たちは定期的に互いの変更をマージしてきました。プロジェクトが完了するとverified_accounts、master

ただし、このすべてのマージにより、大量のジャンク/重複コミットが発生しています。例えば：

http://dl.dropbox.com/u/2792776/screenshots/2012-03-02_1024.png

コミット (1) は、コミット (2) のみを含むプル リクエストのマージです。これは、これらのコミットが本質的に同一であることを意味します (同じ差分などがあります)。同様に、コミット (3) はコミット (4) のみをマージするマージです。つまり、3 と 4 も本質的に同一です。

これらの同一のコミットを管理する最善の方法は何ですか? つまり、コードの機能変更ごとに、関連付けられたコミットが 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/

git リポジトリにプロジェクトがあるとします。プロジェクトには、プロジェクトの現在のバージョンが常に安定している「Stable」または「Production」と呼ばれるブランチがあります。私は、理想的には常に安定版ブランチの最新バージョンを保持する必要がある実稼働サーバーを持っています。cron ジョブで特定の間隔でプルを実行できることは知っていますが、その解決策にはあまり満足していません。安定版ブランチでバグを発見した後、1 時間に 5 つのホットフィックスをプッシュすることがよくありました。新しいコミットがプッシュされたら、運用サーバーに即座にプルしてもらいたいです。

これを行う最も簡単な方法は何ですか？私のフォールバック ソリューションは、実稼働サーバーで 1 分ごとにプルを実行することです。

Github リポジトリとプライベート内部リポジトリがあります。現在、レポジトリの git/config ファイルに 2 つのレポ参照を追加するだけで、どちらもリモート オリジンとして使用できます。したがって、変更をプッシュすると、両方のリポジトリに移動します。冗長性ポリシーとしてこれを開始しました。

しかし、プルリクエストを使い始めました。この背後にある主な目的は、経験の浅い開発者がメイン リポジトリをフォークし、変更を加えてテストし、それらを自分のリポジトリにプルしてから、メイン リポジトリにプル リクエストしたことです。より経験豊富な開発者は、これらの変更を確認し、メイン リポジトリにマージするかどうかを検討します。ただし、最初のテストでは、これによりリポジトリが同期しなくなりました。

それらを同期し続ける方法はありますか？また、より良いアプローチやより良い実践のためのヒントをいただければ幸いです。

2 人目の開発者を雇ったばかりなので、Web ファイルの管理に GIT を使用することを検討しています。

GitHub は使用しませんが、NAS ドライブ (共有ドライブ) があるため、最初の考えは次のような計画です。

• DVCS (ルート)
  • マスター (NAS)
    • プロジェクト1
    • プロジェクト 2
  • 開発者1 (NAS)
    • プロジェクト1
    • プロジェクト 2
  • 開発者2 (NAS)
    • プロジェクト1
    • プロジェクト 2
  • developer1 (ローカル ワークステーション)
    • プロジェクト1
    • プロジェクト 2
  • developer2 (ローカル ワークステーション)
    • プロジェクト1
    • プロジェクト 2

したがって、基本的に各開発者は、マスター プロジェクト リポジトリを開発者リポジトリ (品質管理) に複製し、次にこの開発者リポジトリをローカル リポジトリに複製します。彼らは変更/編集を行い、上級開発者が承認できるように、これらの変更をコミットして開発者リポジトリにプッシュします。彼らがこれを行うと、マスターにプッシュされます。

これが正しいアプローチなのか、ブランチを使用する必要があるのか​​ 、それとも別のワークフローが必要なのかわかりません。

master ブランチを持つ Git リポジトリがあります。ここで、すべてのブランチ (データベースなど) で同じ変更を行うさまざまなブランチを作成したいと考えています。したがって、これらのファイルをmasterに含めることができます。

• a.java
• b.java
• データベース-1.xml

そして、 branch-1およびbranch-2と呼ばれる 2 つのブランチと、次のファイルがあります。

• a.java
• b.java
• データベース-ブランチ-1.xml

と

• a.java
• b.java
• データベース-ブランチ-2.xml

さて、でバグを見つけたとしましょうa.java。明らかに、それを修正して、すべてのブランチで同じ変更をコミットしたいと思います。どうすれば目標を達成できますか?

注: データベース ファイルは異なるままにしておく必要があり、他のファイルは常に同じです。

私は完全なgit初心者ですが、Webアプリケーションを本番サーバーに簡単に「アップロード」する方法としてGitを使用しています。これが私のワークフローです：-

1. ローカルでコーディングmasterを行い、本番環境にリリースする準備ができたら、ブランチにコミットします。-

2. git checkout production

3. git merge master

4. git push origin production

オリジンが本番サーバー上のベアリポジトリである場合、次のことを行う受信後フックがあります。-

1. git clone /dir/to/bare_repo /dir/to/production

2. cd /dir/to/production_dir

3. GIT_DIR=/dir/to/production/.git

4. git checkout -f production

最後のチェックアウトコマンドは、次のメッセージを生成します。-

ブランチ生産は、オリジンからのリモートブランチ生産を追跡するように設定されています。新しいブランチ「プロダクション」に切り替えました

それでも、ローカルで行った変更は/ dir / to/productionに表示されません

どんな提案でも大歓迎です！

編集：変更は、本番環境での場合と同じように、ローカルで本番ブランチに表示されることに注意してくださいgit merge master。動作していないように見えるのは、リモートのクローンリポジトリでのチェックアウトです

カスタムビルドプロジェクト「キックスタート」があります

このキックスタートには、非常に簡単にモジュールを追加できます。

これらのモジュールをビルドするときは、バージョン管理されたキックスタートの 1 つのクリーンなマスター コピーに基づいてすべてのモジュールをビルドします。

プロジェクトを開始するときは、空のレポを作成し、キックスタート レポをリモートとして設定し、リモートからプルします。コアに更新がある場合は、リモートからプルするだけです。

これはうまくいきます。

しかし、私が言及したモジュールはあります。それらはすべて、新しいプロジェクトとしてクリーンなキックスタートでビルドします。

これらすべてのモジュールをバージョン管理したいと考えています。

モジュールのファイルは、実際にはテンプレート内に存在します。

ワークフローは次のようになります

したがって、サイト 1、2、および 3 は独自の git リポジトリです。

それらにはすべて、git リポジトリであるキックスタートが含まれています

モジュールを共有するものもあります。

現在、これらから上流にプッシュすることはありません。サイト 1 で実行中に何かがうまく機能すると判断した場合は、キックスタートのクリーン コピーをチェックアウトし、そこで変更を加えてから、すべての異なるサイトにプル ダウンします。モジュールと同じこと。

しかし、私の基本的な質問は、モジュールをどこに置くかということです。それらはそこにあるキックスタートに依存します。

サブモジュールとサブツリーについても聞いたことがありますが、それらがどのように機能するかはわかりません。

このワークフローを構築する最善の方法は何ですか?