ウェブサイト検索

Linux で Git バージョン管理システムを使用する方法 [総合ガイド]


バージョン管理 (リビジョン管理またはソース管理) は、ファイルまたはファイルのコレクションに対する変更を長期にわたって記録し、後で特定のバージョンを呼び出せるようにする方法です。バージョン管理システム ( 略してVCS) は、ファイルシステム上のファイルへの変更を記録するツールです。

バージョン管理システムは数多くありますが、 現在、特にソース コード管理に最も人気があり、頻繁に使用されているのはGitです。バージョン管理は、ソース コードだけでなく、コンピュータ上のほぼすべての種類のファイルに対して実際に使用できます。

バージョン管理システム/ツールは、個人またはグループが次のことを可能にするいくつかの機能を提供します。

  • プロジェクトのバージョンを作成する
  • 変更を正確に追跡し、競合を解決する
  • 変更を共通バージョンにマージします。
  • 選択したファイルまたはプロジェクト全体に対する変更をロールバックして元に戻す
  • プロジェクトの過去のバージョンにアクセスして、経時的な変更を比較する
  • 問題の原因となっている可能性のあるものを最後に変更した人を確認する
  • プロジェクトの安全なオフサイト バックアップを作成する
  • 複数のマシンを使用して 1 つのプロジェクトなどに取り組む

Git などのバージョン管理システム下のプロジェクトには、主に次の 3 つのセクションがあります。

  • リポジトリ: プロジェクト ファイルの状態や変更を記録するためのデータベース。これには、新しいプロジェクトに必要なすべての Git メタデータとオブジェクトが含まれています。これは通常、ネットワーク上の別のコンピュータまたはリモート サーバーからリポジトリのクローンを作成するときにコピーされるものであることに注意してください。
  • 作業ディレクトリまたは作業領域: 作業(追加、削除、その他の変更アクションを実行)できるプロジェクト ファイルのコピーが保存されます。
  • ステージング領域: Git ディレクトリ内のファイル (Git ではインデックスと呼ばれる)。変更に関する情報が保存され、リポジトリにコミット (ファイルまたはファイルのセットの状態を保存) する準備ができています。< /li>

VCS には主に 2 つのタイプがあり、主な違いはリポジトリの数です。

  • 集中バージョン管理システム (CVCS): ここでは、プロジェクト チームの各メンバーが独自のローカル作業ディレクトリを取得しますが、変更をコミットするのは 1 つの中央リポジトリのみです。
  • 分散バージョン管理システム (DVCS): これにより、プロジェクト チームの各メンバーは、コミットできる独自のローカル作業ディレクトリと Git ディレクトリを取得します。個人がローカルでコミットを行った後は、その変更を中央リポジトリにプッシュするまで、他のチーム メンバーはその変更にアクセスできません。 Git は DVCS の一例です。

さらに、Git リポジトリはベア (作業ディレクトリを持たないリポジトリ) または非ベア (作業ディレクトリのあるリポジトリ) にすることができます。ディレクトリ)。 共有 (またはパブリックまたは中央) リポジトリは常にベアである必要があります。すべての Github リポジトリはベアです。

Git でバージョン管理を学ぶ

Git は、無料のオープン ソースで、高速、強力、分散型、使いやすく、人気のあるバージョン管理システムであり、大規模なプロジェクトで非常に効率的であり、優れた分岐およびマージ システムを備えています。これは、Git ディレクトリに保存されるミニ ファイルシステムの一連のスナップショットのようにデータを処理するように設計されています。

Git でのワークフローは非常に簡単です。作業ディレクトリ内のファイルに変更を加え、変更されたファイルだけを選択してステージング領域に追加し、次のコミットの一部にします。

準備ができたら、コミットを実行します。これにより、ステージング領域からファイルが取得され、そのスナップショットが Git ディレクトリに永続的に保存されます。

Linux にGit をインストールするには、選択したディストリビューションに適切なコマンドを使用します。

$ sudo apt install git   [On Debian/Ubuntu]
$ sudo yum install git   [On CentOS/RHEL]

Git をインストールした後、次のようにフルネームと電子メール アドレスを入力して、Git に自分の身元を伝えることをお勧めします。

$ git config --global user.name “Aaron Kili”
$ git config --global user.email “”

Git 設定を確認するには、次のコマンドを使用します。

$ git config --list 

新しい Git リポジトリを作成します

共有 リポジトリや一元化されたワークフローは非常に一般的であり、ここではそれを説明します。たとえば、組織内のさまざまな部門のシステム管理者/プログラマ向けにリモート中央リポジトリをセットアップし、bashscripts というプロジェクトに取り組む任務を与えられていると仮定します。 >/projects/scritpts/ サーバー上にあります。

リモート サーバーにSSH で接続し、必要なディレクトリを作成し、sysadmins というグループを作成し (すべてのプロジェクト チーム メンバーをこのグループに追加します。例: ユーザー管理者)、適切な権限を設定します。このディレクトリ。

# mkdir-p /projects/scripts/
# groupadd sysadmins
# usermod -aG sysadmins admin
# chown :sysadmins -R /projects/scripts/
# chmod 770 -R /projects/scripts/

次に、ベア プロジェクト リポジトリを初期化します。

# git init --bare /projects/scripts/bashscripts

