詳しいまとめ！ Git の一般的な操作

この記事では、Git に関する関連知識を提供します。ウェアハウスの作成、ファイルの表示、ファイルの追加、ファイルの削除、コンテンツの変更など、一般的な運用上の問題を主にまとめています。質問です。皆さんのお役に立てれば幸いです。

推奨学習: 「Git チュートリアル 」

1. Git ウェアハウスの作成

開く必須 ウェアハウスの場所を作成するには、Git コマンド インターフェイスまたはターミナル ターミナルを開き、「git init」と入力してウェアハウスを作成します。

作成完了後にプロンプ​​トが表示されます /Users/huaqiangsun/Git/.git/ にある空の Git リポジトリが初期化されました 空の Git リポジトリは、現在のディレクトリで初期化されている場合、ディレクトリ内の .git フォルダーも表示できます (通常は隠しフォルダーです。Mac では shift cmd . ショートカット キーの組み合わせを使用して隠しファイルを表示できます) ）。

2. ウェアハウス ファイルのステータスを確認する

Git について言及するとき、ワークスペース、ステージング領域、バージョン ライブラリの概念がよく言及されます。 . これは、非常に一般的な方法で、実際、ワークスペースは一般に、私たちが見ることができるファイルとローカル操作ファイルが配置されているディレクトリを指します。私たちが通常作成するコード ファイルと管理するリソース ファイルはすべて、ここのファイルはバージョン管理されているファイルとバージョン管理されていないファイルに細分化されています。

一時記憶領域に関しては、index ファイルに接続されます。ワークスペース内の新しいファイルや、変更されてバージョン管理されているファイルについては、## を使用します#git add file_name 一時保存領域に追加できます。これは名前を登録するのと同じです。将来リポジトリに送信するときに、これらの登録されたファイルも一緒に持ち込まれます。実際には、すべてのファイルがリポジトリに追加されます。 git add コマンドの実行後に生成されます。対応するオブジェクト オブジェクトは .git/objects ディレクトリに配置され、ステータスは staged になります。リポジトリの場合、ブランチはこれらのオブジェクトを参照します。

リポジトリはファイルの変更先です。最終的な変更はリポジトリに送信されます。このとき、送信されたファイルのステータスは

committed になります。これは、実際には一種のファイルです。 unmodified ステータスでは、リポジトリはユーザーが行うすべての送信を記録し、ユーザーが行うすべての変更の内容を追跡できます。

ファイルのステータスは通常、次のように分類できます:

バージョン管理下にない
• 未追跡ステータス;
バージョン管理下にあります変更済み
• modified status;
バージョン管理下で変更され、ステージング領域に送信されました
• staged status;
ステージング領域からコミットされました
• committed ステータスをローカル ウェアハウスに送信します;
• unmodified ステータスを変更せずにローカル ウェアハウスに送信するか、リモート ウェアハウスから複製します;

git status を使用して、現在のウェアハウス内のファイルの変更とコミットされていないファイルを確認します。
このうち、

• Changes to be commit は、一時保管領域がすでに存在しており、ウェアハウスに送信する必要があることを意味します。 ;
• Changes not staged for commit は、操作されたファイルですが、まだステージング領域に送信されていません。このようなファイルは、## を使用してキャッシュ領域に追加する必要があります。 #add してからウェアハウスに送信します。 ;
追跡されていないファイル
• は、一時記憶領域にないファイルです。;

変更されたファイルが送信前に一時記憶領域に追加されると、再度変更された後、ファイルは非一時記憶領域に再び表示されるため、一時記憶領域に再度

add

追加する必要があります。そうでない場合、ウェアハウス内のファイルには、commit コンテンツの後の二次変更が含まれません。

概要

git status
• 未送信の送信の数のみを表示できますが、特定のファイル情報は表示できません。
git Cherry -v
• は未送信のコミットの説明/指示のみを表示できます;
git log master ^origin/master
• は未送信のコミットを表示できますステージング領域への追加の詳細。 メッセージが表示されない場合は、ファイルが正常に追加されたことを意味します。

ファイルを追加するには、正しいファイル パスを入力する必要があります。複数のファイルを追加する必要がある場合は、スペースを使用して区切ってください。

4. 一時ストレージ領域にファイルを送信します

使用 git commit -m "description" は、一時ストレージに追加されたファイルを送信するために使用されますエリアごとに、複数のファイルを提出することができます。

5. ウェアハウスからファイルを削除する

ウェアハウスに送信されたファイルをディスクから削除する場合、ファイルはウェアハウスのキャッシュにまだ存在するため、

git rm を使用します。 [ fileName]

キャッシュ内のファイルを削除します。再送信後、ファイルはバージョン管理に含まれなくなります。

