問題タブ [git-workflow]

Gitflow を使用しているときに、ブランチの命名をフィーチャー、バグフィックス、ホットフィックスに分ける理由は何ですか?

つまり、たとえば、次の代わりにだけではありません。

ただ行う：

機能/バグ修正/ホットフィックスで分けると何が得られますか?

私たちの git リポジトリには通常、ウェブサイトとサービス全体のコードが含まれています。これには、マーケティング、法律、UI などの入念に表現されたすべてのテキストが含まれます。

基本的に、不正な開発者がそれを複製し、いくつかの変更を加えて、私たちの競争相手になる可能性があります (法的な問題は別として)。あるいは、許可なくポートフォリオに他人の作品を自分の作品として含めることがよくあります。場合によっては、これにより、まだ公開したくない機能が早期に開示されることになります。

いずれにせよ、これはリスクとして認識されています。なぜなら、私たちは世界中の開発者と時折作業しており、開発者が作業するコード ベース全体へのアクセスを許可するために、さらに多くの開発者をすぐに追加する必要があるからです。

この問題に遭遇したことがありますか? または、同様のリスクを軽減または軽減するためのソリューションを実装しましたか?

考えられる戦略の 1 つは、異なる目的 (ブランチではなく) で 3 つの個別の git リポジトリを作成することですが、次のようなものです。

Git リポジトリ: Project1_DEVELOPERS

上記のワークフロー: 基本的に課題/機能ブランチ スタイルです。開発者はタスクを委任され、課題/機能ブランチとしてチェックアウトします。完了すると、そのブランチ & マージ リクエストを dev ブランチに送信します。分岐をテストし、OK の場合は dev にマージします。

上記は、基本的に今日のやり方です。それでおしまい。レポ全体は、世界に公開されると「マスター」にあります。

しかし、指定された目標を達成するために、次のようなものを追加することを考えています...

Git リポジトリ: Project1_OBFUSCATE

そして本番レポ...

Git リポジトリ: Project1_PRODUCTION

問題のコンテンツに関する限り、単純な Web ページをリポジトリとして想像してみてください。

したがって、私の目標は、「DEVELOPERS」リポジトリにあるブランチからダミーのロゴを使用して、本物/偽の「logo.png」を削除またはパッチすることです。

実際には、logo.png だけではなく、一連の .blade ファイル (Laravel) の .twig ファイル、またはアクセスを制限したいコンテンツ ビットを含む可能性のある任意のテンプレート ファイルである可能性があります。場合によっては、ファイルが「OBFUSCATE」リモートにのみ存在する可能性があります。

洞察を共有する可能性のある、これに似たようなことをした人はいますか?

私が提案している方法でこれを行うことを考えると頭が痛くなり、うまくいかないかもしれません:)

と のリポジトリがproject1ありproject2ます。project2マージするつもりはなく、フォークされproject1ました (現在は別の製品です)。

project2ここで、 に選択的に移植したい機能をいくつか紹介しましたproject1。project2のリポジトリをリモートとして追加して実行する必要がproject1ありますgit cherry-pickか? または、git format-patch続けて使用する必要がありgit amますか？

問題の機能は非常に複雑で、プロジェクトが分岐した後、多くのコミットで実装されています。

3 つのブランチがあります。

1. master= 生産拠点
2. feature_1= に基づく分岐master
3. feature_2= に依存するブランチfeature_1

feature_1終了時にブランチをマスターにマージする正しい方法は何ですか? 通常、私はリベースを使用しますが、この場合、ブランチが同期するために常にfeature_2マージされているため、多くの競合が発生します (ブランチ内のすべてのコミット ハッシュが変更されるため)。feature_1feature_1

通常のマージを使用することが唯一の選択肢ですか?

それとも、そのようなタイプのワークフローのためのより良い方法がありますか?

そして別のフォローアップの質問:

1. master- 含むfeature_1
2. feature_1- 終了し、マスターにマージ
3. feature_2-依存および同期feature_1
4. feature_3feature_1-との両方のブランチに依存する新しいfeature_2ブランチ

ブランチで作業を開始する正しい方法は何feature_3ですか?

前もって感謝します！

そのため、管理は Git で販売されています。現在、Perforce を使用して、準備ができたら変更リストをステージからリリース ブランチにマージします。現在のワークフローの利点は、どの機能を製品にするかを選択できることであり、リリース サイクルについて心配する必要はありません。テストが終わるとすぐにすべてが進みます。

Git を使用すると、開発者は開発ブランチまたは独自のブランチで作業します。次に、変更をステージ (テスト) ブランチにマージして、QA がテストできるようにします。
QA のテストが完了すると、PM はこれらの変更をリリース ブランチにマージし、本番環境にデプロイする必要があります。秘訣は、Stage ブランチでおそらく 10 個のテストを行っており、Release にマージする準備ができているのは 1 つだけです。

Stage ブランチ全体をマージしてリリースするのは簡単だとわかっていますが、これは決して起こりません。また、Git のチェリー ピックを使用するのは最悪です。ブランチでマージできなければ、Git を使用する意味はあまりありません。強制的に、チャングルリストをステージからリリースにマージしました。

Git でこれを行うにはどうすればよいでしょうか。
例を挙げていただけますか？

私はタイトルが少し毛むくじゃらであることを知っています - したがって、引用符!

b_featureメインの開発ブランチから分岐してマージされたブランチがあるとしますb_master。b_releaseこれらの変更を (ポイント リリースとして) 追加したい別のブランチ があります。b_master分岐しb_releaseており、再びマージされることはありません。

git cherry-pick -m Mmを使用して、すべてを単一の差分としてチェリーピックできることを知っています。

ここSquashedで、マージのメッセージとともに、機能のすべての変更を含むコミットですMm。

しかし、変更履歴と個々のコミット メッセージを保持したい場合はどうすればよいでしょうか? このおおよそのワークフローを使用して、いつでも手動で選択できます。

しかし、これは、私が知らないよりエレガントなソリューションへの不格好な回避策のようです!

rebase --onto b_release Bm Mmまた、私が探している結果が得られないようです。

それを行うより良い方法はありますか？

GITの特定のブランチから特定のファイルから特定の範囲の行を取得することはすでに可能でしょうか? 私はかなり大きなプロジェクトに取り組んでおり、新しいブランチに切り替えた後にソリューション全体をリロードするのに数秒かかりますが、マスターなどから現在のファイルの履歴/バージョンを確認する必要がある場合があります。マスターに切り替えなくても可能ですか？