Git-basic-concepts

提供:Dev Guides
移動先:案内検索

Git-基本概念

バージョン管理システム

  • バージョン管理システム(VCS)*は、ソフトウェア開発者が協力して作業の完全な履歴を維持できるようにするソフトウェアです。

以下は、VCSの機能です-

  • 開発者が同時に作業できるようにします。
  • 互いの変更を上書きすることはできません。
  • すべてのバージョンの履歴を保持します。

VCSの種類は次のとおりです-

  • 集中型バージョン管理システム(CVCS)。
  • 分散/分散バージョン管理システム(DVCS)。

この章では、分散バージョン管理システム、特にGitのみに集中します。 Gitは分散バージョン管理システムに分類されます。

分散バージョン管理システム

集中型バージョン管理システム(CVCS)は、中央サーバーを使用してすべてのファイルを保存し、チームの共同作業を可能にします。 しかし、CVCSの主な欠点は、その単一障害点、つまり中央サーバーの障害です。 残念ながら、中央サーバーが1時間ダウンすると、その時間中は誰もコラボレーションできなくなります。 最悪の場合でも、中央サーバーのディスクが破損し、適切なバックアップが取られていないと、プロジェクトの全履歴が失われます。 ここでは、分散バージョン管理システム(DVCS)が登場します。

DVCSクライアントは、ディレクトリの最新のスナップショットをチェックアウトするだけでなく、リポジトリを完全にミラーリングします。 サーバーがダウンした場合、任意のクライアントのリポジトリをサーバーにコピーして復元することができます。 すべてのチェックアウトは、リポジトリの完全バックアップです。 Gitは中央サーバーに依存しないため、オフラインのときに多くの操作を実行できます。 オフライン時に変更をコミットし、ブランチを作成し、ログを表示し、他の操作を実行できます。 ネットワーク接続が必要なのは、変更を公開して最新の変更を行う場合のみです。

Gitの利点

無料でオープンソース

GitはGPLのオープンソースライセンスの下でリリースされます。 インターネット経由で自由に利用できます。 Gitを使用すると、1円も支払うことなく、プロパティプロジェクトを管理できます。 オープンソースであるため、ソースコードをダウンロードし、要件に応じて変更を行うこともできます。

速くて小さい

ほとんどの操作はローカルで実行されるため、速度の面で大きな利点があります。 Gitは中央サーバーに依存しません。そのため、操作ごとにリモートサーバーと対話する必要はありません。 Gitのコア部分はCで記述されているため、他の高レベル言語に関連する実行時のオーバーヘッドが回避されます。 Gitはリポジトリ全体をミラーリングしますが、クライアント側のデータのサイズは小さくなります。 これは、クライアント側でデータを圧縮および保存する際のGitの効率を示しています。

暗黙的なバックアップ

データのコピーが複数ある場合、データを失う可能性は非常にまれです。 クライアント側に存在するデータはリポジトリをミラーリングするため、クラッシュまたはディスクの破損が発生した場合に使用できます。

セキュリティ

Gitは、セキュアハッシュ関数(SHA1)と呼ばれる一般的な暗号化ハッシュ関数を使用して、データベース内のオブジェクトに名前を付けて識別します。 すべてのファイルとコミットはチェックサムされ、チェックアウト時にチェックサムによって取得されます。 これは、Gitを知らない限り、Gitデータベースからファイル、日付、コミットメッセージおよびその他のデータを変更することは不可能であることを意味します。

強力なハードウェアは不要

CVCSの場合、中央サーバーはチーム全体のリクエストに応えるのに十分強力である必要があります。 小さなチームの場合、これは問題ではありませんが、チームの規模が大きくなると、サーバーのハードウェア制限がパフォーマンスのボトルネックになる可能性があります。 DVCSの場合、開発者は変更をプッシュまたはプルする必要がない限り、サーバーと対話しません。 面倒な作業はすべてクライアント側で行われるため、サーバーのハードウェアは非常にシンプルにできます。

より簡単な分岐

CVCSは安価なコピーメカニズムを使用します。新しいブランチを作成すると、すべてのコードが新しいブランチにコピーされるため、時間がかかり、効率的ではありません。 また、CVCSでのブランチの削除とマージは複雑で時間がかかります。 ただし、Gitによるブランチ管理は非常に簡単です。 ブランチの作成、削除、マージには数秒しかかかりません。

DVCSの用語

ローカルリポジトリ

すべてのVCSツールは、作業用コピーとしてプライベートな職場を提供します。 開発者はプライベートな職場で変更を行い、コミット後、これらの変更はリポジトリの一部になります。 Gitは、リポジトリ全体のプライベートコピーを提供することで、さらに一歩前進します。 ユーザーは、このリポジトリを使用して、ファイルの追加、ファイルの削除、ファイルの名前変更、ファイルの移動、変更のコミットなど、多くの操作を実行できます。

作業ディレクトリとステージング領域またはインデックス

