はじめに
Gitは、世界で最も人気のある分散型バージョン管理システムです。共同ソフトウェア開発プロジェクトをコーディングして作業する場合は、Gitをよく理解することが不可欠です。
この記事では、Gitの仕組みとその重要な機能の使用方法を学びます。
前提条件
- Gitのインストールと構成（WindowsにGitをインストールする方法、MacにGitをインストールする方法、UbuntuにGitをインストールする方法、CentOS 7にGitをインストールする方法、CentOS 8にGitをインストールする方法を参照）
Gitはどのように機能しますか？
Gitを使用すると、ユーザーは簡単なコマンドを使用してコードの変更を追跡し、プロジェクトを管理できます。
Gitの心臓部はリポジトリです プロジェクトを含むために使用されます。リポジトリは、ローカルまたはGitHubなどのWebサイトに保存できます。 Gitを使用すると、ユーザーは複数の異なるリポジトリを保存し、それぞれを個別に追跡できます。
開発全体を通じて、プロジェクトにはコミットと呼ばれるいくつかの保存ポイントがあります。 。コミット履歴には、すべてのコミット、つまり開発中にプロジェクトに実装された変更が含まれます。コミットを使用すると、コードをコミット履歴内の任意のコミットにロールバックまたは早送りできます。
GitはSHA-1ハッシュを使用します コミットを参照します。それぞれの一意のハッシュは、リポジトリ内の特定のコミットを指します。ハッシュを使用して、Gitはツリーのような構造を作成し、データを簡単に保存および取得します。
各Gitプロジェクトのファイルはいくつかの段階を経ます：
- 作業ディレクトリ 。変更されたファイルですが、追跡されておらず、まだコミットの準備ができていません。
- ステージングディレクトリ 。変更されたファイルをステージング環境に追加することは、それらがコミットの準備ができていることを意味します。
- コミット済み 。コミット履歴に保存されたステージング領域からのファイルのスナップショット。
次の図は、基本的なGitワークフローを示しています。
次のセクションでは、Gitの機能について詳しく説明します。
ステージング
特定のファイルに加えた変更をGitで追跡する場合は、そのファイルをステージング領域に追加する必要があります。 Gitはファイルを変更すると認識しますが、ステージングしない限り追跡しません 。ステージング領域はセキュリティの層を表しており、変更をコミットする前に確認できます。
ステージング領域にいることは、ファイルが後でコミットされる、つまりマスターブランチに実装されるための前提条件です。次のコマンドを実行して、Gitが追跡するファイルを確認できます：
git statusステージング領域にファイルを追加するには、次の構文を使用します。
git add [filename]
[filename]を置き換えます ファイルの実際の名前を使用した構文。
例：
気が変わった場合は、ステージング領域からファイルを削除できます。ファイルのステージングを解除するには、次の構文を使用します。
git rm --cached [filename]例：
コミットを行う
コミットは、作業の保存ポイント、特定の時点でのコードのスナップショットを表します。ステージング領域にファイルを追加すると、ファイルをコミットする準備が整います。
コミットする準備ができているファイルがあるかどうかを確認するには、次のコマンドを実行します。
git status例：
ここでは、3つのファイルをコミットする準備ができていることがわかります。それらをコミットするには、次の構文を使用します。
git commit -m "Notes about the commit"
各コミットには、 -mの後に指定された説明が必要です。 フラグ。後でコミットの内容を知るのに役立ちます。
例：
出力にはコミットが含まれ、何が変更されたかが示されます。
コミット履歴を確認できます 実行することにより：
git log
出力には、行ったすべてのコミット、コミットを行った人、日付、およびコミットノートのログが表示されます。 --onelineを追加する フラグは、コミット履歴を1行にまとめたものです。フラグを省略すると、詳細なコミット履歴が表示されます。
元に戻す
プロジェクトの開発中にミスをした場合、または何らかの理由でコミットを元に戻したい場合は、 git revert そうすることができます。
git revert コマンドは特定のコミットを元に戻します。つまり、マスターブランチから変更を削除するために行ったコミットを元に戻します。
構文は次のとおりです。
git revert [commit_ID]
git logを実行して、コミットIDを見つけます 。 7文字のコードはコミットIDです。
次の例は、 git revertを示しています コマンド：
git reset コマンド永続的 開発の特定のポイントに戻ります。その時点以降に追加されたすべてのファイルと変更は、それらを再度追加する場合はステージングされません。
警告： git resetを使用します このアクションは元に戻せないため、コードの一部を元に戻す/削除することが完全に確実な場合にのみ。
構文は次のとおりです。
git reset [commit_ID]
--hardを指定する フラグはステージングされていないファイルを削除し、それらを戻すことを不可能にします。
フォーク
フォークは、既存のリポジトリの完全なコピーです。 これにより、元のプロジェクトに影響を与えることなく、変更を加えて実験することができます。フォークは、誰かが既存のプロジェクトへの変更を提案する方法です。または、コードがオープンソースである場合は、独自のプロジェクトの開始点になる可能性があります。
プロジェクトの変更またはバグ修正を提案する場合は、リポジトリをフォークして修正を行い、プロジェクト所有者にプルリクエストを行うことができます。
次の図は、フォークがどのように機能するかを示しています。
リポジトリをフォークするには、以下の手順に従います。
1.GitHubアカウントにサインインします。
2. GitHubのリポジトリページにアクセスし、フォークをクリックします オプション。
3.フォークプロセスが完了するのを待ちます。完了すると、GitHubアカウントにリポジトリのコピーが作成されます。
4.次のステップは、リポジトリURLを取得することです。 コードから セクションを作成し、リポジトリをローカルマシンに複製します。
5.次の構文を使用してリポジトリのクローンを作成します。
git clone [repository URL]
[repository URL]の代わりにURLを入力してください 構文。
例：
この例では、 springmvc-raml-pluginのフォークを作成しました。 リポジトリになりました。変更を実装したり、既存のプラグインの上に新しいプラグインの構築を開始したりできます。
分岐
分岐はGitの機能であり、開発者は元のコードのコピーを操作してバグを修正したり、新しい機能を開発したりできます。ブランチで作業することにより、開発者はマスターブランチに影響を与えません 変更を実装するまで。
マスターブランチは通常、安定バージョンを表します リリースまたは公開されているコードのそのため、不安定な場合は、マスターブランチに新しい機能や新しいコードを追加しないようにする必要があります。
分岐により、分離された環境が作成されます 新しい機能を試してみてください。気に入った場合は、マスターブランチにマージできます。何か問題が発生した場合は、ブランチを削除しても、マスターブランチは変更されません。
分岐により、共同プログラミングが容易になり、全員がコードの自分の部分で同時に作業できるようになります。
次の図は、Gitでの分岐を視覚的に表したものです。
Gitで新しいブランチを作成するための構文は次のとおりです。
git branch [branch-name]
[branch-name]の代わりにブランチの名前を入力してください 構文。例：
この例では、 feature-1という名前の新しいブランチを作成しました。 。
マージと競合
git merge このコマンドを使用すると、別のブランチで新機能やバグ修正に取り組んでいる開発者は、終了後に変更をメインブランチにマージできます。変更をマージするということは、それらをマスターブランチに実装することを意味します。
開発者は、 git mergeを使用して変更を入力できます プロジェクトに取り組んでいるすべての人に自分の仕事を送る必要はありません。
既存のブランチを表示するには、次を実行します：
git branch -a
このチュートリアルでは、 feature-1という名前の別のブランチを作成しました 。 機能-1をマージするには マスターとの分岐 ブランチの場合は、以下の手順に従ってください：
1.マスターブランチに切り替えます。 git merge コマンドを実行するには、merge-receiveingブランチにいる必要があります。次のコマンドを実行して、マスターブランチに切り替えます。
git checkout master2.マスターブランチに切り替えた後、次の構文を使用して変更をマージします。
git merge [branch-name]
[branch-name]の代わりにブランチの名前を入力してください 構文。
例：
Gitは、変更内容をマスターブランチに自動的に入力し、プロジェクトで作業しているすべての人に表示されます。
ただし、マージに遭遇する場合があります 競合 。
たとえば、別のブランチで作業しているときに誰かがマスターブランチを編集することにした場合、競合が発生します。このタイプの競合は、変更をマスターブランチとマージするために発生します。マスターブランチは、コードコピーとは異なります。
詳細なガイドでは、Gitでのマージの競合を解決するためのいくつかの異なる方法を提供しています。
変更の取得/プル
git fetch およびgit pull コマンドは両方とも、リモートリポジトリから変更を取得するために使用されます。
違いは、 git fetch リモートリポジトリからメタデータを取得するだけで、ローカルリポジトリには何も転送しません。前回のプル以降に利用可能な変更があるかどうかのみを通知します。
次の例では、 git fetch リモートリポジトリにいくつかの変更があるが、ローカルリポジトリには何も変更されていないことを通知します：
一方、 git pull また、リモートリポジトリ内の新しい変更をチェックし、それらの変更をローカルリポジトリにもたらします。
したがって、 git pull 1つのコマンドで2つのことを行います-git fetch 、および git merge 。このコマンドは、現在のブランチに加えられた変更をダウンロードし、ローカルリポジトリのコードを更新します。
例：
この出力では、これが早送りマージタイプであり、Gitが1つのファイルをローカルリポジトリ（ README.md ）にプルしたことがわかります。 。
変更のプッシュ
git push コマンドはgit pullの反対を行います 、変更を共有してリモートリポジトリに公開できるようにします。
ローカルで変更を加えてリモートリポジトリにプッシュする場合は、次のコマンドを実行します。
git push例：
リモートに存在しない新しいブランチをローカルで作成した場合、変更をプッシュしようとすると、コマンドはエラーを返します。
Gitは出力でソリューションを提供します。出力で指定されたコマンドを実行して、ブランチをアップストリームにプッシュします：
リベース
ブランチを作成すると、Gitは既存のコードのコピーを作成して、さらに開発できるようにします。 新しい変更を組み込む必要がある場合があります マスターブランチから 一般的な開発についていくために。
リベースには、マスターブランチから機能ブランチへの新しい変更の実装が含まれます。つまり、Gitはマスターブランチからの新しい変更を再生し、機能ブランチの先端にコミットを作成します。
機能ブランチをリベースするには、次の手順に従います。
1. git checkoutを使用して機能ブランチに移動します 。構文は次のとおりです。
git checkout [branch-name]2.次のコマンドを実行して、ブランチをリベースします。
git rebase master次の図は、リベース機能がどのように機能するかを示しています。
