この記事では、Git に関する関連知識を提供します。ウェアハウスの作成、ファイルの表示、ファイルの追加、ファイルの削除、コンテンツの変更など、一般的な運用上の問題を主にまとめています。質問です。皆さんのお役に立てれば幸いです。
推奨学習: 「Git チュートリアル 」
開く必須 ウェアハウスの場所を作成するには、Git
コマンド インターフェイスまたはターミナル ターミナルを開き、「git init
」と入力してウェアハウスを作成します。
作成完了後にプロンプトが表示されます /Users/huaqiangsun/Git/.git/
にある空の Git リポジトリが初期化されました 空の Git
リポジトリは、現在のディレクトリで初期化されている場合、ディレクトリ内の .git
フォルダーも表示できます (通常は隠しフォルダーです。Mac では shift cmd .
ショートカット キーの組み合わせを使用して隠しファイルを表示できます) )。
Git
について言及するとき、ワークスペース、ステージング領域、バージョン ライブラリの概念がよく言及されます。 . これは、非常に一般的な方法で、実際、ワークスペースは一般に、私たちが見ることができるファイルとローカル操作ファイルが配置されているディレクトリを指します。私たちが通常作成するコード ファイルと管理するリソース ファイルはすべて、ここのファイルはバージョン管理されているファイルとバージョン管理されていないファイルに細分化されています。
一時記憶領域に関しては、index
ファイルに接続されます。ワークスペース内の新しいファイルや、変更されてバージョン管理されているファイルについては、## を使用します#git add file_name 一時保存領域に追加できます。これは名前を登録するのと同じです。将来リポジトリに送信するときに、これらの登録されたファイルも一緒に持ち込まれます。実際には、すべてのファイルがリポジトリに追加されます。
git add コマンドの実行後に生成されます。対応するオブジェクト オブジェクトは
.git/objects ディレクトリに配置され、ステータスは
staged になります。リポジトリの場合、ブランチはこれらのオブジェクトを参照します。
committed になります。これは、実際には一種のファイルです。
unmodified ステータスでは、リポジトリはユーザーが行うすべての送信を記録し、ユーザーが行うすべての変更の内容を追跡できます。
バージョン管理下にない
- 未追跡
バージョン管理下にあります変更済みステータス;
- modified
バージョン管理下で変更され、ステージング領域に送信されましたstatus;
- staged
ステージング領域からコミットされましたstatus;
- committed
ステータスをローカル ウェアハウスに送信します;
- unmodified
ステータスを変更せずにローカル ウェアハウスに送信するか、リモート ウェアハウスから複製します;
git status を使用して、現在のウェアハウス内のファイルの変更とコミットされていないファイルを確認します。
このうち、
add変更されたファイルが送信前に一時記憶領域に追加されると、再度変更された後、ファイルは非一時記憶領域に再び表示されるため、一時記憶領域に再度
- Changes to be commit
は、一時保管領域がすでに存在しており、ウェアハウスに送信する必要があることを意味します。 ;
- Changes not staged for commit
追跡されていないファイルは、操作されたファイルですが、まだステージング領域に送信されていません。このようなファイルは、## を使用してキャッシュ領域に追加する必要があります。 #add
してからウェアハウスに送信します。 ;
- は、一時記憶領域にないファイルです。;
追加する必要があります。そうでない場合、ウェアハウス内のファイルには、commit
コンテンツの後の二次変更が含まれません。
git status
ファイルを追加するには、正しいファイル パスを入力する必要があります。複数のファイルを追加する必要がある場合は、スペースを使用して区切ってください。- 未送信の送信の数のみを表示できますが、特定のファイル情報は表示できません。
git Cherry -v
- は未送信のコミットの説明/指示のみを表示できます;
git log master ^origin/master
- は未送信のコミットを表示できますステージング領域への追加の詳細。
メッセージが表示されない場合は、ファイルが正常に追加されたことを意味します。
使用 git commit -m "description"
は、一時ストレージに追加されたファイルを送信するために使用されますエリアごとに、複数のファイルを提出することができます。
5. ウェアハウスからファイルを削除する
ウェアハウスに送信されたファイルをディスクから削除する場合、ファイルはウェアハウスのキャッシュにまだ存在するため、
git rm を使用します。 [ fileName]現在の操作が間違っていた場合は、ロールバック操作によってファイルを取得できます。 <p> 以前に変更されたファイル、または一時記憶領域に配置されたファイルを削除する場合は、強制削除オプション <code>-f
パラメーターを使用する必要があります。
誤操作により不要なファイルがウェアハウスに送信された場合、--cached
を使用してウェアハウス内のレコードのみを削除し、ディスクからは削除しません。
git rm
ファイルまたはディレクトリの名前をコマンドの後にリストすることも、glob
モードを使用することもできます。例: git rm log/\*.log
。
アスタリスク *
の前のバックスラッシュ \
に注意してください。Git
には独自のファイル パターン拡張子一致メソッドがあるため、## は使用されません。 #shell を使用して拡張を支援します。このコマンドは、
log/ ディレクトリ内の拡張子
.log を持つすべてのファイルを削除します。
.gitignore を作成できます。 File ファイルを無視する目的を達成するには、無視する必要があるファイル名または式を
.gitignore ファイルに書き込みます。
.gitignore 形式の仕様は次のとおりです:
# で始まる行は Git によって無視されます。 。
パターン マッチングを使用でき、ワークスペース全体に再帰的に適用されます。
) で始めることができます。
) で終わることでディレクトリを指定できます。
) を追加することでそれを無効にできます。
git は
Glob モードもサポートしています。
Glob モードは、
Shell の簡略化された正規表現です。
#) は 0 個以上の任意の文字に一致し、
は正方形内の任意の列に一致します。括弧 (この例は a、b、または c のいずれかに一致します);
) は任意の 1 文字のみに一致します;
if 2 つの文字を区切るにはダッシュを使用しますこれは、これら 2 つの文字の範囲内のすべてが一致する可能性があることを意味します (たとえば、[0-9] は、0 から 9 までのすべての数字が一致することを意味します)。 ) を使用します。たとえば、a/**/z は、a/z、a/b/z、または a/b/ と一致します。 c/zなど。
#.gitignore ファイルを有効にする手順は次のとおりです:
git status
- #git status -- ignored
##git rm -r --cached .// ステータスをチェックし、無視されたファイルが含まれているかどうかを確認します
- // キャッシュをクリアします。 - r は再帰的な削除を意味します
git status --ignored
- // 特定の効果を確認します
//ファイルを再トレースします##git add 。
- // 送信してコメントします
git commit -m "update .gitignore"
## 7. ファイルの変更内容の表示
すべての追跡ファイルの変更の比較を表示します。
git diff
は、ステージングされていないファイルの変更されたコンテンツを表示するためのものであることに注意してください。ファイルがステージングされた領域に追加された後は、再度使用することはできません。 git diff
変更を表示するには、git diff --cached
を使用する必要があります。 8. ファイルの移動
ファイルの名前を変更する必要がある場合は、
名前変更操作は 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前述のファイル ステータスを思い出してください。ファイル ステータスは通常、次のように分類できます: #バージョン管理下にない
ステータス;
# #バージョン管理下で変更済み
バージョン管理下で変更され、ステージング領域に送信されます
変更せずにローカル ウェアハウスに送信されたか、リモート ウェアハウスから複製された
9.1 ステージング領域ファイルを元に戻します
説明:
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
操作を実行した後、次の方法で復元できます。
##gitrestor --staged newfile
git replace HEAD newfile
9.2 ファイルへの変更を元に戻す
git checkout -- [fileName]! 注: git checkout -- <file></file>
は危険なコマンドであることに注意してください。そのファイルにローカルで加えた変更はすべて失われます。
は、最近コミットされたバージョンでそれを上書きします。そのファイルにローカルな変更を加えたくないことが確実にわかっている場合を除き、このコマンドを使用しないでください。 ステートメント: ステージング領域に追加されていないファイルは追跡できないため、ファイルに対する変更をロールバックすることはできません。これは、ローカル ファイルの元に戻す操作によってのみ実行できます。
10. 操作履歴の表示プロジェクト内のすべての提出情報を表示したい場合は、
git log各レコードには、送信された SHA-1
検証、作成者の名前と電子メール アドレス、および送信時間が、送信時間の逆順に表示されます。
単純な
git log
に加えて、出力情報をフィルタリングしてフォーマットするためのパラメータを追加することもできます:
は各提出物を 1 行に表示します。これは、多数の提出物を参照する場合に非常に便利です。 short
、full
、fuller
オプションもあり、これらは基本的に同じ形式で情報を表示しますが、詳細度は異なります。
formart
を使用して印刷形式をカスタマイズします。一般的に使用される形式情報は次のとおりです:
$ git log --pretty=oneline
$ git log --pretty=short
$ git log --pretty=full
$ git log --pretty=fuller
修改文件人员与提交文件人员可以不是同一个人,所以在查询日志时会区分修改人与提交人。
推荐学习:《Git学习教程》
以上が詳しいまとめ! Git の一般的な操作の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。