2

@nvieのGit分岐モデルとgitflowについて読んだことがありますが、これは現在取り組んでいるプロジェクト（Webアプリケーション）に使用するのに適したモデルだと思います。

私はプロジェクトのリード開発者であり、ローカル環境（MAMPのような）で開発しています。クライアントに見せるために何かを作ったときはいつでも、自分の仕事をコミットして中央のGitホストにプッシュします。そこから、インターネットに接続されているサーバーに展開します。その後、私のクライアントは変更を見ることができます。

2人目の開発者がプロ​​ジェクトの作業を開始しました。彼は一度に1つの機能を開発し、準備ができたら中央のGitホストにプッシュします。展開する前に彼の作品をレビューします。

現在、すべてのコミットはmasterブランチで実行され、単一のホスト環境にデプロイされます。将来的には、本番環境（実際に使用するため）、テスト環境（リリース直前にアプリの新しいバージョンをテストするため）、および開発環境（完成した機能またはまだクライアントに進行中です）。master実稼働環境はからデプロイを取得し、開発環境はからデプロイを取得すると思いますdevelop。

私が持っている質問は次のとおりです。

  1. 私はしばしば同時にいくつかのタスクに取り組んでいます。機能の一部の準備ができたら、その機能の作業を続ける前に、クライアントに見せたいことがあります。developただし、私の理解では、機能（ブランチ）は、それが終了してリリースがスケジュールされたときにのみマージされます。進行中の（またはまだリリースが予定されていない）機能を（開発環境で）クライアントに表示するにはどうすればよいですか？

  2. どのブランチからテスト環境にデプロイする必要がありますか？その瞬間のリリースブランチを手動で選択する必要がありますか、それとも専用のテストブランチがありますか？

4

2 に答える 2

3

これについての私の見解は次のとおりです。

  1. 表示する機能ブランチを開発環境にデプロイできます。クライアントが新機能を確認した後、開発ブランチをデプロイすることを忘れないでください。

  2. テスト環境では、リリースブランチを使用します。テスト期間が終了し、アプリをリリースしたら、次のリリーススケジュールまでマスターブランチをテスト環境にデプロイします。

免責事項：私はgit-flow（AVH Edition）の開発者です。
覚えておく必要があるのは、元のgitflowソフトウェアはリモート機能を削除せず、ブランチをリリースしないということです。したがって、元のgitflowで機能またはリリースを終了するときは、リモートブランチを手動で削除する必要があります。git-flow（AVH Edition）では、ソフトウェアがそれを処理します。

于 2012-11-22T03:14:08.353 に答える
3

機能ブランチは、1 つのコマンド (git checkout) でいつでも切り替えることができます。時々 (レールでは、開発モードでは、サーバーを再起動することさえせずに、アプリ サーバーを稼働させ、コードを切り替えます!)。どのブランチにいても、まだ「開発」モードです。
必要なブランチに切り替えて、そのデモを行います。次に、マスターまたは必要なブランチに戻ります。
最初はいくつかの組織ですべて master で作業していましたが、今ではすべての作業 (ブランチの機能、雑用、またはバグ) を行っています。多くの場合、ブランチ名やコミット テキストに追跡システム (この場合は Pivotal Tracker) の ID をタグ付けします。
トリックは、最新のマスターと git マージ マスターの頻繁な git fetch でブランチを最新の状態に保つことです (「トピック」ブランチにいる間)。

他の環境では、mycoolapp-stage などのリモートを構成し、コードを個別にプッシュします。1つのアプリに対して約6つの異なるリモコンがあり、そのうち4つはテストに使用されています.

テストに関しては、テスターは変更をプルダウンして開発環境でローカルに作業するか (プログラマーと QA テスターの両方で機能します)、コードをプッシュするテストまたはステージング領域をリモートとして使用することができます。

全体として、ブランチで作業してから、マスターを介してプッシュします。git branch、fork、fetch、merge、rebase、cloneのプロセスに関する私の回答で詳細を参照してください。違いは何ですか?

于 2012-11-22T03:32:46.647 に答える