現在の操作が間違っていた場合は、ロールバック操作によってファイルを取得できます。 <p> 以前に変更されたファイル、または一時記憶領域に配置されたファイルを削除する場合は、強制削除オプション <code>-f パラメーターを使用する必要があります。

誤操作により不要なファイルがウェアハウスに送信された場合、--cached を使用してウェアハウス内のレコードのみを削除し、ディスクからは削除しません。

git rm ファイルまたはディレクトリの名前をコマンドの後にリストすることも、glob モードを使用することもできます。例: git rm log/\*.log。

アスタリスク * の前のバックスラッシュ \ に注意してください。Git には独自のファイル パターン拡張子一致メソッドがあるため、## は使用されません。 #shell を使用して拡張を支援します。このコマンドは、log/ ディレクトリ内の拡張子 .log を持つすべてのファイルを削除します。

6. ファイルを無視する設定

一部のログ ファイル、一時ファイル、および一部のソフトウェアによって生成された設定ファイルまたは出力ファイルについては、ファイル管理が必要ないため、

.gitignore を作成できます。 File ファイルを無視する目的を達成するには、無視する必要があるファイル名または式を .gitignore ファイルに書き込みます。

ファイル

.gitignore 形式の仕様は次のとおりです:

すべての空行または
• # で始まる行は Git によって無視されます。 。
標準の
• glob パターン マッチングを使用でき、ワークスペース全体に再帰的に適用されます。
一致パターンは、再帰を防ぐために (
• /) で始めることができます。
一致パターンは (
• /) で終わることでディレクトリを指定できます。
指定されたパターンの外にあるファイルまたはディレクトリを無視するには、パターンの前に感嘆符 (
• #!) を追加することでそれを無効にできます。

git は Glob モードもサポートしています。Glob モードは、Shell の簡略化された正規表現です。

アスタリスク (
• #) は 0 個以上の任意の文字に一致し、
• [abc] は正方形内の任意の列に一致します。括弧 (この例は a、b、または c のいずれかに一致します);
疑問符 (
• ?) は任意の 1 文字のみに一致します; if 2 つの文字を区切るにはダッシュを使用しますこれは、これら 2 つの文字の範囲内のすべてが一致する可能性があることを意味します (たとえば、[0-9] は、0 から 9 までのすべての数字が一致することを意味します)。
  
任意の中間ディレクトリと一致するには、2 つのアスタリスク (
• **) を使用します。たとえば、a/**/z は、a/z、a/b/z、または a/b/ と一致します。 c/zなど。

#.gitignore ファイルを有効にする手順は次のとおりです:

• #git status -- ignored

  // ステータスをチェックし、無視されたファイルが含まれているかどうかを確認します

##git rm -r --cached .
• // キャッシュをクリアします。 - r は再帰的な削除を意味します

git status --ignored
• // 特定の効果を確認します
  ##git add 。
//ファイルを再トレースします

• git commit -m "update .gitignore"
// 送信してコメントします

• ## 7. ファイルの変更内容の表示

git status

を使用すると、各ファイルの変更ステータスを表示することしかできませんが、各ファイルのどの内容が変更されたのかを確認することはできません。

git diff を使用できます。

すべての追跡ファイルの変更の比較を表示します。 git diff
は、ステージングされていないファイルの変更されたコンテンツを表示するためのものであることに注意してください。ファイルがステージングされた領域に追加された後は、再度使用することはできません。 git diff
変更を表示するには、git diff --cached を使用する必要があります。 8. ファイルの移動ファイルの名前を変更する必要がある場合は、

git mv [oldFileName] [new FileName]

を使用できます。

Git

名前変更操作は 3 つのステップに分かれています。最初のステップはファイルの名前を変更し、次に元のファイルをウェアハウスから削除し、最後に新しいファイルをステージング領域に追加して送信を待ちます。 <div class="code" style="position:relative; padding:0px; margin:0px;"><pre class="brush:php;toolbar:false">$ mv README.md LOOKME.md $ git rm README.md $ git add LOOKME.md</pre><div class="contentsignin">ログイン後にコピー</div></div>ソフトウェアを使用してファイルをバッチで変更する場合は、このプロセスに従って、最初に元のファイルを削除してから、新しいファイルを追加する必要もあります。 9. 操作を元に戻す

操作エラーによりファイルの内容が送信または変更された場合、

Git

ロールバックを通じて変更前の状態にロールバックできます。手術。

前述のファイル ステータスを思い出してください。ファイル ステータスは通常、次のように分類できます: #バージョン管理下にない

未追跡

ステータス;

# #バージョン管理下で変更済み

modified
• status;バージョン管理下で変更され、ステージング領域に送信されます
staged
• status;
ステージング領域からローカル ウェアハウスに送信された commit
• ステータス;変更せずにローカル ウェアハウスに送信されたか、リモート ウェアハウスから複製された
unmodified
• ステータス。
• 9.1 ステージング領域ファイルを元に戻します
  使用 gitrestor --staged [fileName]
または

git replace HEAD [ fileName]

一時記憶領域のファイルを復元できます。

説明: git register コマンドは、Git 2.23 バージョンの後に新たに追加され、git checkout の機能を共有するために使用されます。一時コマンドを使用すると、ストレージ領域またはリポジトリ内のファイルがローカル ファイルの変更を上書きして、変更をロールバックする目的を達成します。同時に、リポジトリ内のファイルを使用して、ローカル ファイルのファイルを上書きすることもできます。ロールバックの目的を達成するための一時ストレージ領域。git addコマンドの目的。

!!この操作はブランチ レコードには影響しないことに注意してください。これは、ファイルを再度チェックアウトしてローカルの変更を上書きする、前の git checkout コマンドと同等です。

git replace は、実際にはブランチのヘッド ポイントを設定するために使用されます。一連のサブミットを行った後、最近のサブミットに問題があることに突然気づきました。送信から開始する レコードから削除するには、git replace コマンドが使用されます。このコマンドの後に commit id が続きます。これは、現在のブランチがロールバックされることを意味します。特定の コミット ID に対応するステータスに応じて、後続のログ レコードが削除され、ワー​​クスペース内のファイルのステータスがパラメータに応じてさまざまな状態に復元されます。

• --soft: ロールバックされたバージョンの変更は一時ストレージ領域に配置され、再度送信できます。

• --mixed: デフォルト オプションでは、ロールバックされたバージョンへの変更は作業ディレクトリに配置されます。最初にステージング領域に追加してから、送信してください。

• --hard: ロールバックされたバージョンの変更は、まるで存在しなかったかのように直接破棄されます。

gitrest HEAD file_name コマンドを使用して、ファイルを HEAD ポイント バージョンに対応する状態 (実際には現在のバージョン ライブラリ内の状態は、ローカルの変更を復元するのと同じです。

ステージング領域およびリポジトリに追加されていないワークスペース内のファイルについては、git add 操作を実行した後、次の方法で復元できます。

git rm --cached newfile
• ##gitrestor --staged newfile
• git replace HEAD newfile
#注: 最後の 2 つのコマンドを使用する場合、それをリポジトリ内の最初のファイルにすることはできません。

9.2 ファイルへの変更を元に戻す

git checkout -- [fileName]

を使用して、ファイルを最後に送信された状態にロールバックします。

! 注: git checkout -- <file></file> は危険なコマンドであることに注意してください。そのファイルにローカルで加えた変更はすべて失われます。

Git

は、最近コミットされたバージョンでそれを上書きします。そのファイルにローカルな変更を加えたくないことが確実にわかっている場合を除き、このコマンドを使用しないでください。 ステートメント: ステージング領域に追加されていないファイルは追跡できないため、ファイルに対する変更をロールバックすることはできません。これは、ローカル ファイルの元に戻す操作によってのみ実行できます。

10. 操作履歴の表示プロジェクト内のすべての提出情報を表示したい場合は、

git log

を使用してすべての提出記録を印刷できます。参加者。

各レコードには、送信された SHA-1 検証、作成者の名前と電子メール アドレス、および送信時間が、送信時間の逆順に表示されます。

単純な git log
に加えて、出力情報をフィルタリングしてフォーマットするためのパラメータを追加することもできます:

-p --patch

: 各コミットによってもたらされた違いを表示します。表示されるログ エントリの数を制限することもできます。たとえば、-2 オプションを使用して、最新の 2 つのコミットのみを表示します。

• 
  

  --stat
: 変更されたすべてのファイル、変更されたファイルの数、および変更されたファイルのどの行が削除または追加されたかをリストします。 。各提出物の最後には概要も記載されています。

• 
  

  --pretty
: このオプションには、使用できる組み込みのサブオプションがいくつかあります。たとえば、
• oneline

  は各提出物を 1 行に表示します。これは、多数の提出物を参照する場合に非常に便利です。 short、full、fuller オプションもあり、これらは基本的に同じ形式で情報を表示しますが、詳細度は異なります。 formart
  を使用して印刷形式をカスタマイズします。一般的に使用される形式情報は次のとおりです:
  

示例 10.1 将日志信息显示在一行上

$ git log --pretty=oneline

示例 10.2 以 short 格式输出仓库修改信息

$ git log --pretty=short

示例 10.3 以 full 格式输出仓库修改信息

$ git log --pretty=full

示例 10.4 以 fuller 格式输出仓库修改信息

$ git log --pretty=fuller

修改文件人员与提交文件人员可以不是同一个人，所以在查询日志时会区分修改人与提交人。

推荐学习：《Git学习教程》

以上が詳しいまとめ！ Git の一般的な操作の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。