【Gitの基礎】よく使うgitコマンド(4)

記事ディレクトリ

1. 緊急時の対応

1.1 一時的な変更

このような状況で、特定の機能の開発やリファクタリング (FT-12345 ブランチ) に集中しているのですが、オンライン上で突然 BUG が表示され、BUG を解決する必要があるのですが、現在の変更をどうすればよいでしょうか? ? 送信すると、意味のないコミットが生成されます。次に、この時点で git stash を使用できます。使用する手順は次のとおりです。

まず、ステージングする必要があるブランチ (例: FT-12345) 上にいることを確認します。次のコマンドを使用して、現在のブランチを表示できます。
```
git branch
```
ブランチを切り替える必要がある場合は、次を使用します。
```
git checkout FT-12345
```
git stashコマンドを使用して、変更を新しいリポジトリに保存します。オプションで説明メッセージを追加すると、後でこのストアを見つけて適用しやすくなります。
```
git stash save "Work in progress on FT-12345"
```
これにより、変更が新しいリポジトリに保存され、ワークスペースが最後のコミットの状態に復元されます。
これで、バグを修正する必要があるブランチに自由に切り替えることができます。たとえば、次のようになります。
```
git checkout master
```
または：
```
git checkout hotfix-branch
```
正しいブランチに切り替えた後、必要なバグ修正を行い、変更をコミットします。
バグ修正が完了したら、元のブランチ (例: FT-12345) に切り替えることができます。
```
git checkout FT-12345
```
次に、git stash listコマンドをすべてのバケットを表示します。次のような出力が表示されるはずです。
```
stash@{
      
      0}: On FT-12345: Work in progress on FT-12345
```
段階的な変更を現在のブランチに適用するには、リポジトリへの参照を指定してgit stash applyコマンドを。
```
git stash apply stash@{
      
      0}
```
これにより、以前にステージングされた変更がワークスペースに適用されます。
適用されたスタッシュをスタッシュリストから削除する場合は、git stash drop次のコマンドを。
```
git stash drop stash@{
      
      0}
```

こうすることで、緊急のバグ修正に取り組んでいる間、現在のブランチの変更を安全に保存し、バグへの作業が終了したときにそれらの変更を復元できます。

ただし、最後の変更をステージングして後で元に戻す必要がある場合は、git stashand を使用するだけですgit stash pop。

他のブランチに切り替える前にgit stash段階的な変更を使用する
git stash pop変更が完了したらrevert-modification を使用し、以前に動作していたブランチに戻します。

1.2 git stash のいくつかのコマンド

git stash save [<message>]: 現在のワークスペースの変更を新しいリポジトリに保存し、最後のコミットの状態に戻します。オプションで説明メッセージを提供して、異なるストアを簡単に区別できます。
```
git stash save "Work in progress"
```

git stash list: すべてのバケットをリストします。出力は次のようになります。

stash@{
      
      0}: On branch-name: Work in progress
stash@{
      
      1}: On another-branch: Another work in progress

git stash apply [<stash>]: 指定されたバケットを現在のワークスペースに適用します。スタッシュが指定されていない場合は、デフォルトで最も近いスタッシュ (stash@{0}) が使用されます。
```
git stash apply stash@{
      
      0}
```
git stash branch <branch-name> [<stash>]: 新しいブランチを作成し、指定されたバケットを新しいブランチに適用します。バケットが指定されていない場合は、デフォルトで最も近いバケットが使用されます。
```
git stash branch new-feature-branch stash@{
      
      1}
```
git stash pop [<stash>]: と似ていますgit stash applyが、ストアが適用されると、ストアリストから削除されます。バケットが指定されていない場合は、デフォルトで最も近いバケットが使用されます。
```
git stash pop stash@{
      
      0}
```
git stash drop [<stash>]: 指定したストレージ領域をストレージリストから削除します。バケットが指定されていない場合、デフォルトでは最も近いバケットが削除されます。
```
git stash drop stash@{
      
      1}
```
git stash clear：すべての保存領域を削除します。
```
git stash clear
```
git stash push [-m|--message <message>]: これはgit stash saveの。Git 2.13.2 以降を推奨しますgit stash push。現在のワークスペースの変更を新しいリポジトリに保存し、最後のコミットの状態に戻します。オプションで説明メッセージを提供して、異なるストアを簡単に区別できます。
```
git stash push -m "Work in progress"
```

