公開では、1 つのアイテムが同時に公開されるわけではなく、独立して 1 つのアイテムが公開されます。ここでは、現在使用されている、gitlab に基づく git ワークフロー を共有することを考えています。 調整された git フローは、私たちの出力頻度を低下させる可能性がありますが、頻繁に git 問題に遭遇することもなく、その後、スタック git の高レベルのアプリケーション メソッドを削除します。ただし、基本的な git 操作が実行されるだけで、その後調整操作が行われ、基本的に git の問題に遭遇することはなく、そのような大家は、時間をかけてトラフィックを管理することができます。ではなく、遭難问题、紧急去寻找答案的候時
我们的このgit工作流玩儿法呢、主是分支持下面几个分支：
master
分支 最新のセキュリティコード
-
vx.x.x分支 バージョンサポート、x.x.x は次に公開されるバージョン番号です。
-
feat-xxx分支特性（新しい機能）分支
-
fix-xxx分支 修正分支
上面のこれらの分支、就是我们在リリースでは、頻繁に再構築されて使用される支店が必要です。 以下に、各支店が表す意味を詳しく説明します。
feat-xxx
分枝は、特定のバージョンの特定の新機能を公開するために作成された分枝を示します。
vx.x.x はバージョン ブランチを表します。これは、各バージョンの開始前に、このバージョン番号の名前で master から作成するブランチです。たとえば、バージョン番号は2.0.1 の場合、バージョン ブランチは v2.0.1 になります。次に、このバージョンの新機能が feat-xxx で開発され、スモーク テストに合格するまで待ってから、gitlab に移動して mr を送信してマージします。ブランチ上のこのバージョンに移行します。各環境テストに合格したら、バージョン ブランチのコードを master にマージし、このバージョン ブランチを削除します。
fix-xxx は修復ブランチを表します。通常、オンラインの問題に対処する場合、欠陥名にちなんで名付けられたブランチが作成されます。欠陥テストに合格した後、mr master ブランチを
にマージします。 注: ここには、feature ブランチで開発によって送信された commit 情報は一般に役に立たない情報であると考えられるという詳細があります。バージョン ブランチにマージする場合は、commit にマージします (マージに gitlab を使用しているため、mr リクエスト スカッシュを開始するときに を確認してください) オプションは問題ありません)、テストが送信された後は、テスト プロセス中のバグを修正するためであっても、関数を最適化するためであっても、すべての commit が保持されます。この目的は警告です。最も良い状況は、テストがすぐに開始されることを願っているためです。この目標を達成するのは困難ですが、残された commit 情報は、
の関数を確認するのに役立ちます。
最初のシナリオ: 通常の開発反復
今回は 1.0 を開発する必要があるため、時間をかけて開発しました。 0 バージョンを例として説明すると、2 つの機能モジュールがあり、1 つはボタンを追加する必要があり、もう 1 つはフォームを追加する必要があります
sequenceDiagram
master->>v1.0.0: 从master切出 v1.0.0
master->>feat-add-button: 从master切出 feat-add-button
master->>feat-add-form: 从master切出 feat-add-button
feat-add-form->>feat-add-form: 开发完成
feat-add-button->>feat-add-button: 开发完成
feat-add-button->>v1.0.0: 在gitlab发起mr到v1.0.0,并合并所有commit
feat-add-form->>v1.0.0: 在gitlab发起mr到v1.0.0,并合并所有commit
v1.0.0->>v1.0.0: 提测
feat-add-button->>feat-add-button: 修复测试bug
feat-add-button->>v1.0.0: 将修复的 commit cherry pick到 v1.0.0
v1.0.0->>master: 在gitlab上mr到master，并将合并信息改成 v1.0.0
ログイン後にコピー
上記のシーケンス図を通して、バージョンは、バージョン ブランチ v1.0.0 と名付けられ、また、2 つの機能ブランチ feat-add-button および feat- に基づいて作成されたことがわかります。このバージョンでは 2 つの関数 add-form を実行し、関数の開発が完了するまで待ってから、mr から gitlab を開始します (マージcommit# に注意してください) ## オプションをここでチェックする必要があります) v1.0.0 にマージすると、v1.0.0 ブランチのコードが開発環境から運用環境へのフローを開始します。その中で、修正や最適化が必要な箇所がある場合は、まず feature ブランチを変更し、その後 cherry pick を version ブランチに移動します。オンラインになったら、バージョン ブランチと次の機能ブランチを削除します。
このプロセスで管理されるコード バージョンは非常に明確です。これはインターセプトされたマスター フラグメントの一部です。
通常の反復には別のシーンがあります。プロセス。それは、開発中に突然PMがやってきて、何らかの不可抗力で機能をカットする必要があると言い出したのです。このとき、まだテストされていないコードや比較的単純な機能であれば、それほど面倒ではありません。しかし、そうであれば、あなたの関数と他の同僚のコードはテストされており、いくつかのバグは修正されています。コミットはすべて絡み合っており、特に多くのファイルの変更を伴う要件は、現時点で対処するのが非常に面倒です。 、他の人のコードを見るだけでなく、自分のコードで間違いを犯さないように注意する必要もあります。現時点でのプロセスは非常に簡単で、既存のバージョン ブランチを削除し、オンラインにする必要がある機能ブランチを再グループ化するだけです。バージョン ブランチは機能ブランチによって結合されていることがわかります。つまり、バージョン ブランチは異なる機能ブランチによって任意に結合できます。これは処理がより便利です
2 番目のシナリオはオンライン バグ修復です
オンラインで修復する必要があるボタンのクリック イベントを例として取り上げます
sequenceDiagram
master->>fix-button-click: 从master切出 fix-button-click
fix-button-click->>fix-button-click: 修复问题并测试
fix-button-click->>master: 从gitlab发起mr合并到master
ログイン後にコピー
In実際、ここでのプロセスは上記とあまり変わりませんが、ここで注意する必要があるのは、オンラインの問題を修正する場合、バグごとに 1 つのコミットが作成され、マスターにマージするときにコミットがマージされないことです。そして、マージ情報をこのバージョン番号に変更する必要があります。たとえば、今回は v1.0.1です。
3 番目のシナリオはマルチバージョンの並列開発です。
このシナリオは通常の反復シナリオと変わりません。複数のバージョンがあるかどうかによって異なります。バージョンがあるので、対応するバージョンのブランチを作成するだけで十分です。各バージョン ブランチの通常の反復プロセスに従うだけです。
Q&A
Q: プッシュやデプロイを実現するために、開発、テストなどの環境に対応するブランチがないのはなぜですか。
A: 私たちのプロセスはこれらの固定ブランチの使用を断念しました。理由はいくつかあります。
コードがテストされた後、開発環境からテスト環境、さらには UAT (プレリリース) 環境まで、さまざまな環境でコードが変更された場合、これらのブランチのコードを維持するために、コードを各環境ブランチに同期させるのは少し面倒です。バージョン ブランチではこの問題は発生せず、バージョン ブランチは 1 つだけ存在し、さまざまな環境に対応できます。
複数のバージョンの並行開発に便利です。複数のバージョン ブランチを作成できるため、並行開発中にさまざまなテスト環境にデプロイするのに便利です。バージョン間のモジュールに密接な関連性がない場合は、それらを並行してテストすることもできます。 ＃＃＃＃＃＃＃＃＃＃＃＃セマンティック。バージョン ブランチを使用すると、ブランチ名を通じて現在開発中のブランチを知ることができます。
Q: master ブランチの変更に対処する方法
推奨学習: "
Git ビデオ チュートリアル
"
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
