【Git】Gitの原理と使い方

一般的なLinuxツールでのgitの簡単な使い方を学習しました。次に、 git の使い方をさらに学習します。

バージョン コントローラー: ファイルのいくつかの異なるバージョンの管理を容易にするために、バージョン コントローラーがあります。

いわゆるバージョン コントローラーは、ファイルの履歴とその開発プロセスを理解できるようにするシステムです。平たく言えば、プロジェクトのすべての変更とバージョンの反復を記録できる管理システムであり、複数の人々による共同作業も容易になります。現在、最も主流のバージョン コントローラーはGitです。

Linuxでは、プラットフォームがcentosの場合、 git のインストールは非常に簡単で、centos7.6 を例に取ると、git :を実行してインストールされたバージョンをsudo yum -y install git確認するだけです。git --version

プラットフォームがubuntuの場合、gitをインストールする手順は次のとおりです: sudo apt-get install git -y; gitによってインストールされたバージョンを確認しますgit --version。

注: gitツールの使用方法は、centosプラットフォームでもubuntuプラットフォームでも同じです。

1. Git ローカル ウェアハウス

1. ローカル倉庫の創設

ウェアハウスはバージョン管理のためのファイル ディレクトリです。ファイルのバージョン管理を実行したい場合は、まずウェアハウスを作成する必要があります。

Gitローカル ウェアハウスを作成するための対応するコマンドはですgit init。コマンドはファイル ディレクトリで実行する必要があることに注意してください。たとえば、次のようになります。

上記のように、ローカル ウェアハウスはディレクトリ内に構築されます。ls -laこのディレクトリ内のウェアハウスを表示するには、次のコマンドを使用します。

現在のディレクトリに追加の.git隠しファイルがあることがわかりました。.gitディレクトリは、ウェアハウスの追跡と管理のためにGitによって使用されます。このディレクトリ内のファイルを手動で変更しないでください。変更しないと、変更が台無しになります。 Gitリポジトリが破壊されました。

2.Gitの構成

Gitをインストールするときに最初に行うことは、ユーザー名と電子メールアドレスを設定することですが、これは非常に重要です。

一般的なLinuxツールにも導入されており、設定手順は次のとおりです。

		git config [--global] user.name "Your Name" 
		git config [--global] user.email "[email protected]"

その中で、グローバルはオプションです。このオプションを使用すると、このマシン上のすべてのGitリポジトリがこの構成を使用することになります。また、このオプションを追加することをお勧めします。異なるウェアハウスで異なる名前や電子メールを使用する場合は、 --globalオプションは必要ありませんが、コマンドを実行するときはウェアハウスにいる必要があることに注意してください。

構成を変更したい場合は、上記のコマンドを直接実行すると、新しい構成が以前の構成を上書きします。

Gitを構成した後、現在の構成を表示できますgit config -l。

構成を削除する場合、構成を削除する手順は次のとおりです。

		git config [--global] --unset user.name
		git config [--global] --unset user.email

Gitを構成するときに–globalオプションを追加する場合は、構成を削除するときにも–globalオプションを追加する必要があることに注意してください。

3. ワークスペース、ステージングエリア、バージョンライブラリ

まず、ワークスペース、ステージング領域、バージョン ライブラリの概念を理解しましょう。

• ワークスペース: コードまたはファイルを書き込むコンピューター上のディレクトリです。
• 一時記憶領域：英語ではステージまたはインデックスと呼ばれます。通常、.gitディレクトリの下のインデックスファイル (.git/index)に保存されますが、一時的な保存領域をインデックス (インデックス) と呼ぶこともあります。
• バージョン ライブラリ: ネーム ウェアハウス、英語名リポジトリ。ワークスペースには隠しディレクトリ .git があります。これはワークスペースとは見なされませんが、Gitリポジトリと見なされます。このリポジトリ内のすべてのファイルはGitで管理できます。Gitは各ファイルの変更と削除を追跡できるため、いつでも履歴を追跡したり、将来のある時点で「復元」したりできます。

このうち、３者の関係は以下の通りです。

• 図の左側はワークスペース、右側はバージョン ライブラリです。Gitのリポジトリには多くのものが保存されていますが、その中で最も重要なものはステージング領域です。
• Gitリポジトリを作成するとき、Git は自動的に一意のマスターブランチと、HEADと呼ばれるマスターへのポインターを作成します。(ブランチとHEADの概念については後ほど紹介します)
• ワークスペースで変更 (または追加) されたファイルに対してコマンドが実行されるとgit add、ステージング領域のディレクトリ ツリーのファイル インデックスが更新されます。
• コミット操作が実行されるとgit commit、マスターブランチは対応する更新を行います。これは、ステージング領域のディレクトリ ツリーが実際にリポジトリに書き込まれると単純に理解できます。