作業ディレクトリは、ファイルがチェックアウトされる場所です。 他のCVCSでは、開発者は通常、変更を行い、変更をリポジトリに直接コミットします。 しかし、Gitは別の戦略を使用します。 Gitは、変更されたすべてのファイルを追跡しません。 操作をコミットするたびに、Gitはステージング領域にあるファイルを探します。 ステージング領域に存在するファイルのみが、すべての変更されたファイルではなく、コミットの対象と見なされます。

Gitの基本的なワークフローを見てみましょう。

  • ステップ1 *-作業ディレクトリからファイルを変更します。
  • ステップ2 *-これらのファイルをステージング領域に追加します。
  • ステップ3 *-ステージング領域からファイルを移動するコミット操作を実行します。 プッシュ操作後、変更はGitリポジトリに永続的に保存されます。

Gitチュートリアル

「sort.c」と「search.c」という2つのファイルを変更し、各操作に2つの異なるコミットが必要だとします。 ステージング領域に1つのファイルを追加して、コミットを実行できます。 最初のコミットの後、別のファイルに対して同じ手順を繰り返します。

# First commit
[bash]$ git add sort.c

# adds file to the staging area
[bash]$ git commit –m “Added sort operation”

# Second commit
[bash]$ git add search.c

# adds file to the staging area
[bash]$ git commit –m “Added search operation”

Blobは* B inary L arge Ob * jectを表します。 ファイルの各バージョンはblobで表されます。 Blobはファイルデータを保持しますが、ファイルに関するメタデータは含みません。 これはバイナリファイルであり、Gitデータベースでは、そのファイルのSHA1ハッシュと呼ばれます。 Gitでは、ファイルは名前でアドレス指定されません。 すべてがコンテンツに対応しています。

ツリーは、ディレクトリを表すオブジェクトです。 それは他のサブディレクトリと同様にブロブを保持します。 ツリーは、ツリーオブジェクトの SHA1 ハッシュとも呼ばれるBLOBとツリーへの参照を格納するバイナリファイルです。

コミット

コミットは、リポジトリの現在の状態を保持します。 コミットは SHA1 ハッシュによっても名前が付けられます。 コミットオブジェクトはリンクリストのノードと考えることができます。 すべてのコミットオブジェクトには、親コミットオブジェクトへのポインタがあります。 特定のコミットから、親ポインターを見てコミットの履歴を表示することにより、前に戻ることができます。 コミットに複数の親コミットがある場合、その特定のコミットは2つのブランチをマージすることによって作成されています。

ブランチは、別の開発ラインを作成するために使用されます。 デフォルトでは、Gitにはmasterブランチがあります。これはSubversionのトランクと同じです。 通常、新しい機能で動作するブランチが作成されます。 機能が完成すると、それはmasterブランチにマージされ、ブランチを削除します。 すべてのブランチはHEADによって参照されます。HEADは、ブランチ内の最新のコミットを指します。 コミットを行うたびに、HEADは最新のコミットで更新されます。

Tags

タグは、リポジトリ内の特定のバージョンに意味のある名前を割り当てます。 タグはブランチに非常に似ていますが、違いはタグが不変であることです。 つまり、タグはブランチであり、誰も変更するつもりはありません。 特定のコミット用にタグが作成されると、新しいコミットを作成しても更新されません。 通常、開発者は製品リリース用のタグを作成します。

クローン

クローン操作により、リポジトリのインスタンスが作成されます。 クローン操作は、作業コピーをチェックアウトするだけでなく、リポジトリ全体をミラーリングします。 ユーザーは、このローカルリポジトリを使用して多くの操作を実行できます。 ネットワーキングが関係するのは、リポジトリインスタンスが同期されているときだけです。

Pull

プル操作は、リモートリポジトリインスタンスからローカルインスタンスに変更をコピーします。 プル操作は、2つのリポジトリインスタンス間の同期に使用されます。 これは、Subversionの更新操作と同じです。

Push

プッシュ操作は、ローカルリポジトリインスタンスからリモートインスタンスに変更をコピーします。 これは、変更をGitリポジトリに永続的に保存するために使用されます。 これは、Subversionのコミット操作と同じです。

HEAD

HEADはポインターであり、常にブランチの最新のコミットを指します。 コミットを行うたびに、HEADは最新のコミットで更新されます。 ブランチのヘッドは .git/refs/heads/ ディレクトリに保存されます。

[CentOS]$ ls -1 .git/refs/heads/
master

[CentOS]$ cat .git/refs/heads/master
570837e7d58fa4bccd86cb575d884502188b0c49

リビジョン

リビジョンは、ソースコードのバージョンを表します。 Gitのリビジョンはコミットによって表されます。 これらのコミットは、 SHA1 セキュアハッシュによって識別されます。

URL

URLはGitリポジトリの場所を表します。 Git URLは設定ファイルに保存されます。

[tom@CentOS tom_repo]$ pwd
/home/tom/tom_repo

[tom@CentOS tom_repo]$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = [email protected]:project.git
fetch = +refs/heads/*:refs/remotes/origin/*