2

私はむしろGitの初心者であり、あなたのアドバイスを探しています。

私が働いている会社には、2つのブランチを持つプロジェクトの単一のGitリポジトリがある「ワークフロー」がありmasterますprod。masterすべての開発者はブランチで作業します。チケットが（開発の観点から）完了したら、リポジトリにプッシュします。すべてのテストに合格すると、リリースされます。

問題は、ほとんどの場合、ビジネスマンからのリクエストが「チケットAまたはA&&Bをリリースしてください」のように聞こえることです。

ほとんどの場合、私は次のようなことをすることになります

git checkout prod
git cherry-pick --no-commit commit_hash
git commit -m "blah blah to prod" -a

ご覧のとおり、これは完璧な解決策ではありません。私は大きな印象を受けています。特に、変更Aが変更BとCに依存している場合、これはどこにも行かない完璧な方法です。

より多くの開発者が同じブランチで動作し、フローが上記のようになっている場合に、オンデマンドでリリースを処理する方法について何か提案はありますか？すべての提案を歓迎します。

私はビジネスプロセスを変更することはできず、残念ながらそのままにしておく必要があります。

4

2 に答える 2

3

私たちはあなたのようなワークフローを2年間使用し、最近それを放棄しました。これには4つの問題があり、ワークフローを長く使用するほど、それぞれが誇張されてしまいます。それは驚異的な時間の浪費であり、管理するために私たちの（確かに小さな）リリーススタッフによるほぼフルタイムの努力を必要としました。まだ行っていない場合は、数か月以内にヒットするものは次のとおりです。

  1. あなたmasterとprodブランチはコミット履歴を共有しません。つまり、それらを簡単にマージすることはできません。これは、このワークフローのバージョンで特に明白になり--no-commitます。フラグを使用してチェリーピッキングを行い、ファイルを再コミットするためです。ある意味で、同じコードセットに対して2つの異なるgitリポジトリを維持していることになります。あなたがヒットするまで、これは扱いやすいように聞こえます...

  2. masterとprodは異なる履歴を持っていますが、の変更prodのサブセットであるためmaster、ブランチは時間の経過とともに分岐します。新しい機能が廃棄されることがあります。時々、ビジネスマンは優先順位を変更します。40のコミットを取得し、それがすべてを壊すことに気付くまで、アイデアが素晴らしいと思われることがあります。で再現できないバグがmasterブランチに導入されprod、それらの一部は、まったく表示されないコードのアーティファクトになりますprod。一定の維持がなければ、masterの完全性は低下します。それは煩わしく、イライラし、実際の作業を行うのを妨げます。さらに悪いことに...

  3. masterに存在しないマージの競合を修正することになりますprod。これらのコミットをチェリーピックするとprod、チェリーピックプロセス中にバグが発生する可能性がわずかにあります。あなたのmasterコードはほとんどあなたのprodコードですが、わずかな違いが意図しない結果を生み出す可能性があります。開発者が空白に特に注意を払わなかったり、「実験」したりしない場合、問題は誇張されます。Genius Developer Susie（実際には非常に明るいが、レガシーファイルをより読みやすくするためにリファクタリングする傾向がある）が、正当なコード修正とともに一連の空白の変更をチェックインする場合、本番ブランチを奇妙な灰色にすることになります以前の状態と現在の状態の間の状態master。

  4. 最後に、-1-、-2-、および-3-を組み合わせると、発生した最悪の問題が発生します。緊急修正と機能の作成、テスト、およびリリースが困難です。危機的状況の場合、アプリケーションにセキュリティホールを導入しただけです。bizdevは中規模国のGDPのためにMoneyBagsMcEnterpriseに署名したばかりで、必要なのはCOBによるまったく新しいツールスイートだけです。これは機能する必要があるため修正する必要がありprodますが、できません。簡単ではありません。すべての開発者はmasterローカルで実行されています。prodブランチを切り替えることで実行できますが、テストフレームワークはmasterのコードに組み込まれているため、の新しい部分全体が詰まってしまいprodます。それは大丈夫です、あなたはそれを書いて、それprodをチェリーピックしてmaster、 右？うーん。マージの競合や発散ファイルをヒットせずにはいられません。機能を分岐prodして、それを完全にマージするのはmasterどうですか？そうそう、彼らは歴史を共有していません...

これらの問題について十分に考えていなかった可能性があります。そこにいる誰かが、この仕事をするためにコミットと歴史に十分注意していることを約束します、そしてあなたは他の答えで彼らから聞くかもしれません。それでも、このワークフローは、使用した2つのYeraで時間のバケツを浪費しました。いくつかの重要なアイデアを中心にワークフローを再構築しました。

まず、ブランチgitは安価で簡単なので、すべての機能やケースに使用します。開発者がケース固有のブランチ（問題追跡システムによって提供されるケース番号）を共有可能な場所にプッシュする命名スキームを開発しました。私たちは各開発者に個人的なリモートリポジトリを提供するためにgitoriousを使用していますが、これらの「実行中」の機能とケースを共有にプッシュできなかった理由はありませんorigin。ある程度の整理と追跡が必要ですが、上記の問題で必要とされるものよりはるかに少ないです。

production次に、これらの機能ブランチは、ではなく切断する必要がありmasterます。機能または修正が「実行中」の別の変更セットに依存していない限り、問題を示しているか、機能を必要とする最も上流のブランチに基づいている必要があります。私たちにとって、それは常にproductionです。

第三にmaster、、または私たちがメインの開発統合ブランチと呼んでいるものは、本番環境に統合された「飛行中」の機能ブランチのコレクションです。これは、統合テストのために存在し、機能ブランチ間のマージの競合と依存関係を早期に特定するために存在します。これは、新しいコードの基礎となるものではありません。リリースごとにリセットし、「飛行中のトピック」の追跡とマージを自動化しました。また、QA部門用に別のブランチを維持していますnext。このブランチには、本番環境が遮断され、次のリリースでリリースされる機能ブランチのみが含まれています。

これは、 gitプロジェクト自体から採用したワークフローです。それは分散されており、私たちにとってはかなりのパラダイムシフトです。うまくいくかもしれませんが、うまくいかない場合でも、別のワークフローを探すことをお勧めします。現在のものは時間の経過とともに劣化し、コードと戦うのと同じくらいバージョン管理と戦うことになりかねません。

于 2012-05-30T15:07:10.970 に答える
0

ブランチワークフローの一般的なリファレンスは、成功したGitブランチモデルです。

于 2012-05-30T16:39:00.183 に答える