上記の説明から、ディレクトリへのファイルの作成または貼り付けは、ウェアハウスへのファイルの追加とは言えず、ワークスペースへのファイルの追加のみであることがわかります。管理のためにファイルをウェアハウスに追加するには、git addおよびコマンドを使用する必要があります。git commit

4. ファイルを追加する

.gitを含むディレクトリに新しいテストファイルを作成します。git addコマンドを使用して、ファイルをステージング領域に追加できます。その使用法は次のとおりです。

• 1 つ以上のファイルをステージング領域に追加します。git add [file1] [file2] ...
• 指定したディレクトリを、サブディレクトリも含めてステージング領域に追加します。git add [dir]
• 現在のディレクトリ内のすべてのファイルの変更を一時記憶領域に追加します。git add .

次に、git commitコマンドを使用して、ステージング領域の内容をローカル ウェアハウスに追加します。その使用法は次のとおりです。

• ステージング領域のすべてのコンテンツをローカルのウェアハウスに送信します。git commit -m "message"
• ステージング領域内の指定されたファイルをウェアハウス領域に送信します。git commit [file1] [file2] ... -m "message"

git commitの後の-mオプションに注意してください。このオプションの後には、この送信を説明するメッセージが続き、ユーザーがこれを完了する必要があります。コンテンツのこの部分は省略してはならず、十分に説明する必要があります。これは、提出の詳細。

例えば：

git commitコマンドが正常に実行されると、ファイルが変更され (つまり、新しく追加されたテストファイル)、コンテンツ行が挿入されたことがわかります(テストにはコンテンツ行があります)。

コマンドを使用して、送信履歴の記録を表示できますgit log。例:

このコマンドは、コミット ログを最新のものから最も古いものまで表示し、コミット時のログ メッセージを確認できます。出力情報が多すぎて見苦しいと思われる場合は、--pretty=onelineパラメーターを追加できます。

7aad62bad5848c12ef8818df7e3c9cfb9c01fa17に似た大きな文字列は、各送信のコミット ID (バージョン番号)であることに注意してください。Gitのコミット ID は 1、2、3... と増加する数字ではなく、SHA1 で計算された A 16 進数で表される非常に大きな数。

5. .git ファイルを表示する

コマンドを使用してtree .git/、独自の.git/のディレクトリ構造を表示できますが、ディレクトリ構造が長すぎるため、重要な部分を抜粋して説明します。

• Index は一時記憶域であり、追加後のコンテンツはここに追加されます。

• HEAD はmasterブランチへのデフォルトのポインタです

デフォルトのマスターブランチは実際には次のとおりです。

出力された7aad62bad5848c12ef8818df7e3c9cfb9c01fa17は、現在保存されている最新のコミット IDです。

• オブジェクトはGitのオブジェクト ライブラリであり、作成されたさまざまなリポジトリ オブジェクトとコンテンツが含まれています。git addコマンドが実行されると、一時記憶領域のディレクトリ ツリーが更新され、同時にワークスペースで変更 (または追加) されたファイルの内容が、オブジェクト ライブラリ内の新しいオブジェクトに書き込まれます。「 .git/objects」ディレクトリで、これらのオブジェクトの使用法を見てみましょう。

オブジェクトを検索する場合、コミット ID を2 つの部分に分割する必要があり、最初の 2 桁がフォルダー名、最後の 38 桁がファイル名になります。このファイルを見つけた後、通常、中身を直接見ることはできません。このタイプのファイルは SHA (セキュア ハッシュ アルゴリズム) によって暗号化されたファイルですが、次のコマンドを使用してリポジトリ オブジェクトの内容を表示できますgit cat-file -p + commit id。

上記は私たちの最新の提出物です。

要約すると、ローカルgitリポジトリには、いくつかの特別なファイルまたはディレクトリがあります。

• Index:ステージング領域の場合、内容はgit add後に更新されます。
• HEAD:デフォルトでマスターブランチを指すポインタ。
• refs/heads/master:このファイルには、現在のmasterブランチの最新のコミット IDが保存されます。
• オブジェクト:作成されたさまざまなリポジトリ オブジェクトとコンテンツが含まれます。単純に、 gitによって維持されるすべての変更が含まれると理解できます。

6. ファイルを変更する

Git はファイルではなく変更を追跡および管理します。修正とは何ですか? たとえば、新しい行を追加した場合も変更、行を削除した場合も変更、一部の文字を変更した場合も変更、一部の文字を削除して追加した場合も変更になります。一部の文字を削除した場合も修正であり、新しいファイルを作成することも修正と見なされます。テストファイルに変更を加えてみましょう。

現時点では、ウェアハウスでのテストはワークスペースでのテストとは異なります。現在のウェアハウスのステータスを確認するにはどうすればよいですか? git statusこのコマンドは、ファイルが前回の送信以降に再度変更されたかどうかを確認するために使用されます。次に例を示します。