2. git管理が必要ないファイルを指定する

2.1 git管理が不要なファイルを指定する

Git をバージョン管理に使用する場合、Java や C/C++ などのプログラミング言語のプログラマーは、次のような問題に遭遇することがあります。などのコマンドを実行するときに、git add .コンパイルによって生成された中間ファイル (.class、.obj、.o など) 、など）がリポジトリに送信されます。これを回避するために、Git では、どのファイルを Git リポジトリに送信しないかを指定するルールを定義する .gitignore というファイルが提供されています。

.gitignore ファイルはリモートリポジトリにコミットできるため、すべての開発者がこれらのルールを共有できます。.gitignore ファイルでは、各行が無視ルールを定義します。次に例を示します。

*.[oa]
*~

最初の行は、.o または .a で終わるすべてのファイルを無視することを意味し、2 行目は、「~」で終わるすべてのファイルを無視することを意味します。

.gitignore を使用する場合は、通常、次のルールに従います。

オペレーティングシステムによって自動的に生成されるサムネイルなどのファイルは無視します。
コンパイルによって生成される中間ファイル、実行可能ファイルなどは無視します。つまり、ファイルが別のファイルから自動的に生成された場合、自動生成されたファイルをリポジトリに置く必要はありません。たとえば、Java コンパイルによって生成された .class ファイル、または C++ の .obj ファイルです。
パスワードやログファイルを保存する構成ファイルなど、機密情報を含む構成ファイルは無視します。

これらのルールに従うことで、ソースコードと必要な構成ファイルのみが Git リポジトリに含まれるようになり、リポジトリをクリーンで安全に保つことができます。

2.2 .gitignore のルール

