なぜ企業は gitlab を使用するのでしょうか?ワークフローはどのようなものですか?-Git-php.cn

なぜ企業は gitlab を使用するのでしょうか?ワークフローはどのようなものですか?

青灯夜游

リリース： 2023-03-23 19:49:07

転載

2062 人が閲覧しました

なぜ企業は github や gitee ではなく gitlab を使用するのでしょうか?次の記事ではその理由と Gitlab のワークフローについて説明しますので、皆様のお役に立てれば幸いです。

なぜ企業は gitlab を使用するのでしょうか?ワークフローはどのようなものですか?

公式の言い伝え:

GitLab は、ネットワークに基づいた MIT ライセンスを使用して GitLabInc. によって開発された Git ウェアハウス管理ツールであり、## があります。 #wiki と問題追跡機能。コード管理ツールとして Git を使用し、これをベースにして Web サービスを構築します。

GitLab は、ウクライナのプログラマー Dmitriy Zaporozhets と Valery Sizov によって開発され、
Ruby 言語で書かれています。その後、一部の部分を Go 言語で書き直しました。 2018 年 5 月の時点で、同社には約 290 人のチームメンバーと 2,000 人を超えるオープンソース貢献者がいます。 GitLab は、IBM、Sony、Jülich Research Center、NASA、Alibaba、Invincea、O’Reilly Media、Leibniz-Rechenzentrum (LRZ)、CERN、SpaceX などの組織で使用されています。

GitLab には Github と同様の機能があり、ソースコードを参照したり、欠陥やコメントを管理したりすることができます。リポジトリへのチームアクセスを管理し、コミットされたバージョンの参照を容易にし、ファイル履歴ライブラリを提供します。チームメンバーは、内蔵の簡易チャットプログラム（ウォール）を使用してコミュニケーションできます。コードの再利用を容易にするコードスニペット収集機能も提供します。

なぜ

なぜ企業は github や gitee ではなく gitlab を使用するのでしょうか?

プロジェクトのバージョンが増え、開発者が増えると、単純な Git 管理では依然として多くの問題が発生します。一方で、開発者には過大な権限があり、他方では、運用および保守担当者の権限が不足します。私たちの開発プロセスをよく理解していないため、より良いツールを使用してプロジェクトを管理することを考えています。そこで私はgitlabを思いつきました。

CI/CD

ここでの CI/CD は、実際には継続的インテグレーション (CI)、継続的デリバリー、継続的デプロイメント (CD) を指します。CI はソフトウェアエンジニアが行うものです。毎日更新されたコードのコピーを共有の場所に頻繁に配信するプロセス。すべての開発作業はスケジュールされた時間またはイベントに統合され、テストとビルド作業が自動化されます。 CI を使用すると、開発プロセス中に発生したエラーを適時に発見できるため、開発サイクル全体が短縮されるだけでなく、ソフトウェアエンジニアの作業がより効率的になります。 CD は継続的デリバリー (CD) の略で、高品質のアプリケーションを作成するためのパズルの 2 番目のピースです。 CD は、テクノロジとツールを使用して実稼働段階のコードを迅速に提供するソフトウェア開発分野です。配送サイクルの多くが自動化されているため、これらの配送は迅速に完了できます。

CI/CD ワークフローについては後ほど詳しく紹介します

権限制御とコラボレーション

GitLab プロジェクトで共同作業する最も簡単な方法方法は、共同作業者に Git リポジトリへの直接プッシュ権限を与えることです。プロジェクト設定の「メンバー」セクションからプロジェクトにライターを追加し、新しいコラボレータをアクセスレベル (. コラボレータに「開発者」以上のアクセスレベルを与えることで、このユーザーはリポジトリに直接コミットできます)または制限なしで分岐します。

コラボレーションをより分離するもう 1 つの方法は、マージリクエストを使用することです。その利点は、プロジェクトを閲覧できるすべての共同作業者が、制御された方法でプロジェクトに貢献できることです。直接アクセスできるコラボレータは、ブランチを作成したり、このブランチにコミットしたり、マスターまたは他のブランチへのマージリクエストを開くだけで済みます。リポジトリに対するプッシュ権限を持たない共同作業者は、リポジトリを「フォーク」し、コピーにコミットして、そのコピーからメインプロジェクトへのマージリクエストを開くことができます。このモデルにより、プロジェクト所有者は、リポジトリに対してどのようなコミットが行われるか、また未知の共同作業者からの貢献がいつ許可されるかを完全に制御できます。 (これは github に似ていますが、現在 github のプライベートライブラリは有料です)

GitLab でのリクエストと問題のマージは、長年にわたる議論の主要な部分です。各マージリクエストでは、全体的なトピックだけでなく、変更が提案された行 (これにより軽量のコードレビューが可能になります) についてのディスカッションが可能になります。どちらもユーザーに割り当てることも、マイルストーンインターフェイスに編成することもできます。

このセクションでは主に GitLab の Git 関連機能に焦点を当てますが、成熟したシステムとして、GitLab はプロジェクト Wiki やシステムメンテナンスツールなど、共同作業に役立つ他の多くの製品を提供します。 GitLab の優れた点の 1 つは、サーバーが起動して実行されると、構成ファイルを調整したり、サーバーに SSH 接続したりする必要がほとんどなくなり、ほとんどの管理と日常使用がブラウザインターフェイス内で実行できることです。

Git Flow ワークフローの概要

一般的に、企業内のプロジェクトは複数の人によって同時に開発されるため、Git ブランチをどのように管理するかが重要な問題になります。。

それでは、ここで git flow ワークフローを紹介する必要があります。

コードの実行環境から始めましょう。一般に、コードが実行される環境として、企業チームには少なくとも次の環境があります。

ローカル開発環境: 開発者による自己テスト。ローカルにデプロイされた静的サーバーにすることもできます。もちろん、実行中の npm サーバーと同様の環境にすることもできます。ローカル環境で実行されるコードは、任意のブランチの
dev 開発環境にすることができます。この環境は次のとおりです。開発に使用唯一のパブリック
テストおよびプレリリース環境は、開発ブランチ dev によって生成されたコードを使用してデプロイされます。この環境は、開発ブランチリリースによって生成されたコードを使用してデプロイされ、唯一のパブリック環境です。
オンライン運用環境: この環境は、開発ブランチマスターによって生成されたコードを使用してデプロイされます。唯一のパブリック

対応する git ブランチモデルは、

の対応するブランチ戦略です。

# は次のとおりです

#master: ブランチを保護します。これは本番環境のブランチです

release: 保護されたブランチ。開発されたすべてのブランチは、リリースブランチにマージされ、テスト用にテスターに提供されます。
feature-*: function ブランチ、特定の関数開発
dev /test-*: 開発ブランチとダーティブランチ。全員が共有する開発環境に対応します。上記のコードは、開発者がセルフテストを実行し、日常および非日常のデバッグに対処できるように、パブリック開発環境にデプロイされます
hotfix-*: バグ緊急修復ブランチ。マスターに直接マージできます (リリースが複数の機能ブランチをマージする場合、テスト中に緊急修復が必要な buf を検出します。緊急修復テストが完了すると、マスターに直接マージされます。リリースにマージされてからリリースからマスターにマージされた場合、テスト中の関数はまだオンラインになる準備ができていない可能性があります。関数は直接起動されます)

ワークフローの概要