上記の結果は、テストは変更されましたが、追加と送信が完了していないことを示しています。

まずファイルを追加してから、ウェアハウスのステータスを確認します。

上の図に示すように、テストは一時保存領域に追加されていますが、送信はまだ完了していないので、送信することができます。

最後に、git diff [file]このコマンドを使用して、ステージング領域とワークスペース ファイルの違いを表示できます。git diff HEAD -- [file]また、このコマンドを使用して、リポジトリとワークスペース ファイルの違いを表示することもできます。

たとえば、テストを再度変更し、一時記憶域と変更後のワークスペース ファイルの違いを比較します。

上記の結果にあるように、最後のhello world!!の前に「-」の記号があり、この行が削減されたことを意味しており、結果は確かにこのようになります。

7. バージョンのロールバック

Git はファイルの履歴バージョンを管理できます。これはバージョン コントローラーの重要な機能でもあります。ある日、以前の作業に大きな問題があることが判明し、特定の過去のバージョンからやり直す必要がある場合、バージョンのロールバック機能が必要になります。

実行git resetコマンドはバージョンをロールバックするために使用され、特定の送信までロールバックするバージョンを指定できます。説明すると、「ロールバック」の本質は、リポジトリ内のコンテンツをロールバックすることです。ワークスペースまたはステージング領域のどちらをロールバックするかは、コマンド パラメータによって決まります。

	git reset 命令语法格式为： git reset [--soft | --mixed | --hard] [HEAD]
	
	--mixed 为默认选项，使⽤时可以不⽤带该参数。该参数将暂存区的内容退回为指定提交版本内容，⼯作区⽂件保持不变。
	--soft 参数对于⼯作区和暂存区的内容都不变，只是将版本库回退到某个指定版本。
	--hard 参数将暂存区与⼯作区都退回到指定版本。切记⼯作区有未提交的代码时不要⽤这个命令，因为⼯作区会回滚，你没有提交的代码就再也找不回了，所以使⽤该参数前⼀定要慎重。
	
	HEAD 说明：
	◦ 可直接写成 commit id，表⽰指定退回的版本
	◦ HEAD 表⽰当前版本
	◦ HEAD^ 上⼀个版本
	◦ HEAD^^ 上上⼀个版本
	◦ ...以此类推

たとえば、テストファイルの内容を次のように書き直します。

次に、ここにコンテンツを追加して送信します。

上で述べたように、リポジトリの最新の送信は「テスト リセット」です。この時点で、それをロールバックし、ステージング領域とリポジトリの内容を以前のバージョンにロールバックします。

git reset + commit id上に示すように、ウェアハウスは操作を追加して送信する必要があることを通知し、前のバージョンにロールバックしたことを示します。さらに、上記のバージョンのロールバック操作では、指定されたバージョンへのロールバックも使用できます。次のように、最新バージョンから元のコミット テストバージョンに直接ロールバックします。

現在の最新バージョン:

元のバージョンにロールバックするには、元のコミット テストのコミット IDをコピーし、次を使用します。

現在、ステージング領域とリポジトリは元のコミット テストバージョンに戻りましたが、オプションを提供しなかったため、ワークスペースは戻っていません。デフォルトのオプションでは、ステージング領域とリポジトリの内容--mixedのみがロールバックされます。ワークスペースの内容は、はまだ次のとおりです。

しかし、後悔してテスト リセットのバージョンに戻りたい場合はどうすればよいでしょうか? 引き続きgit replaceコマンドを使用してバージョンをロールバックできますが、ロールバックされたバージョンを指定するにはテスト リセットのコミット IDを取得する必要があります。

しかし、 git log が最新のコミット ID を出力できないことがわかりました。運が良ければ、ターミナルから以前のレコードを見つけることができます。運が悪いと、コミット ID は失われています。

ただし、Git にgit reflogはこの状況を解決するコマンドも用意されており、このコマンドは次のようにすべてのローカル コマンドを記録するために使用されます。

ここのコミット ID には前の部分しかないことがわかりました。はい、 Gitバージョンをロールバックするときは、ターゲット バージョンを表すためにコミット IDの一部を使用することもできます。テスト リセットバージョンが見つかったら、ロールバックします。

この時点ではテストリセット版に戻っています。

Gitには現在のブランチ (ここではマスター) を指す内部HEADポインターがあり、refs/heads/masterファイルには現在のマスターブランチの最新のコミット IDが格納されるため、 Gitのバージョンのロールバックは非常に高速です。バージョンをロールバックすると、Git は特定のバージョンのみをrefs/heads/masterに保存します。これは次のように単純に理解できます。

8. 変更を元に戻す

