SO の同様の投稿、公式の Hg ガイド、多くの記事やガイドを読みましたが、機能別の開発に最適な Hg ワークフローが何であるかはまだわかりません。Web 上の記事の一部は何年も前のもので、Hg の最新機能が含まれていない可能性があります。明らかに、それにアプローチする方法にも多くのオプションがあります。
私は、「タスク #546 - 何かを変更する」のように、修正または機能の要求がタスクとして提出されるプロジェクトに取り組んでいるソロ開発者です。これらのタスクには数日かかるものもあれば、数か月間オープンなタスクもあり、多くの場合、一度に最大 12 件の作業が行われます。タスクは、依頼者によって承認された後、最終サイトに送られます。
Hg ガイドでは、機能ごとにクローンを作成することを推奨しているようです。しかし、私のドライブにサイトの完全なコピーを 10 個も持つのは... もったいないですか? 私はそれを試すつもりですが、もっと理にかなった他の提案を見てきました。開発マシンに各サイトのコピーを一度に 10 個も持っている人が本当にいるのでしょうか?
ブランチに名前を付けるというのは、最初は私が望んでいるように聞こえます。ブランチに「タスク 546」という名前を付けて作業し、出荷時にマージして戻します。名前の永続性と非常に多くのブランチがあることについて、多くの議論が見られます (ただし、それらは閉鎖される可能性があります)。それを気にする人もいれば気にしない人もいるようです。私は気にするかどうか、そしてマイナス面が実際に何を意味するのかを知るのに十分なほどHgを知りません.
最後に、ブックマークは最近の記事で人気があるようで、「タスク 546」のようなブックマークを設定してから、次のコミット メッセージを使用してメイン ブランチにマージするのが最良の方法のようです。その中のタスク番号は、作業で何が行われていたかへの参照を保持します。ブックマークを削除できることは知っていますが、最終的なマージ後にこれを行う必要があるかどうかは不明です。
したがって、組み合わせたアプローチに対する私の考えは次のとおりです。
1つのレポ
3 つの名前付きブランチ:
- サイトのリリース バージョンを保持する「デフォルト」
- 機能開発を行う「dev」
- クライアントによってレビューされているすべてのタスクを保持する「テスト」
「dev」ブランチでは、取り組んでいるタスクごとにブックマークを使用するので、各タスクの頭を持っています
タスク/機能のワークフローは次のようになります。
- 「dev」という名前のブランチのメインラインへの更新
- タスク「タスク #123」のブックマークを使用して新しいブランチを開始します
- クライアントがレビューできるようになるまで変更をコミットする
- 「タスク #123」を「テスト」ブランチにマージします
- 「test」をテストサーバーにデプロイします
- 本番環境の準備が整うまで、コミット、マージ、デプロイを繰り返します
- 承認されたら、タスク名を含むコミットメッセージで「dev」ブランチのメインラインにマージします
- 「dev」を「default」ブランチにマージします。
- 「デフォルト」ブランチをライブサーバーにデプロイします
- 開いている機能ブランチに「デフォルト」をマージします
考え？各機能のクローンと、プッシュ先の「ライブ」および「テスト」リポジトリを用意したほうがよいでしょうか?
編集:いくつかのリンクから、「デフォルト」から開発を行う必要があることがわかります。そのため、リストされたプロセスに対する最初の変更は、名前付きの「開発」ブランチの代わりに名前「プロダクション」ブランチを使用することです。