空行: 空行は無視され、異なるルールグループを区切るために使用できます。
コメント: ポンド記号 (#) で始まる行はコメントとして扱われ、Git によって無視されます。

例：
```
# 这是一个注释
```
ワイルドカード: パターンマッチングには、アスタリスク (*)、疑問符 (?)、角括弧 ([]) などのワイルドカードを使用できます。
- アスタリスク (*) : 任意の長さの任意の文字に一致します。
  例：
```
*.log  # 忽略所有.log文件
```
- 疑問符 (?) : 任意の 1 文字と一致します。
  例：
```
?.txt  # 忽略所有单个字符加.txt后缀的文件，如a.txt，但不包括ab.txt
```
- 角括弧 ([]) : 角括弧内の任意の 1 文字と一致します。
  例：
```
[abc].txt  # 忽略a.txt、b.txt、c.txt
```
スラッシュ (/) : ディレクトリを指定するために使用されます。
- ルールの先頭にスラッシュを使用すると、ルールが現在のディレクトリにのみ適用されることを示します。
  例：
```
/debug.log  # 仅忽略当前目录下的debug.log文件
```
- ファイルやシンボリックリンクではなく、ディレクトリのみを照合するには、ルールの最後にスラッシュを使用します。
  例：
```
tmp/  # 忽略所有名为tmp的目录，但不忽略tmp文件或tmp符号链接
```
感嘆符 (!) : ルールを無効にするために使用され、ルールに一致するファイルまたはディレクトリが無視されないことを示します。

例：
```
*.log      # 忽略所有.log文件
!important.log  # 但不忽略important.log文件
```
二重アスタリスク (**) : 任意の数のディレクトリレベルと一致するために使用されます。

例：
```
**/debug.log  # 忽略所有目录下的debug.log文件，包括子目录
```
組み合わせルール: 複数のルールを組み合わせて、複雑な要件を満たすことができます。

例：
```
# 忽略所有.txt文件，但不忽略doc/目录下的.txt文件
*.txt
!/doc/*.txt
/doc/**/*.txt
```

これらのルールを理解した後、プロジェクトのニーズに合った .gitignore ファイルを作成し、特にバージョン管理に含める必要のないファイルとディレクトリを無視することができます。

.gitignore ファイルを自動的に生成する別の URL は次のとおりです: https://www.toptal.com/developers/gitignore

3. プロジェクト間の依存関係を解決する方法

3.1 git を使用してプロジェクト間の依存関係を処理する方法

製品開発プロセスでは、異なるチームが異なるモジュールを開発できるように、製品アーキテクチャが複数のモジュールに分割されている状況によく遭遇します。たとえば、ソースsrcディレクトリには次のモジュールが含まれる場合があります。

src
 |------- buffer
 |------- f-threadpool
 |------- iniconfig
 |------- intf
 |------- store
 |------- router

サードパーティのプロジェクトに依存する場合もあります。これらの依存関係を管理するには、Git のサブモジュール機能を使用できます。サブモジュールを使用すると、親プロジェクトに多数の独立した Git サブプロジェクトを含めることができます。これらのサブプロジェクトは個別に送信、プッシュ、プルなどを行うことができ、親プロジェクトのコミットはサブプロジェクトに影響しません。

サブモジュールを使用すると、次のような利点があります。

サブモジュールを Git プロジェクトとして分離すると、独立して開発でき、サブモジュール内のエラーは親プロジェクトに影響しません。これにより、プロジェクトを分離した状態に保ち、プロジェクト間の結合を減らすことができます。
チームはさまざまな Git プロジェクトのモジュールで作業できるため、コードの送信への依存が軽減され、更新操作によって生じる競合と複雑さが軽減されます。

Git サブモジュールを使用すると、プロジェクト間の依存関係をより適切に管理し、モジュール開発を実現し、チームのコラボレーションの効率を向上させることができます。

3.2 サブモジュールの使用方法

サブモジュールを追加

リポジトリをサブモジュールとして現在のプロジェクトに追加するには、次のコマンドを使用します。
```
git submodule add <repository_url> <path_to_submodule>
```
ここで、<repository_url>はサブモジュールリポジトリの URL、は<path_to_submodule>メインプロジェクト内のサブモジュールのパスです。

たとえば、メインプロジェクトがありmy_project、次のサブモジュールを追加したいとしますmy_library。
```
git submodule add https://github.com/username/my_library.git libs/my_library
```
これにより、ディレクトリの下にサブモジュールがlibs/my_library追加されます。my_library
サブモジュールの初期化と更新

サブモジュールを追加した後、初期化して更新する必要があります。これを次のコマンドで実行します。
```
git submodule init
git submodule update
```
これにより、サブモジュールのコードがチェックアウトされます。--recursiveオプションを使用して、すべてのサブモジュールとそのサブモジュールを同時に初期化および更新することもできます。
```
git submodule update --init --recursive
```
メインプロジェクトがプルされたときにサブモジュールを更新する

リモートリポジトリからメインプロジェクトをプルするときにサブモジュールも更新されるようにするには、次のコマンドを使用できます。
```
git pull --recurse-submodules
```
サブモジュールに変更を加える

サブモジュールに変更を加えるには、まずサブモジュールディレクトリに移動し、通常の Git リポジトリと同様に変更、コミット、プッシュを行います。
```
cd libs/my_library
# 对子模块进行更改
git add .
git commit -m "Update submodule"
git push
```
メインプロジェクト内のサブモジュールへの参照を更新する

サブモジュールに変更を加えてプッシュした後、メインプロジェクト内のサブモジュールの参照を更新する必要があります。メインプロジェクトディレクトリに戻り、次のコマンドを使用します。
```
cd ../..
git add libs/my_library
git commit -m "Update submodule reference"
git push
```
これにより、メインプロジェクト内のサブモジュールの参照が更新され、サブモジュールの最新のコミットを指すようになります。
サブモジュールの削除

プロジェクトからサブモジュールを削除するには、次の手順に従います。
1. .gitmodulesファイル内の関連するサブモジュールエントリを削除します。
2. .git/configファイル内の関連するサブモジュールエントリを削除します。
3. ファイルシステム内のサブモジュールのディレクトリを削除します。
次に、これらの変更をコミットします。
```
git add .gitmodules
git rm --cached <path_to_submodule>
git commit -m "Remove submodule"
git push
```
サブモジュールは正常に削除されました。

3.3 サブモジュールのクローンを作成する方法

サブモジュールを含むプロジェクトを複製する場合、Git はデフォルトでメインプロジェクトを複製しますが、サブモジュールの内容は複製しません。メインプロジェクトとサブモジュールを同時にクローンするには、次の方法を使用できます。

方法 1:クローン作成時に--recurse-submodulesオプションを追加する

--recurse-submodulesメインプロジェクトとそのすべてのサブモジュールをオプションを使用してクローンします。

git clone --recurse-submodules <repository_url>

これにより、メインプロジェクトとそのすべてのサブモジュールのクローンが作成され、サブモジュールが自動的に初期化および更新されます。

方法 2: クローン作成後にサブモジュールを手動で初期化して更新する

メインプロジェクトのクローンを作成したが、サブモジュールのクローンは作成していない場合は、次のコマンドを使用してサブモジュールを手動で初期化し、更新できます。

git submodule init
git submodule update

サブモジュール内にネストされたサブモジュールもある場合は、--recursiveオプションを使用して、すべてのサブモジュールとそのサブモジュールを同時に初期化および更新できます。

git submodule update --init --recursive

3.4 サブモジュールの落とし穴と課題

サブモジュールの複雑さ: サブモジュールの使用と管理は通常の Git リポジトリよりも複雑であり、追加のコマンドと操作が必要です。特にサブモジュールに慣れていないチームメンバーにとっては、困難や課題に遭遇する可能性があります。
サブモジュールのバージョン参照: サブモジュールは、サブモジュールに対する最新の変更をリアルタイムで追跡するのではなく、メインプロジェクト内の特定のコミットへの参照にすぎません。これにより、サブモジュールを更新するときに問題が発生し、メインプロジェクト内のサブモジュール参照を手動で更新する必要が生じる可能性があります。
サブモジュールの初期化と更新を忘れる: メインプロジェクトを複製するときに、--recurse-submodulesオプションを使用するか手動でサブモジュールの初期化と更新を忘れる可能性があります。これにより、サブモジュールコードが欠落し、ビルドエラーやランタイムエラーが発生する可能性があります。
サブモジュールとメインプロジェクトの分離: サブモジュールは独立した Git ウェアハウスであり、個別に送信、プル、プッシュする必要があります。これにより、サブモジュールとメインプロジェクトを管理する際に、チームメンバー間で混乱や誤った処理が発生する可能性があります。
権限とアクセス制御: サブモジュールは、異なる権限とアクセス制御を持つ異なる Git リポジトリに配置される場合があります。サブモジュールを構成するときは、権限の問題によるエラーを回避するために、すべてのチームメンバーが適切なアクセス権を持っていることを確認する必要があります。
サブモジュールの削除と移動: サブモジュールの削除または移動には複数の手順が必要であり、エラーが発生しやすくなります。間違って実行すると、Git リポジトリ内で不正確な参照や一貫性のない参照が発生する可能性があります。

3.4 サブモジュールの内容を更新する方法

サブモジュールのリモートウェアハウスが更新されると、メインプロジェクトでサブモジュールのコンテンツを更新する必要があります。サブモジュールのコンテンツを更新する手順は次のとおりです。

サブモジュールのディレクトリを入力します。まず、サブモジュールのディレクトリに移動します。
```
cd <path_to_submodule>
```
サブモジュールの最新の変更をプルする: 次のgit fetchコマンドを使用して、サブモジュールの最新の変更をリモートリポジトリからプルします。
```
git fetch
```
特定のブランチから更新を取得することも選択できます。例:
```
git fetch origin master
```
サブモジュールの更新をチェックアウトする:git checkoutコマンドを使用して、サブモジュールを最新のコミットに更新します。リモートブランチの最新バージョンに更新する場合は、次のように実行できます。
```
git checkout origin/master
```
特定のコミットに更新したい場合は、次のように実行できます。
```
git checkout <commit_sha>
```
メインプロジェクトディレクトリに戻ります: サブモジュールを更新した後、メインプロジェクトディレクトリに戻ります。
```
cd ..
```
メインプロジェクトのサブモジュール参照を更新します。git addおよびgit commitコマンドを使用して、サブモジュールの更新をメインプロジェクトに追加します。
```
git add <path_to_submodule>
git commit -m "Update submodule to the latest version"
```
メインプロジェクトの変更をプッシュする: メインプロジェクトの変更をリモートリポジトリにプッシュします。
```
git push
```

これで、サブモジュールが最新バージョンに更新され、メインプロジェクトのサブモジュール参照も更新されました。メインプロジェクトとサブモジュールは別個の Git リポジトリであるため、これらの手順ではそれらを切り替える必要があることに注意してください。

3.5 サブモジュールの更新を同期する方法

サブモジュールのリモートリポジトリが更新された場合は、メインプロジェクトのサブモジュールのコンテンツを同期する必要があります。サブモジュールの更新を同期する手順は次のとおりです。

最新の変更をメインプロジェクトにプルする: まず、最新の変更をメインプロジェクトにプルしたことを確認します。
```
git pull
```
サブモジュールを初期化します (まだ初期化されていない場合): サブモジュールが初期化されていない場合は、次のコマンドを使用して初期化します。
```
git submodule init
```
サブモジュールのコンテンツを更新する: 次のコマンドを使用して、サブモジュールのコンテンツを更新します。
```
git submodule update
```
これにより、メインプロジェクトで参照される特定のコミットにサブモジュールが更新されます。

サブモジュール内にネストされたサブモジュールもある場合は、--recursiveオプションを使用して、すべてのサブモジュールとそのサブモジュールを同時に初期化および更新できます。
```
git submodule update --init --recursive
```
サブモジュールの最新の変更を取得する (オプション): メインプロジェクトによって参照される特定のコミットだけでなく、サブモジュールをリモートリポジトリの最新の変更に更新したい場合は、サブモジュールディレクトリで実行できますgit pull。
```
cd <path_to_submodule>
git pull
cd ..
```
この手順を実行する場合は、参照の不一致を避けるために、メインプロジェクト内のサブモジュール参照も最新の変更に更新されていることを確認する必要があることに注意してください。

上記の手順により、メインプロジェクトのサブモジュールの更新を同期できます。これにより、サブモジュールの内容がメインプロジェクトによって参照されるコミットと確実に一致します。

3.6 サブモジュールでの作業

サブモジュールで開発および変更を行う場合、サブモジュールを独立した Git リポジトリと考えることができます。サブモジュールで作業するための基本的な手順は次のとおりです。

サブモジュールのディレクトリに移動します。まず、サブモジュールのディレクトリを入力します。
```
cd <path_to_submodule>
```
サブモジュールから最新の変更をプルする: サブモジュールの最新バージョンで作業していることを確認するには、リモートリポジトリから最新の変更をプルします。
```
git fetch
git checkout <branch_name>
git pull
```
新しいブランチを作成する (オプション): 新しいブランチで作業する必要がある場合は、新しいブランチを作成できます。
```
git checkout -b <new_branch_name>
```
変更を行う: サブモジュールに必要な変更と修正を加えます。
変更をコミット: 変更をステージング領域に追加してコミットします。
```
git add .
git commit -m "Your commit message"
```
変更をプッシュ: 変更をリモートリポジトリにプッシュします。
```
git push
```
メインプロジェクトディレクトリに戻ります。サブモジュールへの変更が完了したら、メインプロジェクトディレクトリに戻ります。
```
cd ..
```
メインプロジェクトのサブモジュール参照を更新します。サブモジュールの変更をメインプロジェクトに追加し、更新された参照をコミットします。
```
git add <path_to_submodule>
git commit -m "Update submodule reference"
```
メインプロジェクトの変更をプッシュする: メインプロジェクトの変更をリモートリポジトリにプッシュします。
```
git push
```

これらの手順を実行すると、他のスタンドアロン Git リポジトリと同様に、サブモジュールで作業および開発を行うことができます。サブモジュールへの変更が完了したら、メインプロジェクト内のサブモジュール参照を適切に更新してコミットするようにしてください。

3.7 サブモジュールの削除

Git リポジトリからサブモジュールを削除する場合は、次の手順を実行する必要があります。

サブモジュールディレクトリの削除: サブモジュールディレクトリとその内容を削除します。
```
git rm --cached <path_to_submodule>
```
これにより、ステージング領域からサブモジュールが削除されますが、サブモジュールの物理ファイルは削除されません。
サブモジュールの物理ファイルを削除します: サブモジュールの物理ファイルとディレクトリを削除します:
```
rm -rf <path_to_submodule>
```
ファイルの変更.gitmodules:.gitmodulesファイルを編集して、サブモジュールに関連するエントリを削除します。これは次のようになります。
```
[submodule "path_to_submodule"]
    path = path_to_submodule
    url = https://github.com/user/repo.git
```
エントリ全体を削除し、ファイルを保存して閉じます。
変更をコミット: これらの変更をステージング領域に追加してコミットします。
```
git add .gitmodules
git commit -m "Remove submodule"
```
サブモジュール構成の削除:.git/configサブモジュール関連の構成をファイルから削除します。ファイルを編集し.git/config、次のようなサブモジュールに関連するセクションを見つけます。
```
[submodule "path_to_submodule"]
    url = https://github.com/user/repo.git
```
セクション全体を削除し、ファイルを保存して閉じます。
サブモジュールキャッシュのクリア: 次のコマンドを実行して、Git キャッシュからサブモジュール関連の情報を削除します。
```
git rm --cached <path_to_submodule>
```
変更をプッシュ: 変更をリモートリポジトリにプッシュします。
```
git push
```

これで、サブモジュールが Git リポジトリから完全に削除されました。これらの手順には複数のファイルの変更が含まれるため、問題が発生しないように注意する必要があることに注意してください。

4. gitリポジトリのバックアップ方法

災害復旧のために、多くの企業は git ウェアハウスをバックアップします。以下にいくつかの基本的な手順を示します。
ここに画像の説明を挿入

ssh のパスワード不要のログイン方法を設定します。

ssh-kengen –t rsa  # 以rsa算法生成密钥对
vim ~/.ssh/id_rsa.pub # 把id_rsa.pub的内容拷贝后放在git仓库的/root/.ssh/authorized_keys里
chmod 400 /root/.ssh/authorized_keys   # 在git服务器上设置文件的权限为400

次のスクリプトを記述します。 ssh プロトコルを使用してイメージをコピーします (git ウェアハウスには多くのブランチとタグの情報があるため、省略できませんgit clone)--mirror

giturl="[email protected]:/srv/"
# reslist=("nginx-docs.git")
reslist=$(ssh [email protected] "cd /srv ; ls")
for res in ${reslist[@]};
do
	cd ${res}
	#echo ssh://${giturl}${res}
	git clone --mirror ssh://${giturl}${res}
done

crontab を使用してタイミングタスクを追加します。

crontab –e   # 在定时任务中添加: 0 0 * * * sh /srv/backup_remote_git.sh，然后保存
systemctl restart cron  # 重启cron服务，如果在centos是systemctl restart crond