ワークスペースで長い間コードを書いていて、書けば書くほど続けられなくなって、自分が書いたものは本当に良くないと感じて、元に戻したいと思うことがあります。以前のバージョンに戻す; もちろん、ワークスペースに追加されたコードを直接削除することもできます。コードですが、これは非常に非効率なので、gitコマンドを使用して完了できます。

git checkout -- [file]このコマンドを使用すると、ワークスペース内のファイルを最後の追加またはコミットの状態に戻すことができます。なお、git checkout -- [file]コマンド中の「」は--非常に重要です。省略しないように注意してください。省略すると別の意味になってしまいます。後で紹介します。

以下では、いくつかの状況について説明します。

• (1) ワークスペース内のコードについては、まだ追加されていません

テストファイルには次の文が含まれています。

次に、新しいコンテンツをテストファイルに追加します。

以下では、コマンドを直接使用して、ファイルの内容を最後の追加git checkout -- test前のバージョンに復元できます。

• (2) すでに追加されているがコミットされていない

git reset学習したロールバック コマンドを思い出してみましょう。このコマンド--mixedでパラメータを使用すると、ステージング領域の内容を指定されたバージョンの内容にロールバックできますが、ワークスペース ファイルは変更されません。次に、ステージング領域の内容をロールバックできます。例:

追加後、一時記憶域の内容をロールバックし、git reset HEAD test 次のコマンドを実行します。

一時記憶域の内容はロールバックされていますが、ワークスペースの内容はロールバックされていないことがわかりました。この時点では、状況 1 に戻っているため、次を実行しますgit checkout -- test。

• (3) 追加済み、コミット済み

以前のバージョンにロールバックできますgit reset --hard HEAD^が、これは条件付きです。つまり、ローカル バージョンのライブラリをリモート ウェアハウスにプッシュしていないことです。

以下が追加され、コミットされました。

ワークスペース、ステージング領域、およびバージョン ライブラリのすべてのコンテンツを以前のバージョンに戻します。

9. ファイルを削除する

Gitでは削除も変更操作ですが、次のようにfile3ファイルを削除したい場合はどうすればよいでしょうか。

直接実行するとrm file3、この時点でワークスペースとリポジトリに不整合が生じます。ファイルを削除するには、現在、ワークスペース内のファイルの削除に加えて、リポジトリ内のファイルもクリアする必要があります。

一般的に、これに関しては 2 つの可能性があります。

• リポジトリからファイルを削除してもよろしいですか?
• 間違って間違ったものを削除してしまいました

2 番目のケースでは、削除が誤って行われたことは明らかであり、それを復元するにはgitを使用する必要があります。これは非常に簡単です。学習したばかりです (削除も変更です)。git checkout -- file3それだけです。

最初のケースでは、明らかに削除が完了していないため、ワークスペース内のファイルを削除しただけです。git rmこの時点で、ステージング領域と作業領域からファイルを削除し、commit する必要があります。

2.支店管理

1. ブランチを理解する

ブランチングは SF 映画の並行世界のようなもので、中国語を学習しているときは、別の並行世界で数学を学習していることになります。2 つの並行世界が互いに干渉しなければ、今のあなたには何の影響も与えません。しかし、ある時点で 2 つの並行世界が融合し、その結果、あなたは中国語と数学の両方を学ぶことができました。

バージョンのロールバックでは、 Git が送信ごとにそれらをタイムラインに文字列化し、このタイムラインはブランチとして理解できることはすでにわかっています。現時点ではタイムラインは 1 つだけですが、Gitではこのブランチをメイン ブランチ、つまりマスターブランチと呼びます。

HEAD をもう一度理解しましょう。厳密に言うと、 HEAD はコミットを指しているのではなく、マスターを指しています。マスターはコミットを指しているので、HEAD は現在のブランチを指しています。

送信するたびに、masterブランチは 1 ステップ進みます。そのため、送信を続けると、masterブランチの行はどんどん長くなり、HEAD は、常にmasterブランチを指している限り、現在のブランチを指すことができます。 。

現在のリポジトリを確認すると、現在のmasterブランチが指す最新の送信のコミット IDも確認できます。

2. ブランチを作成する

Git は他のブランチの表示または作成をサポートしています。対応するコマンドは次のとおりです: git branch; ここで最初のブランチdevを作成します、対応するコマンドは次のとおりです: git branch dev; それを作成した後、ブランチを見てみましょう:

新しいブランチを作成すると、Git はdevという新しいブランチを作成します。masterの前の * は、現在HEADが指しているブランチがmasterブランチであることを示します。さらに、新しいdevブランチはディレクトリ構造を通じて検出できます。

現在、 devとmaster が同じ変更を指していることがわかります。現在の状況は次のとおりです。

3. ブランチを切り替える

開発のためにdevブランチに切り替えるにはどうすればよいですか? 次のようにコマンドを使用してgit checkout切り替えを完了します。

HEAD がdevを指していることがわかりました。これは、 devに正常に切り替えられたことを意味します。

