1

開発ライフサイクルのさまざまな段階で、コードのいくつかの異なるバージョンをバージョン管理し、常に Web 上で同時に公開したいと考えています。バージョンは通常、development、staging、liveという名前で、次のツリーのように構造化されています。

Sitename
  |--Development
  |--Live
  `--Staging
  • 3 つの個別のリポジトリを作成するのと、3 つのブランチが永続的にチェックアウトされた 1 つのリポジトリを作成するのとではどちらがよいでしょうか?
  • 各ワークフローのそれぞれのメリットとデメリットは何ですか?
  • Git を初めて使用する場合、優先ワークフローを実装するにはどうすればよいですか?

補遺

単一のリポジトリを作成したいのですが、それはその下にリポジトリを作成し、そのSitename中に 3 つの作業ディレクトリを持つことを意味しますが、Git はネストされた作業ディレクトリをサポートしていないことを理解しています。と呼ばれる寄稿ソリューションを認識してgit-new-workdirいますが、このワークフローを使用すると、新しいユーザーが利益よりも多くの結果を被る可能性があることを読んだので、代替案に興味があります。

4

3 に答える 3

0

これは古い質問ですが、まだ多くの意見が寄せられているため、適切な回答に値すると思います。この質問をしたとき、私は SVN には精通していましたが、Git には慣れていませんでしたが、3 年経った今、答える資格があると感じています。

この質問の最も適切な部分は次のとおりです。

3 つの個別のリポジトリを作成するのと、3 つのブランチが永続的にチェックアウトされた 1 つのリポジトリを作成するのとではどちらがよいでしょうか?

これら 2 つのオプションのどちらかを選択する必要がある場合、後者になりますが、正解はどちらでもありません。環境ごとに異なるリポジトリを作成することは、環境ごとに異なるブランチを作成することと同様に正しくありません。

Git を使用する正しい方法は、1 つのプロジェクトに対して 1 つのリポジトリを用意することです。リポジトリは、必要に応じて何度でも複製できます。さまざまなユーザーがさまざまなバージョンのコードをチェックアウトできるように、さまざまな環境で、リポジトリのコピーからさまざまなバージョンのコードをチェックアウトできます。異なる環境は、コードの異なるユーザーと見なすことができます。

于 2015-09-29T15:37:38.453 に答える
0

1 つのリポジトリを保持します。ブランチの規約を考えてください。通常、これは次のとおりです。

master : サーバーで実行されているコードと、ユーザーが経験することを表します

staging : (オプション) ステージング サーバーにデプロイされたコードと、選択したベータ テスターが使用するものを表します。

release-candidate または RC : 単独で、または他の機能と一緒にテストされ、合格したすべての機能。これは、いつでもマスターおよび/またはステージングにマージできます。

integration または dev : 過去および現在 (完全および不完全) のすべての機能が統合され、現在何が失敗しているかについてのフィードバックを取得します。

機能またはタスク: (通常、チケット番号として名前が付けられます) 機能を格納します。できれば、反復内の他の機能と共通のポイントから開始します。

それらを管理するには、次のワークフローをお勧めします: http://dymitruk.com/blog/2012/02/05/branch-per-feature/

組織化され、一貫性があり、チームにとって意味のあることを行うようにしてください。

于 2012-07-17T23:06:56.933 に答える