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

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

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

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

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

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

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

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 “[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://admin@remote_server_ip:/projects/scripts/bashscripts

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

git clone ssh://admin@remote_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 代替手段 10 選

まとめ

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

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