次に、devブランチのテストファイルに変更を加えて送信します。

上記のように、ファイルにコンテンツの行を追加し、以下を追加して送信します。

次に、 masterブランチに戻ってテストファイルを表示します。

この時点で、masterブランチでのテストには新しい行のコンテンツが含まれていないことがわかりました。dev ブランチと master ブランチを調べたところ、この2つが指すコミット ID が異なることがわかりました。

devブランチでサブミットしており、この時点ではmasterブランチのサブミットポイントは変更されていないため、この時点のステータスは次のようになります。

masterブランチに切り替えると、HEAD はmasterを指すため、コミットは表示されません。

4. ブランチをマージする

master ブランチの最新のコミットを確認するには、 devブランチをmasterブランチにマージする必要があります。このとき、次のようにコマンドを使用してブランチをマージする必要があります。git merge

現時点でdevブランチにいる場合は、まずmasterブランチに切り替えてからマージする必要があります。

ブランチをマージします。

git mergeこのコマンドは、指定されたブランチを現在のブランチにマージするために使用されます。マージ後、マスターはdevブランチによって送信されたコンテンツを確認できるようになります。この時のステータスは以下の通りです。

このときのマージモードは「早送りモード」を表すFast-forwardモードです。つまり、マスターがdevの現在の送信を直接指すため、マージ速度は非常に高速です。もちろん、すべてのマージをFast-forwardできるわけではありません。他のマージ モードについては後で紹介します。

5. ブランチの削除

マージが完了すると、devブランチは役に立たなくなるため、devブランチを削除できます。現在、特定のブランチの下にいる場合、現在のブランチを削除することはできません。そのブランチは、他のブランチの下にある場合に削除できます。分岐命令はgit branch -d + 分支名称次のとおりです。

ブランチの作成、マージ、削除は非常に高速であるため、Git では、ブランチを使用して特定のタスクを完了し、マージ後にブランチを削除することをお勧めします。これには、マスターブランチで直接作業する場合と同じ効果がありますが、プロセスはより安全です。 。

6. マージ競合

実際にブランチをマージする場合、マージしたくてもマージが成功せず、場合によってはコードの競合が発生することがあります。

まず、新しいブランチdev1を作成し、ターゲット ブランチに切り替えます。git checkout -b dev1次のように、 を使用して 1 ステップで作成と切り替えを完了できます。

次のように、 dev1ブランチのテストファイルを変更し、送信を追加します。

この時点で、 masterブランチに戻り、テストの内容が変更されていないことを確認します。これは通常の現象です。これについては以前に説明しました。

ここで、masterブランチ上のテストファイルを変更し、コミットを追加します。

これで、masterブランチとdev1ブランチにそれぞれ新しいサブミットが追加され、以下のようになりました。

この場合、Git はそれぞれの変更をマージしようとすることしかできませんが、このマージにより、以下に示すように競合が発生する可能性があります。

上記のメッセージは、マージに競合があることを示しています。この時点でのウェアハウスのステータスを確認してみましょう。

テストファイルで競合を検出した後、ファイルのコンテンツを直接表示できます。以下に示すように、Git はそれを使用して、異なるブランチ内の競合するコンテンツをマークすることに注意してください。<<<<<<<，=======，>>>>>>>

現時点では、競合するコードを手動で調整し、内容をmasterブランチに保持するか、dev1ブランチに保持して、修正した結果を再度送信する必要があります。次のように、忘れずに再送信することが重要です。

この時点で競合は解決され、ステータスは次のようになります。

以下に示すように、コマンド: などのパラメーターを指定してgit logを使用すると、ブランチのマージ ステータスを確認することもできます。git log --graph --pretty=oneline --abbrev-commit

この時点で、dev1ブランチを削除できます。

7. 支店経営戦略

通常、ブランチをマージするとき、Git は可能であれば高速転送モードを使用します。上でこのモードを簡単に紹介しましたが、これは dev ブランチを masterブランチに直接マージすることです。この高速転送モードでは、ブランチを削除した後、ブランチ履歴を表示しますこれを行うとブランチ情報が失われ、最新の送信がマージによって送信されたのか、正常に送信されたのかがわかりません。

ただし、マージ競合セクションでは、競合を解決することで新しい送信が行われ、最終的に取得されるステータスが次のようになることもわかります。

これは早送りモードではなく、分岐履歴から分岐情報が見られるという利点があります。たとえば、マージ競合部分で作成されたdevブランチを削除しましたが、 master が実際には他のブランチからマージされたことがまだわかります。

また、Git では、高速転送モードを強制的に無効にすることをお勧めします。そうすれば、マージ中に新しいコミットが生成され、ブランチ履歴からブランチ情報を確認できるようになります。

