2

私は、フィーチャー ブランチを git のプレビュー ブランチに時折公開する最良の方法を理解しようとしています。これが私のセットアップです：

  1. クライアントは機能を要求します。
  2. 初期機能を開発し、プレビュー/テスト サイトに公開します。
  3. クライアントがフィードバックを提供します。
  4. さらに変更を加えます。
  5. ステップ 3 に数回進みます。
  6. クライアントは機能に適しています
  7. 機能を本番サイトにプッシュされる単一のコミットにリベースします。

いくつかの異なる機能が一度に開発される可能性があり、クライアントが開発中のこれらすべての機能を確認できる「プレビュー」サイトは 1 つだけであることに注意してください。現在の私のgitワークフロー。

git checkout -b new_feature
...hack hack hack...
git add .
git commit -m "WIP"
git checkout preview
git merge new_feature
... feedback and another feature got approved and merged with master ...
git checkout new_feature
git merge master
... hack hack hack...
git add .
git commit -m "WIP"
git checkout preview
git merge new_feature
... client approves work for release ....
git checkout new_feature
git rebase -i master
... squash all commits except the first which I reword with a good description...
git checkout master
git merge new_feature
git branch -d new_feature
git checkout preview
git merge master
git checkout master

したがって、最終結果は次のとおりです。

  1. 本番環境に移行するときに、独自の分離されたブランチとコントロールで機能を開発することができました。また、きちんとしたコミットとして本番環境にロールアップされます。
  2. クライアントは、私が開発してフィードバックを提供する機能を確認できます。彼らはまた、私が同時に開発している他の機能と一緒にその機能を見ることができます.
  3. 「プレビュー」ブランチは、「WIP」コミットと最終的なリベース コミットの両方を取得するため、少し厄介になります。しかし、それはクライアントのプレビュー用であるため、それほど気にしません。必要に応じて、定期的にブランチを削除してマスターから再作成できます。

私の唯一の問題は、予想よりも多くの競合が発生しているように見えることです。これは、ステージングが開発コミットと最終コミットの両方を取得しているためだと考えています。これを行うためのより良い方法があるかどうかも疑問に思いますか？

4

1 に答える 1

0

マスターとマージする前に機能ブランチからすべてのコミットを押しつぶすのが好きではないことを除けば、ワークフローは問題ないようです。

私の意見では、これでは何の価値も生まれず、機能の進化に関する潜在的に重要な情報が失われます。

マージするときは、 を使用しますgit merge --no-ff new_feature。これにより、機能ブランチの存在に関する情報が保持されるため、各機能にどのコミットが行われたかが一目でわかります。

git マージ --no-ff

画像ソース -成功した Git ブランチ モデル

于 2011-10-10T15:32:39.107 に答える