「GitHub」と「GitLab」を比較–2大Git VCSの相違点と類似点

今回は「「GitHub」と「GitLab」を比較–2大Git VCSの相違点と類似点」についてご紹介します。

関連ワード （ソフトウェア等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、ZDNet Japan様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

　筆者はよく次のような質問を受ける。「プログラミングプロジェクトで使う分散型バージョン管理システム（VCS）は、『GitHub』と『GitLab』のどちらがよいのか」

　まず、社内プログラムを構築するだけの場合は、自社サーバー上で単独で使用できるローカルGitインスタンスがあれば十分だ。Gitは自社サーバーやクラウド上で集中型のVCSとして使用することもできる。VCSを自分で構築できるなら、VCSサービスのサブスクリプションは必要ない。このモデルでは、世界中に散在するチームやパートナーとともにプロジェクトを簡単に運営することができる。

　しかし、ホスト型Gitサービスのさまざまな付加機能が必要な人もいるだろう。本記事では、ソフトウェアサービスの違いから、インターフェースと中核的な価値の類似点までを詳しく解説する。

　主な違いは、GitLabに継続的インテグレーション／継続的デリバリー（CI/CD）とDevOpsワークフローが組み込まれていることだ。GitHubでは好みのCI/CDツールを使用できるが、それらを自分で統合する必要がある。GitHubユーザーは通常、「Jenkins」「CircleCI」「TravisCI」といったサードパーティーのCIプログラムを使用する。

　もう1つの重要な違いは、GitHubが速度を優先しているのに対し、GitLabは信頼性を重視していることだ。

　具体的にいうと、GitHubは新しいブランチ（新たに加えた独自の変更）をマスター（メイン）ブランチとマージすることを提唱している。そうすることで迅速な展開が可能になり、問題が発生しても古いバージョンをすぐに復元できる。

　GitLabのワークフローでは、一連の変更を加えるたびに、マスターブランチの安定版とは別に複数の個別の安定版ブランチが作成される。最低でも、本番用と本番前の安定版ブランチが作成されることになる。複数ブランチのアプローチでは、複数段階のテストプロセスが必要だ。マージリクエストの際の1回のコードレビューでは足りない。

　もちろん、どちらも自分が望むように機能させることができるが、2つのシステムが提唱するアプローチには明白な違いがある。

　もう1つの大きな違いは、GitLabが包括的なソフトウェア開発ソリューションを提供することだ。GitLabが包括的なDevOpsプラットフォームとして売り込んでいることには理由がある。とはいえ、GitLabは一部のサードパーティープログラム／プラットフォーム（「Jira」「Microsoft Teams」「Slack」「Gmail」など）や、その他の多数のアプリやプラットフォームとの統合を提供している。

　一方、GitHubがプログラム内で提供するサービスは比較的少ないが、多くの外部プログラムおよびサービスと統合する方法が用意されている。これには、GitHubが同サービスとの統合用に開発したソフトウェアや、「GitHub Marketplace」で入手可能な他の多数のプログラムがある。

　だが、相違点よりも類似点の方が多い。いずれも「Linux」サーバー上で運用され、問題追跡システムを備えており、幅広いサードパーティー統合ツールとインポートツールを提供する。

　また、どちらも上級開発者向けのコマンドラインインターフェース（CLI）を搭載し、新人プログラマー向けのウェブベースインターフェースも提供する。

　GitLabの場合、ユーザーインターフェースはGitLab独自のデザインシステム「Pajamas」を使用し、「Vue.js」で記述されている。GitHubのユーザーインターフェース「Desktop」は、「Windows」や「macOS」のプログラムとして利用できる。「Visual Studio」をGitHubで使用することも可能になった。

　GitHubもGitLabもオープンソースをサポートしているが、リポジトリー自体は複合的なプログラミングモデルを使用している。GitLabはオープンコアのビジネスモデルを採用した。このモデルでは、「GitLab Community Edition」が無料かつオープンソースのままで、「GitLab Enterprise Edition」はより多くの機能を提供し、サポートが付属する。