次に、--no-ffこの方法を使用して、マージの早送りモードgit mergeを無効にする練習をします。まず、新しいブランチdevを作成し、新しいブランチに切り替えて、新しいブランチ上のファイルを変更してコミットを追加します。

次に、 masterブランチに戻り、マージを開始します。

この時点で実行するコマンドは次のとおりです: ;パラメータにgit merge --no-ff -m "test git merge --no-ff" dev注目してください。これは、早送りモードを無効にすることを意味します。早送りモードを無効にすると、マージ後に新しいコミットが作成されるので、パラメータを追加して説明を記述します。--no-ff-m

この時点で、合併の歴史を確認できます。

ご覧のとおり、早送りモードを使用しない場合、マージは次のようになります。

そのため、ブランチをマージする場合は--no-ffパラメータを追加することで通常モードでマージすることができますが、マージされた履歴にはブランチがあるのでマージが行われたことがわかりますが、早送りマージではマージが行われたことがわかりません。

8. バグブランチ

現在devブランチで開発を行っているとしますが、開発の途中で突然、解決する必要のあるバグがmasterブランチに見つかったとします。Gitでは、各バグを修正するには、新しい一時ブランチを作成し、修正後にブランチをマージし、一時ブランチを削除します。

現在のメイン ブランチのテストが次のようになっていると仮定します。

これからdevブランチで開発を進めます。

突然、 masterブランチのテストに書かれているhello, world!が 1 つ少ない、つまりバグが発生していることがわかり、この時点でmasterブランチに切り替えてテストの内容を表示します。

devブランチにテストを追加して送信しない場合、テストファイルを変更すると、 masterブランチのテストファイルに影響を与えることがわかります。現時点では、devブランチでテストの変更された内容を表示する必要はありません。 masterブランチ上のtestのブランチ。したがって、Git は現在のワークスペース情報を保存するコマンドを提供しており、保存されたコンテンツは将来のある時点で復元できます。次のように、このコマンドをdevブランチで使用します。git stash

Viewを使用してgit status、ワークスペースがクリーンであることを確認します (Git によって管理されていないファイルがない限り)。これにより、バグを修正するためのブランチを安全に作成できます。

開発ワークスペースを保存した後、マスターブランチに基づいてバグを修正する必要があるため、次のようにマスターブランチに切り替えてバグを修正するための一時ブランチを作成する必要があります。

この時点で、 fix_bugブランチを作成して入力し、バグの修正を開始しました。hello, world! の記述が 1 つ減ったので、追加して送信しました。

次に、マージのためにmasterブランチに戻り、最後にfix_bugブランチを削除します。

この時点でバグ修正作業は完了したため、引き続き開発ブランチに戻って開発を続けます。devブランチに戻ります。

この時点では、ワークスペースはまだクリーンです。開発したコードを復元し、git stash listストレージ領域を表示するために使用する必要があります。

作業サイトはまだ存在します。Gitは隠しコンテンツをどこかに保存していますが、復元する必要があります。サイトを復元するにはどうすればよいですか? git stash pop次のように、コマンドを使用してリカバリ中にスタッシュを削除できます。

上記の通り、開発中に開発したコードは取得できており、現時点では開発を続行できますが、バグ修正の内容はdev上に表示されません。このときの状態図は次のとおりです。

私たちの最終的な目標は、 master にdevブランチをマージさせることです。通常の状況では、 masterブランチに戻って直接マージできますが、これには実際には一定のリスクがあります。これは、ブランチをマージするときに競合が発生する可能性があり、コードの競合を手動で解決する必要があるためです (マスター上で解決されます)。競合の問題を一度に正しく解決できるかどうかは保証できません。解決プロセス中に手動エラーが避けられず、その結果、間違ったコードがマスターにマージされます。devブランチをmasterブランチに直接マージした場合、この時点のステータスは次のようになります。

現時点では、マスターをdevブランチにマージし、マスターにdev をマージさせるという別の解決策があります。この目的は、マスターに影響を与えることなく、競合を解決してdevブランチでテストできるようにすることです。この時のステータスは以下の通りです。

次に、コードのデモを開始します。最初にdev上のmasterをマージします。

競合を見つけて解決します。

次に、以下を追加して送信します。

マスターに戻り、dev をマージします。

この時点でマージは完了し、devブランチを削除できます。

9. 一時ブランチの強制削除

日々の開発中に開発ブランチでコードを開発していて、それが突然停止された場合は、ブランチを削除する必要があります。新しいブランチで開発されたコードは次のとおりです。

そして、以下を追加して送信します。

masterブランチに切り替えて通常の方法で削除すると、次の問題が発生します。

次のコマンドを使用できます:git branch -D temp強制削除:

3. 遠隔倉庫

ウェアハウスの作成についてはすでにCommon Linux Tools (パート 2)で紹介したため、ここでは紹介しません。

1. リモート リポジトリのクローンを作成します。

