序文
Git
名前はとても大きいです, 誰もがそれを聞いたことがあると思います. 有名な同性出会い系ウェブサイトは、唯一のバージョン ライブラリ形式としてホストされているプラットフォームに基づいていますGitHub
。Git
この記事では、Git
の詳しい使い方を紹介するのではなく、Git
をベースとした開発ブランチの処理仕様を紹介するだけなので、Git
ある程度の理解が必要です。
簡単な説明
Git
経営において最も重要なポイントは支店管理です。プロジェクト開発では、Git
一般に次の関連ブランチが関係します。
- master/main: master ブランチ。バージョンの正式リリースのコードは、このブランチのコードでコンパイルされます。多くの場合、保護されたブランチとして設定されます。
- dev/develop: 開発ブランチ。開発環境はこのブランチに基づいて構築されます。
- feature-*: 特定の機能を開発するために分岐します。
- hotfix- /fix- :
bug
ブランチを修正します。 - release-*: プラットフォームのテストに使用されます。
小規模なプロジェクトの場合、参加者が少ない場合は、ブランチを維持することしかできませmaster
んdevelop
。
これはあくまで通常のプロジェクトの支店管理であり、参考程度であり、具体的な状況については詳細に分析する必要があります。
実際の状況
現在プロジェクトを開発中で、コードは自分で作成し、短期間の反復作業を行っています。
コードは毎日develop
ブランチをベースに書かれており、関数を書いた後は直接develop
ブランチにサブミットしてテスト環境を構築してテストを行い、問題があれば直接修正してブランチにサブミットするという流れですdevelop
。つまり、develop
ブランチ上のコードはテスト環境で使用されるコードです。
反復の最後に、develop
ブランチを にマージしmaster
、正式バージョンを作成しますtag
。
開発プロセス
- 枝 ( )から
develop
新しい枝を引きますfeature-*/fix-*
。 - 開発が完了したら、ブランチをリモート ウェアハウスに送信します。
- マージ リクエスト (
merge request
,feature-*
->develop
) を作成し、プロジェクト マネージャーにコード レビューを実施してブランチを にマージするように要求しますdevelop
。 - テストに合格したら、
develop
ブランチをmaster
ブランチにマージし、対応するtag
(通常は正式なバージョン番号) でマークします。
上記のプロセスは、プロジェクトのバージョンごとに繰り返されます。
問題が解決しました
反復プロセス ( 1.1
) 中に、最後の正式バージョン ( ) がリリースされたことが判明し、修復が必要な1.0
大規模な修正があり、非常に緊急でしたが、現在のブランチでは多くのバージョンの機能が変更されており、テストが完了していないため、現在のブランチに基づいて直接変更を行うことはできません。bug
develop
1.1
develop
幸いなことに、以前の1.0
バージョンがリリースされたとき、develop
ブランチのコードはブランチにマージされていましたが、今後はブランチからコードを取得して変更し、変更した内容をリリース用ブランチにマージするだけで済みますmaster
。ここで注意したいのは、後でブランチを開発するときは、まず のコードをプルしてマージする必要があり、競合がある場合は、次回ブランチからブランチにマージするときに競合が発生しないように変更します。master
master
develop
master
develop
master
要約する
Git
プロセス設計は相変わらず素晴らしく、慣れてしまえば共同開発作業も容易に行えるので、時間をかけて理解することをお勧めします。- さまざまな規模やシナリオのプロジェクトに対して、
Git
ワークフローを独自に変更および最適化することができ、最終的な目標は、プロジェクト システムを便利に、迅速かつ正確に構築することです。
この記事では主に、反復プロセス中にbug
オンラインの緊急事態を修復する必要がある場合のgit
ワークフローの設計について説明します。つまり、オンライン環境が常にmaster
ブランチ コードを使用するようにするためです。
master
新しいブランチをチェックアウトして変更を加えます。- 変更したコードを
master
ブランチにマージし、コンパイルして公開し、 を押しますtag
。 - 変更された
master
ブランチを現在開発されているdevelop
ブランチにマージして競合を解決します。 - 通常の開発プロセス。
参考
Git バージョン管理仕様 (Git Flow)
製品の迅速なイテレーション中のブランチ管理に Git を使用するための詳細な手順