Git を使用してバージョン管理を調べる

  • 5 分

バージョン 管理システム (VCS) にはさまざまな種類がありますが、一般に、一元化および分散として分類できます。 近年 (部分的には DevOps の人気の高まりにより) 後者のカテゴリは大きな人気を集め、Git は最新のソフトウェア開発における事実上の標準となりました。 この特定の VCS は、サンプル シナリオで組織に最適な選択肢です。特に、DevOps 移行のターゲット プラットフォームとして GitHub を使用する意図を考慮します。 このユニットでは、Git をバージョン管理として使用する方法について説明します。

一元化されたバージョン管理システムと分散バージョン管理システムの利点を比較した表のスクリーンショット。

一元化されたバージョン管理と分散バージョン管理

集中バージョン管理システム (CVCS) と分散バージョン管理システム (DVCS) の両方で、ソフトウェア開発プロジェクトの変更を管理および追跡する機能が提供されます。 それらの主な違いは、リポジトリとコラボレーションを実装する方法に関連しています。 具体的には次のとおりです。

  • リポジトリの場所: 一元化されたシステムでは、プロジェクトの完全な履歴を含むリポジトリの単一の一元化されたインスタンスがあります。 分散システムでは、各チーム メンバーは通常、リポジトリ全体の完全に機能するローカル コピーを 1 つ持ち、完全なバージョン履歴を含む可能性があります。
  • ネットワーク接続: 一元化されたシステムでは、更新や履歴の取得など、多くのアクションを実行するために、リポジトリの一元化されたインスタンスへのアクセスが必要です。 分散システムでは、リポジトリのローカル コピーに対してすべてのアクティビティを実行できます。
  • コラボレーション モデル: 一元化されたシステムでは、開発者は、変更を行って変更をコミットする前に、ネットワーク経由でリポジトリに接続しながら、リポジトリの一元化されたインスタンスからファイルをチェックアウトします。 これにより、変更が他のユーザーによってファイルからチェックアウトされるのを防ぐことができます。 分散システムでは、開発者はリポジトリのローカル コピーに変更を加えてコミットします。この変更は、後で他のコピーと同期されます。
  • 分岐とマージ モデル: 一元化されたシステムでは、通常、分岐とマージには他のユーザーとの調整が必要です。 分散システムでは、ブランチをローカル コピーに個別に作成し、後でマージすることができます。

分散モデルは (従来の意味で) 中央リポジトリを持つことに依存しませんが、GitHub、GitLab、Bitbucket などのサービスによってホストされるリポジトリの 1 つのコピーを実装するのが一般的です。 このインスタンスは、コラボレーションと同期の焦点として機能します。

一元化および分散バージョン管理システムリポジトリとコラボレーションのスクリーンショット。

Git の用語

Git を使い慣れるためには、その用語を理解することが重要です。 一部の概念は Git に固有であり、他の DVCS と区別されます。 最も基本的な Git 用語は次のとおりです。

  • 作業ツリー: プロジェクトのすべてのファイルを含むディレクトリ構造。
  • リポジトリ (一般に リポジトリと呼ばれます): 作業ツリーの最上位にあるディレクトリ。プロジェクトのすべてのファイルと、これらのファイルのバージョン履歴をホストします。
  • 複製: ローカル コンピューター上にリモート リポジトリのコピーを作成し、アクセス権を持つプロジェクトで作業するアクション。
  • フォーク: アクセス権のないプロジェクトで動作するリモート リポジトリの GitHub でホストされるコピーを作成するアクション。 フォークは通常、他のユーザーのプロジェクトに貢献する場合や、そのようなプロジェクトの独自のバージョンを作成する場合に使用されます。 元のリポジトリへの書き込みアクセス権はありませんが、フォークを完全に管理できます。
  • コミット: 特定の時点でリポジトリ内のファイルに加えられた変更のスナップショット。 コミットは、変更の記録と保存に使用されます。
  • ステージング領域 は、作業ツリー内のファイルに対する変更がコミットされる前に準備される中間の場所 (リポジトリの一部ではない) です。 これにより、開発者はコミットする変更を選択できます。
  • ブランチ: リンクされたコミットの一連の名前。 簡単に言うと、ブランチはプロジェクトの個別のバージョンを表します。 これにより、メイン バージョンに影響を与えることなく、プロジェクトのさまざまな部分で同時に作業できます。 ブランチ内の最新のコミットは ヘッドと呼ばれます。 リポジトリを初期化するときに自動的に生成される既定のブランチは、 メイン または マスターと呼ばれます。
  • マージ: あるブランチ (またはコミット) の変更を別のブランチに結合するプロセス。 これにより、あるブランチの変更が別のブランチに統合されます。
  • オブジェクト: リポジトリで使用できる 4 種類のエンティティのいずれか。 これらのエンティティには、個々のファイルを表す BLOB 、作業ツリーを表す ツリー 、特定のバージョンの作業ツリーを表す コミット 、および個々のコミットに割り当てられたラベルである *タグが含まれます。
  • ハッシュ: オブジェクトの内容を表す、自動的に生成された一意の固定長識別子。 そのオブジェクトが変更されるたびに、ハッシュも変更されます。 これにより、Git はリポジトリ内のどのコンテンツが更新されたかを判断できます。
  • リモート: (ローカルリポジトリ以外の) 別のリポジトリへの参照。通常は、リポジトリのサービスでホストされるインスタンスを指します。 これは、プッシュ操作とプル操作の既定値として機能します。
  • プル: リモート リポジトリから変更をフェッチし、それらを現在のブランチにマージするアクション。
  • プッシュ: ローカル コミットをリモート リポジトリに送信し、ローカルで行われた変更で更新するアクション。
  • フェッチ: リモート リポジトリから変更を自動的にマージせずに取得するアクション。 これにより、マージを適用する前にレビューが可能になります。
  • Pull request: Git ベースのホスティング プラットフォーム (GitHub など) の機能。開発者は変更を提案し、ターゲット ブランチにマージするように要求できます。

Git には、Linux Bash や Windows コマンド プロンプトなどのコマンド シェルを使用してバージョン管理を完全に実装および管理する機能を提供する広範なコマンド セットもあります。 または、GitHub Desktop などのデスクトップ アプリケーションを使用して Git を管理することもできます。 Git ベースのホスティング プラットフォームは、サービス側リポジトリとの対話を容易にする Web インターフェイスを提供します。

Git と GitHub

前述のように、Git はマルチプラットフォームのオープンソース DVCS であり、ローカル リポジトリを使用してコラボレーションを容易にし、リモート リポジトリと同期できます。 GitHub は、Git リポジトリのホスティング プラットフォームを提供するクラウドベースのサービスです。 次のサポートを含めることで、Git 機能の範囲を拡張します。

  • リモート リポジトリ: 分散チーム間の対話を促進します。
  • コラボレーション ツール: 問題、ディスカッション、プル要求、通知、ラベル、アクション、フォーク、Wiki、プロジェクトなどの機能を提供します。
  • Web ベースのインターフェイス: Git コマンドを使用する必要性を最小限に抑える
  • 分岐保護: マージを実行する前に満たす必要がある条件を適用します (たとえば、完了した pull request レビューなど)。