リモート ウェアハウスをローカルにクローン/ダウンロードするには、git cloneコマンドを使用し、その後にリモート ウェアハウスへのリンクを使用する必要があります。リモート ウェアハウスへのリンクはウェアハウスにあります: [クローン/ダウンロード] を選択してリモート ウェアハウスを取得します倉庫リンク:

SSHプロトコルとHTTPSプロトコルは、Gitで最も一般的に使用される 2 つのデータ転送プロトコルです。SSHプロトコルは、実用性とセキュリティを反映する公開キー暗号化と公開キー ログイン メカニズムを使用します。このプロトコルを使用するには、公開キーをサーバーに置き、Git サーバーで管理する必要があります。HTTPS を
使用する場合、要件はなく、直接クローンを作成できます。

以前にHTTPS方式を紹介しました。ウェアハウスのアドレスを にコピーするだけです。ここではSSHgit clone方式に焦点を当てます。

上記のようにクローンを作成すると、公開キーをリモート ライブラリに追加しなかったため、サーバーはクローンリンクを拒否します。

それを設定する必要があります:

1. SSH キーを作成します。ユーザーのホーム ディレクトリに.sshディレクトリがあるかどうかを確認します。ある場合は、このディレクトリに2 つのファイルid_rsaとid_rsa.pubがあるかどうかを確認します。すでに存在する場合は、そのディレクトリに直接ジャンプできます。次のステップ。そうでない場合は、 SSH キーを作成する必要があります。

この場合、.sshにはid_rsaとid_rsa.pubがないため、 SSH キーを直接作成する必要があります。

この時点で、次のコマンドを入力する必要があります。ssh-keygen -t rsa -C "你的邮箱"その後、Enter キーを最後まで押します。

次に、 .sshディレクトリにこれら 2 つのファイルがあります。これら 2 つはSSH キーのペアです。id_rsaは秘密キーであり、漏洩することはできません。id_rsa.pubは公開キーです。誰にでも自信を持って伝えることができます:

2. 独自の公開キーをリモート リポジトリに追加します

リモート リポジトリに戻り、設定を見つけます。

SSH 公開キーオプションをクリックします。

入力したら、まず公開キーにランダムな名前を付けて、公開キーを次の場所にコピーします。

公開キーをコピーするには、公開キーのファイルをcat してから、公開キーをコピーします。

上記の作業を完了したら、「確認」をクリックし、アカウントのパスワードを入力します。

次に、 SSHウェアハウスを作成し、新しいディレクトリを作成してgit clone + 仓库地址、.

複数の人が開発に協力している場合、GitHub/Gitee を使用すると複数の公開キーを追加できます。全員のコンピュータ上のキーをGitHub/Giteeに追加する限り、各コンピュータのGitHub/Giteeにプッシュを送信できます。

リモート リポジトリからクローンを作成すると、Git は実際にローカルのmasterブランチをリモートのmasterブランチに自動的にマップします。リモート リポジトリのデフォルトの名前は、originです。次のようなコマンドをローカルで使用して、git remoteリモート ライブラリの情報を表示できます。

または、次git remote -vのコマンドを使用して、より詳細な情報を表示します。

上記は、クロールおよびプッシュできるオリジンのアドレスを示しています。プッシュ権限がない場合は、プッシュアドレスを表示できません。

2. リモート倉庫へのプッシュ

リモート ウェアハウスがローカルで正常に複製された後、コンテンツをウェアハウスに送信できます。たとえば、いくつかのファイルを追加して送信します。

この時点で、コンテンツをローカル ウェアハウスに送信しました。ローカル ウェアハウスのコンテンツをリモート ウェアハウスにプッシュするにはどうすればよいですか? コマンドを使用する必要があります。このコマンドは、ローカル ブランチ バージョンをリモート ウェアハウスにアップロードしてマージするために使用されgit pushますコマンドの形式は次のとおりです。

		git push <远程主机名> <本地分支名>:<远程分支名>
		#如果本地分支名与远程分支名相同，则可以省略冒号：
		git push <远程主机名> <本地分支名>

この時点で、ローカルのマスターブランチをオリジンホストのマスターブランチにプッシュしたいので、次を実行できますgit push origin master。

クローン作成時にgit pushローカルマスターブランチとリモートマスターブランチがすでに対応しているため、ここで直接使用できます。

HTTPSプロトコルを使用しているため、を押すたびにユーザー名とパスワードを入力する必要があります。SSHプロトコルを使用している場合、これは必要ありません。

以下に示すように、3 つのファイルすべてがリモート ウェアハウスにプッシュされます。

3. リモート倉庫をプルする

次のように、リモート ウェアハウスのfile1ファイルを変更するとします。[編集] をクリックして変更します。

次のように、file1 を変更しました。