この時点で、プロジェクトの中央ストレージ機能である裸のGit ディレクトリが正常に初期化されました。ディレクトリのリストを実行して、そこにあるすべてのファイルとディレクトリを確認してみてください。

# ls -la /projects/scripts/bashscripts/

Git リポジトリのクローンを作成する

次に、SSH 経由でリモート共有 Git リポジトリのクローンをローカル コンピューターに作成します (Web サーバーがインストールされ、適切に構成されている場合は、HTTP/HTTPS 経由でクローンを作成することもできます。 Github 上のほとんどのパブリック リポジトリの場合)、例:

$ git clone ssh://_server_ip:/projects/scripts/bashscripts 

特定のディレクトリ (~/bin/bashscripts) にクローンを作成するには、以下のコマンドを使用します。

$ git clone ssh://_server_ip:/projects/scripts/bashscripts ~/bin/bashscripts

これで、非ベアリポジトリ (作業ディレクトリあり) にプロジェクトのローカル インスタンスができました。プロジェクトの初期構造を作成できます (つまり、README.md ファイル、さまざまなカテゴリのスクリプトのサブディレクトリ (例: 偵察スクリプトを保存する recon、sysadmin スクリプトを保存する sysadmin ro など):

$ cd ~/bin/bashscripts/
$ ls -la

Git ステータスの概要を確認する

作業ディレクトリのステータスを表示するには、加えた変更を表示するstatus コマンドを使用します。どのファイルが Git によって追跡されていないのか。段階的に行われた変更など。

$ git status 

Git ステージの変更とコミット

次に、-A スイッチを指定したadd コマンドを使用してすべての変更をステージングし、最初のコミットを実行します。 -a フラグは、変更されたファイルを自動的にステージングするようにコマンドに指示し、-m はコミット メッセージを指定するために使用されます。

$ git add -A
$ git commit -a -m "Initial Commit"

ローカルコミットをリモートGitリポジトリに公開する

プロジェクト チームのリーダーとして、プロジェクト構造を作成したので、 図に示すようにプッシュ コマンドを使用して変更を中央リポジトリに公開できます。

$ git push origin master

現時点では、ローカル git リポジトリはプロジェクトの中央リポジトリ (オリジン) と最新の状態になっているはずです。これを確認するには、status コマンド をもう一度実行します。

$ git status

また、リポジトリをローカル コンピュータに複製してプロジェクトの作業を開始するように同僚に通知することもできます。

新しい Git ブランチを作成する

ブランチを使用すると、コードベース (マスター ブランチ) に触れることなく、プロジェクトの機能に取り組んだり、問題を迅速に修正したりできます。新しいブランチを作成してそれに切り替えるには、ブランチ コマンドと チェックアウト コマンドをそれぞれ使用します。

$ git branch latest
$ git checkout latest

あるいは、-b フラグを指定したチェックアウト コマンドを使用して、新しいブランチを作成し、ワンステップでそのブランチに切り替えることもできます。

$ git checkout -b latest

たとえば、別のブランチに基づいて新しいブランチを作成することもできます。

$ git checkout -b latest master

どのブランチにいるかを確認するには、ブランチ コマンドを使用します (アスタリスク文字はアクティブなブランチを示します)。

$ git branch

新しいブランチを作成して切り替えた後、その下でいくつかの変更を加え、いくつかのコミットを実行します。

$ vim sysadmin/topprocs.sh
$ git status
$ git commit add  sysadmin/topprocs.sh
$ git commit -a -m 'modified topprocs.sh'

あるブランチから別のブランチに変更をマージする

ブランチ テストでの変更を master ブランチにマージするには、master ブランチに切り替えてマージを実行します。

$ git checkout master 
$ git merge test 

特定のブランチが不要になった場合は、-d スイッチを使用して削除できます。

$ git branch -d test

リモート中央リポジトリから変更をダウンロードする

チーム メンバーが変更を中央プロジェクト リポジトリにプッシュしたと仮定すると、プル コマンドを使用して、プロジェクトのローカル インスタンスに変更をダウンロードできます。

$ git pull origin
OR
$ git pull origin master	#if you have switched to another branch

Git リポジトリを検査して比較を実行する

この最後のセクションでは、リポジトリ内で発生したすべてのアクティビティを追跡し、プロジェクト履歴を表示できるようにするいくつかの便利な Git 機能について説明します。

最初の機能は Git ログで、コミット ログを表示します。

$ git log

もう 1 つの重要な機能は、さまざまなタイプのオブジェクト (コミット、タグ、ツリーなど) を表示するshow コマンド です。

$ git show

知っておく必要がある 3 番目の重要な機能は diff コマンドです。これは、ブランチ間の違いを比較または表示したり、作業ディレクトリとインデックスの間の変更を表示したり、ディスク上の 2 つのファイル間の変更を表示したりするために使用されます。

たとえば、マスターと最新のブランチの違いを表示するには、次のコマンドを実行します。

$ git diff master latest
まとめ

Git を使用すると、チームが同じファイルを使用して共同作業しながら、ファイルへの変更を長期にわたって記録し、後で特定のバージョンを呼び出すことができます。

このようにして、Git を使用してソース コード、構成ファイル、またはコンピューターに保存されているファイルを管理できます。詳細なドキュメントについては、Git オンライン ドキュメントを参照してください。