現時点では、リモート ウェアハウスはローカル ウェアハウスよりも 1 つ前のバージョンであるため、ローカル ウェアハウスを最新バージョンに保つには、リモート コードをプルしてローカルでマージする必要があります。Git には、リモートからコードを取得し、ローカル バージョンをマージするgit pullために使用されるコマンドが用意されています。形式は次のとおりです。

		git pull <远程主机名> <远程分支名>:<本地分支名>
		
		# 如果远程分支是与当前分支合并，则冒号后⾯的部分可以省略。
		git pull <远程主机名> <远程分支名>

使ってみましょう:

クローン作成時にgit pullローカルマスターブランチとリモートマスターブランチがすでに対応しているため、ここで直接使用できます。

4.Gitの構成

(1) 特殊ファイルを無視する

日々の開発では、データベースのパスワードを保存する構成ファイルなど、リモート エンドに送信したくないファイルや送信すべきではないファイルがいくつかあります。Git ワークスペースのルート ディレクトリに特別なファイルを作成し、無視するファイル名を入力すると、Git はこれらのファイルを自動的に無視します。.gitignore

.gitignoreファイルを最初から作成する必要はありません。ウェアハウスの作成時にgiteeが生成してくれますが、積極的にチェックする必要があります。

このオプションが選択されていない場合でも、ワークスペースでオプションを作成できます。どちらの方法でも、完全な.gitignoreファイルが完成する可能性があります。たとえば、 .soおよび.iniで終わるすべてのファイルを無視したいとします。 .gitignoreの内容は次のとおりです:

		*.ini
		*.so

.gitignoreファイルで特定のファイルを指定することもできます。最後のステップは、.gitignore をリモート エンドに送信することです。これで完了です。

(2) コマンドのエイリアスを設定する

Gitを使用している間、いくつかのコマンドは入力するのが非常に面倒でした (長すぎます)。幸いなことに、git はコマンドの簡略化をサポートしています。

たとえば、git statusに単純化するgit stと、対応するコマンドは次のようになります。

		git config --global alias.st status

効果は次のとおりです。

5. タグ管理

(1) タグの作成

タグは、エイリアスに相当する、特定のcommitの識別として単純に理解できます。たとえば、プロジェクトが特定のバージョンをリリースすると、マイルストーンの重要性を識別するために、最後のコミットに対してv1.0などのラベルが作成されます。

使用は何ですか？タグには覚えやすく意味のある名前を付ける必要があるため、覚えにくいコミット IDと比較して、タグはこの問題を非常にうまく解決します。重要なバージョンにロールバックする必要がある場合は、ラベルを直接使用して、そのバージョンをすばやく見つけることができます。

Gitでのタグ付けは非常に簡単です。まず、タグ付けする必要があるブランチに切り替えます。

次に、次のコマンドを使用してgit tag [tag name]新しいラベルを作成します。

コマンドを使用してgit tagすべてのタグを表示できます。

デフォルトのラベルは最新のコミットに配置されます。では、指定されたコミットにラベルを付けるにはどうすればよいでしょうか? 方法は、履歴送信のコミット ID を見つけて入力することです。例は次のとおりです。

まず、過去の提出記録を確認します。

特定の提出物にラベルを付けるには、そのコミット IDをたどるだけです git tag [tag name]; バグを修正する提出物にラベルを付け、v0.9 という名前を付けるとします。

上と同様に、ラベルは入力されていますが、ラベルは日付順ではなく、アルファベット順にリストされていることに注意してください。次のコマンドを使用してタグ情報を表示できますgit show [tag name]。

最後に、Git は-a、タグ名-mと説明テキストを次の形式で指定して、説明付きのタグを作成する機能も提供します。

		git tag -a [tag name] -m "XXX" [commit id]

例えば：

ラベルをもう一度見ると、指定された説明テキストが表示されます。

(2) 操作ラベル

ラベルの入力を間違えた場合は、削除することもできます。コマンドは次のとおりです。

		git tag -d v1.0

次のように：

実際、作成されたタグはローカルにのみ保存され、自動的にリモートにプッシュされないため、リモート倉庫にもタグがあります。したがって、タイプを間違えたタグはローカルで安全に削除できます。

ラベルをリモートにプッシュする場合は、git push origin <tag name>次のようにコマンド: を使用します。

この時点で、リモート ウェアハウス内のタグを確認すると、実際にリモートにプッシュされています。

もちろん、ローカル タグが多数ある場合は、それらすべてを一度にリモート エンドにプッシュすることもできます。コマンドは次のとおりです。;git push origin --tagsここではデモは行いません。

ラベルがリモートにプッシュされている場合、リモート ラベルを削除するのは少し面倒です。最初にローカルで削除します。

次に、リモートから削除します。削除コマンドもPushで、命令はgit push origin :[tag name]次のようになります。

リモート倉庫のステータスを確認してみましょう。

確かにリモート倉庫のタグは削除されています。