Git の使用法とスキル

1. Git の基本

1.1、バージョン管理

1.1.1. バージョン管理とは

バージョン管理は、ファイルの内容の特定のバージョンを後で参照できるように、ファイルへの変更を記録する方法です。

1.1.2. マニュアルバージョン管理の問題点

1. ドキュメントの数が多く、名前が不明瞭であるため、ドキュメントのバージョンが混乱します。
2. 文書を編集するたびにコピーする必要があり、不便です。
3. 複数の人が同じ文書を同時に編集すると、簡単に上書きされてしまいます。

1.2 Git とは

Git はバージョン管理制御システム (略称 VCS) であり、文書の状態を任意の時点で更新記録として保存し、任意の時点で更新記録を復元することもできます。

1.3. Git のインストール

公式 Web サイトからダウンロードできます - デフォルトでインストールできます - インストール後にマウスを右クリックします (デフォルトでは Git Bash Here がより一般的に使用されます)

• git --version // バージョンを表示

1.4、Git の基本的なワークフロー

1. gitwarehouse: 送信レコードを保存するために使用されます。
2. 一時保存領域: 変更されたファイルの一時的な保存領域。
3. 作業ディレクトリ: Git によって管理されるプロジェクト ディレクトリ (コードを記述する場所)

• プロセス: 作業ディレクトリ—>一時ストレージ領域 (git add '')—> Git ウェアハウス (git commit -m '')

1.5、Gitの使用

1.5.1、使用前のGit設定

git を使用する前に、自分が誰であるかを git に伝える必要があり、git リポジトリに送信するときにそれを使用する必要があります。

1. 送信者の名前を設定します: git config --global user.name '送信者の名前'
2. 送信者のメールボックスを構成します: git config --global user.email 'submitter's mailbox'
3. git 構成情報の表示: git config --list

• 注⚠️:
  1. 構成情報を変更したい場合は、上記のコマンドを繰り返してください。
  2. 構成は 1 回だけ実行する必要があります。
  3. .gitconfig 構成ファイルを使用して直接変更することもできます。

1.5.2 、送信手順

1. git init は git ウェアハウスを初期化します (.git フォルダーは現在のディレクトリに生成され、デフォルトでは非表示になります)。
2. git status ファイルのステータスを表示する
3. git add 'file list' 追跡ファイル (. または A はすべて追加を表し、一時記憶領域に追加します)

1、git add .:会监视工作区的状态树，使用它会把工作的所有变化提交到暂存区，包括文件内容修改（modified）以及新文件（new），但不包括被删除的文件。
2、git add -u:仅监控已经被add的文件（即track file），会将修改的文件提交到暂存区。add -u 不会提交新文件（untracked file）。（git add --update的缩写）
3、git add -A: 是上面两个功能的集合（git add --all的缩写）
总结：
git add -A: 提交所有的变化；
git add -u: 提交被修改（modified）和被删除（deleted）文件，不包括新文件（new）；
git add .: 提交新文件（new）和被修改（modified）文件，不包括被删除（deleted）文件。

4. git commit -m 'コミット情報' コードを git ウェアハウスに送信します(一時記憶領域内のコードをgit ウェアハウスに送信します。各送信には 1 つの関数のみが含まれることが望ましいです)。
5. git log コミットレコードの表示

1.5.3. 失効

• 作業ディレクトリ内のファイルを一時ストレージ領域のファイルで上書きします: git checkout 'ファイル名' (一時ストレージ内にあります)
• ステージング領域からファイルを削除します: git rm --cached 'file' (作業ディレクトリにはまだ存在します)
• git リポジトリで指定された更新レコードを復元し、一時記憶領域と作業ディレクトリを上書きします: git restart --hard commitID (後続のコミットは削除されます)

2. 高度な Git

2.1、分岐

理解を容易にするために、ブランチを現在の作業ディレクトリ内のコードのコピーとして一時的に考えることができます。ブランチを使用することで、開発の本線から切り離して、開発の本線に影響を与えないようにすることができます。

2.1.1、ブランチの細分化

1. マスターブランチ (master) : git リポジトリに初めて更新レコードが送信されたときに自動的に生成されるブランチ。
2. 開発ブランチ(develop) : 開発ブランチとしてmasterブランチをベースに作成されます。
3. 機能ブランチ（フィーチャー）：特定の機能を開発するためのブランチとして、開発ブランチをベースに作成されます。
4. バグ修正ブランチ、さまざまな依存バージョン ブランチのストレージなどもあります。

2.1.2、分岐コマンド

• git Branch // すべてのローカル ブランチを表示
• git Branch -r // すべてのリモート ブランチを表示します
• git Branch -a // すべてのローカルおよびリモート ブランチを表示します
• git Branch 'ブランチ名' // ブランチを作成します (どのブランチを操作するかは、どのブランチに基づいて新しいブランチを作成することになります)
• git checkout 'ブランチ名' // ブランチを切り替えます (ブランチを切り替える前に、現在のブランチの変更をgit に送信 (コミット) する必要があります。現在のブランチの作業領域を完全にクリーンな状態に保ちます。そうしないと、切り替え後のブランチにも変更が含まれます。ただし、 git stashコマンドを使用して一時的に保存)
• git checkout -b dev//開発ブランチ dev を作成し、このブランチに切り替えます
• git Push --set-upstream Origin Branchname // 既存のブランチと指定されたリモート ブランチ間の追跡関係を確立します
• git merge 'ソース ブランチはマージされたブランチ dev' // ブランチをマージします。たとえば、dev は master にマージされます (最初にマージするブランチ マスターに切り替える必要があります)
• git merge --abort はマージされたコードをキャンセルできます (コードをマージした後、競合が見つかりました。マージをキャンセルするには、次を使用します。) (このコマンドは、マージ後に競合が発生した場合にのみ使用されます。 git merge --abort はマージ プロセスを放棄し、マージ前の状態の再構築を試みます。ただし、マージ開始時にコミットされていないファイルがある場合、git merge --abort 場合によっては、マージ前の状態を再現することはできません。特に、これらのコミットされていないファイルがマージ プロセス中に変更される場合は、git merge を使用するときにコミットされていないファイルを使用することは非常に推奨されません。 git の使用を推奨します (stash コマンドは、コミットされていないファイルを一時的に保存します)。
• git Branch -d 'ブランチ名' // ブランチを削除します (ブランチはマージされた後にのみ削除できます- D は削除を強制します) (現在のブランチを現在のブランチの下で削除することはできません)

2.2. 変更を一時的に保存する

git では、ブランチ上のすべての変更を一時的に抽出して保存できるため、開発者はクリーンな作業コピーを取得して、一時的に他の作業に移ることができます。
利用シナリオ：ブランチ一時切替：

• 一時的な変更を保存します。git スタッシュ// 最初に一時記憶域に追加します (git add '')
• 一時的な変更を元に戻します。git スタッシュポップ
• 注 ⚠️: この操作はブランチから独立しています。つまり、git stash Pop は他のブランチでも実行できます。クリップボードに復元されると、そのファイルは存在しません

2.3. ブランチ上の単一ファイルをメインブランチにマージする

1. まずメイン ブランチに切り替えて、データの競合や損失を避けるためにブランチ上のすべてのデータを送信するように注意してください。

git checkeout master

2. マージするブランチとファイルを選択してください

git checkout --path '分支名称' '要合并的文件路径（文件在电脑中的全部路径）'

3. マージ完了、コミット

git add -A ''
git commit -m ''
git push
// 如果不想合并只是测试一定要回滚回来
git reset --hard origin/master 到上一个版本

2.4. リモート ウェアハウスから読み取り、ローカル ウェアハウスの内容を上書きする

git fetch コマンドとオプション
git pull = git fetch+ git merge

// 1、fetch仓库中所有的分支。同时也会下载指定远端的所有commits和文件
git fetch <remote>
// 2、与上面命令相同，但是会fetch指定分支
git fetch <remote> <branch>
// 3、fetch所有已经注册过的远端仓库的全部分支
git fetch --all
// 4、--dry-run选项会执行fetch命令的演练，执行该命令的输出与执行正常fetch命令一致，但不会在本地应用这些更改。
git fetch --dry-run
// 5、确定没有问题之后，使用git merge origin/main合并远端变更
git merge origin/main
// 到此为止，origin/main分支和本地main分支都指向同一次commit，本地分支与远端分支同步完成。

git はワークスペース、インデックス、リポジトリの 3 つの部分に分かれています。

1. ワークスペース: 作業領域を指します。
2. インデックス: ローカル キャッシュを参照し、ファイルの更新は追加操作を通じてインデックスに追加されます。
3. リポジトリ: ローカル git ウェアハウスを指します。このウェアハウス内のコードはコミットによって追加され、リモート ウェアハウスにプッシュされるコードもこの場所にあるコードです。

• そのため、 git fetch はリポジトリ部分のコードを更新しますが、ワークスペースとインデックスはまだ更新されていません。最新のコードを確認したい場合は、マスター (またはその他の対応する) ブランチで git merge コマンドを実行し、競合を解決して再送信するだけです。
• Git には、ワークスペースのコンテンツをリモート ウェアハウスのコンテンツで直接上書きできるショートカット コマンド git pull も用意されています。ただし、このコマンドはコミットされていない更新を上書きする可能性があるため、お勧めできません。

git fetch コマンドの概要

• 一般に、リモート ウェアハウスからコンテンツをダウンロードするための主なコマンドは git fetch です。
• git fetch は、ローカルとリモートの状態を更新し、一貫性があることを確認するために、git Remote、git Branch、git check、および git replace コマンドと組み合わせて使用​​されます。
• git fetch コマンドは、git コラボレーション ワークフローにおいて非常に重要な役割を果たします。
• git fetch コマンドは git pull コマンドと同様に動作しますが、より安全で非破壊的な更新同期コマンドとみなされます。

3. Git の実践的なコマンド

3.1、git stashとgit stash Pop

開発プロセス中にブランチを切り替えたりバグを一時的に変更したりする場合、このコマンドを使用して競合を防止したり、ワークスペースをクリーンアップしたりできます。

1. git stash は、
   現在のワークスペースのコンテンツをバックアップし、それをgit stackに保存し、最新のコミットから関連するコンテンツを読み取ります。
2. git スタッシュポップ
   • git stackから最新のstash のコンテンツを取得し、ワークスペースのコンテンツを復元します。取得後、スタック内の対応するスタッシュは削除されます。
   • stash は複数回存在する可能性があるため、git はスタック管理(先入れ先出し) を使用し、git stash list を使用してすべての stash を表示できます。
3. git stash list に
   は、git スタック内のすべてのワークスペースの内容のバックアップが表示されます。
   たとえば、git stash apply stash@{1}を使用すると、対応する stash を削除せずに、バージョン番号 stash@{1} のバックアップを取得できます。0が最新バージョンです。
4. git stash clear は
   git スタックをクリアします。
5. git stash show は
   、現在の最新の変更を表示します。主に、スタッシュを復元する前に変更されたコンテンツを確認できるためです。どのスタッシュ コンテンツを使用できるかを忘れた場合、デフォルトは最新です。対応するスタッシュを表示したい場合は、次を使用します: git隠し場所 $num を表示
6. git stash drop は、対応する stash を削除します。多くの場合、stash+stash Pop は通常、drop コマンドを使用しないため、このコマンドはあまり使用されません。キャッシュを一度にクリアする必要がある場合は、 git stash clear
   を実行できます。
7. git stash Pop がバックアップを取り出すときに競合が発生します。
   たとえば、index.vue ファイルがあり、コードの一部を変更します。git stash がそれを保存した後、リモート ウェアハウスから他の人のコードを git pull し続けます。他の人もindex.vueコードを変更する場合。git stash Pop を使用すると、変更が最新のプルされたファイルに基づいていないため、競合が発生します。そのため、git が判断するのは困難です。
   **解決策: **変更したファイルをバックアップし、プログラム ファイルに加えた変更を削除して再度プルし、バックアップしたファイルに置き換えてプッシュします。
   もう 1 つは、ローカルの変更を直接無視する、上記の git restart --hard です。。
8. git stash Pop と git stash apply の違い []
   git stash コマンドを使用すると、対応する情報が stash リストに生成されます。applyコマンドを使用して復元すると、stash リストの情報は引き続き保持され、pop コマンドで stash リストの情報が削除されます。

4. Git ファイルの 4 つの状態

ファイルがバージョン管理に追加されているかどうかに応じて、ファイルのステータスは次のように分類できます: Tracked (追跡済み)とUntracked (未追跡)。追跡済み (追跡済み) には、未変更、変更済み、ステージング済みの 3 つの作業状態が含まれます。

• Untracked : ファイルは git リポジトリに追加されておらず、バージョン管理にも参加していません。つまり、追跡されていない状態です。現時点では、git add を使用してファイルをステージング状態に変更できます。
• Unmodified : ファイルは git リポジトリに追加されましたが、変更されていません。これは、リポジトリ内のファイル スナップショットの内容がフォルダー内のファイル スナップショットの内容とまったく同じであることを意味します。Unmodified ファイルが変更されると Modified ファイルになり、git Remove を使用してリポジトリの外に移動すると Untracked ファイルになります。
• Modified : ファイルが変更されると、変更された状態になります。ファイルの状態は、stage コマンドを使用してステージングされた状態に入ることができます。
• staged : 一時保存状態 git commit を実行してライブラリへの変更を同期すると、ライブラリ内のファイルとローカルファイルの整合性が再び取れ、ファイルは Unmodified 状態になります。

5. Gitの基本共通コマンド（処理）

• gitクローン

  git clone url  克隆远程版本库 // 克隆远程版本库到本地
  

• git checkout -b dev

  git checkout -b dev  // 创建开发分支dev，并切换到该分支下
  

• git add

  git add .	// 添加当前目录的所有文件到暂存区git add [dir]	添加指定目录到暂存区，包括子目录git add [file1]	添加指定文件到暂存区
  

• gitコミット

  git commit -m [message]  // 提交暂存区到仓库区,message为说明信息git commit [file1] -m [message] 提交暂存区的指定文件到本地仓库git commit --amend -m [message] 使用一次新的commit，替代上一次提交
  

• git status
  コード ファイルを一時ストレージ領域に追加したか、ローカル ウェアハウスに送信したかを忘れた場合は、git status を使用して確認できます。

  git status  // 查看当前工作区暂存区变动git status -s  查看当前工作区暂存区变动，概要信息git status  --show-stash 查询工作区中是否有stash（暂存的文件）
  

• git log
  git log、このコマンドはより頻繁に使用する必要があります。これは、送信履歴/コミットログを表示することを意味します~

  git log  查看提交历史git log --oneline 以精简模式显示查看提交历史git log -p <file> 查看指定文件的提交历史git blame <file> 一列表方式查看指定文件的提交历史
  

• git diff

  git diff 显示暂存区和工作区的差异git diff filepath   filepath路径文件中，工作区与暂存区的比较差异git diff HEAD filepath 工作区与HEAD ( 当前工作分支)的比较差异git diff branchName filepath 当前分支的文件与branchName分支的文件的比较差异git diff commitId filepath 与某一次提交的比较差异
  

• git プル / git フェッチ

  git pull  拉取远程仓库所有分支更新并合并到本地分支。git pull origin master 将远程master分支合并到当前本地分支git pull origin master:master 将远程master分支合并到当前本地master分支，冒号后面表示本地分支
  git fetch --all  拉取所有远端的最新代码git fetch origin master 拉取远程最新master分支代码
  

  通常、git pull を使用して最新のコードをプルし、競合を確認して解決し、コードをリモート ウェアハウスにプッシュします。
  実際、一部のパートナーは、git pull と git fetch のどちらを使用するかについて少し混乱しているかもしれません。git pull = git fetch+ git merge。pullの場合はリモートのブランチをpullしてローカルのブランチにマージしますが、fetchの場合はリモートのブランチをpullするだけですが、どのようにマージするかは自分で選択できます。
• git Push
  git Push はローカル ブランチとタグをリモート ウェアハウスにプッシュでき、リモート ブランチを削除することもできます。

  git push origin master 将本地分支的更新全部推送到远程仓库master分支。
  git push origin -d <branchname> // 删除远程branchname分支
  git push --tags // 推送所有标签
  

6. Git の元に戻すとロールバック

Git のアンドゥとロールバックは日常業務で頻繁に使用されます。たとえば、変更したファイルを前のバージョンに取り消したい場合、または冗長な送信を取り消したい場合は、git の取り消しおよびロールバック操作を使用する必要があります。
以下の図に示すように、Git の各作業領域でコードを元に戻すまたはロールバックするにはどのようなコマンドが使用されますか:

Git の元に戻すおよびロールバックに関しては、一般に次のコア コマンドが使用されます。

• 1. git checkoutファイルがまだ作業領域にあり、一時記憶域に追加されていない
  場合は、 git checkout を使用して元に戻すことができますgit checkout [file] ファイルを破棄する file git checkout . すべてのファイルを破棄する
  
  

• 2、gitリセット

  1. git replace の機能は、HEAD の位置を変更することです。つまり、HEAD が指す位置を、以前に存在したバージョンに変更します。

  • git restart をより深く理解するために、Git のバージョン管理と HEAD の理解を確認してみましょう。

  • Git のすべてのコミットは、ブランチであるタイムラインに接続されます。現在のブランチがマスターの場合、通常、次のようにHEAD ポインターは現在のブランチを指します。
    

  • git reset を実行してバージョン 2 にロールバックすると、次のようにバージョン 3 が失われます。
    2. Git Reset のいくつかの使用モード:
    

  • コード git は一時記憶域に追加しますが、コミットはしません。
    gitリセットHEADファイルのステージング解除
    git チェックアウト ファイルの変更を元に戻す

  • コードは git commit されましたが、まだプッシュされていません:
    git log はロールバックする commit_id を取得します
    git replace --hard commit_id は過去に戻りたい、過去の commit_id に戻る

  • コードはリモート ウェアハウスにプッシュされました
    git log
    git restart --hard commit_id
    git Pushorigin HEAD --force

• 3. git revert
  と git restartの違いは、revert はロールバック先の履歴バージョンをコピーし、それを現在のブランチの前に追加することです。
  
  

• コードがリモートにプッシュされている場合は、 revert rollback :
  git log を実行して、コミットをロールバックするために必要なコミット ID を取得することも検討できます。(git log -n 3.-n 3 を追加すると、最後の 3 つのコミットのみが出力されます)
  git revert -n <commit_id> は指定されたバージョンを取り消し、取り消しもコミットとして保存されます。
  

7. Git の頭

HEAD は git バージョン管理のヘッド ノード、つまりブランチの最後の送信を表します。また、ファイルでもあり、通常はバージョン ライブラリの repository/.git/HEAD にあり、通常は ref: refs/heads/master が保存されます。名前は基本的に送信のハッシュ値を指し、通常は ce11d9be5cc7007995b607fb12285a43cd03154b のようになります。

• HEAD は ==.git/HEAD を参照します現在の作業ディレクトリが存在する特定の時刻を保存するファイルcommit==、開いているファイルの内容は次のとおりです: ref: refs/heads/master
  
  
  

• refs ディレクトリにはウェアハウスとタグが格納されており、各ウェアハウスにはブランチがあり、各タグにはタグがあり、タグは特定のコミットに対応します。

  // 存储本地local master分支的最新commit对象的SHA-1
  refs/heads/master
  // 存储远程仓库master分支的最新commit对象SHA-1
  refs/remotes/origin/master
  // 存储tag的SHA-1
  tags/xxx
  

• 頭現在のブランチによって参照されますポインタ、常にコミットを指します。デフォルトは最後のコミットです。これは、HEAD が次のコミットの親になることを意味します。通常、HEAD は最後のコミットのスナップショットと考えることができます。もちろん、HEADのポイントは、コミットを送信したり、ウェアハウスを切り替えたり、ブランチやバージョンをロールバックしたり、タグを切り替えたりするなど、変更することができます。

  • 例: master ブランチでは、最初は master ブランチは 1 行です。Git は、マスターを使用して最新の送信をポイントし、次に HEAD を使用してマスターをポイントして、現在のブランチと現在のブランチのサブミット ポイントを決定します。。
  • 新しい dev の作成など、新しいブランチを作成する場合、dev は現在の master ブランチの最新のコミットを指します。
  • dev ブランチを切り替えた後、 HEAD は現在のブランチ dev を指します。
  • dev で変更して送信します。ブランチ dev は現在のブランチの最新の送信を指し、master は master ブランチの最新の送信を指します。
  • master に切り替えると、dev で変更された master が変更されていないことがわかります (この時点では、HEAD はまだ master ブランチの最新のコミットを指しています)。
  • dev を master にマージした後、master は dev の最新のコミットを指します。そして、HEAD は現在のブランチ、マスターを指します。

• HEAD~ と HEAD^

  バージョンにロールバック: git restart --hard HEAD~

  • HEAD^ は、以前のバージョンが HEAD~1 と同じであることを示します
  • HEAD^^ は、以前のバージョン HEAD~2 (など) を意味します。
  • HEAD~100 は最新の 100 バージョンを意味します
  • HEAD~~、HEAD^^、HEAD~2、HEAD^2
    

       albert@home-pc MINGW64 /d/gitstart (dev1)
       $ git rev-parse --short HEAD~~
       dcdcb87
       albert@home-pc MINGW64 /d/gitstart (dev1)
       $ git rev-parse --short HEAD^^
        dcdcb87
       albert@home-pc MINGW64 /d/gitstart (dev1)
       $ git rev-parse --short HEAD~2
       dcdcb87
       albert@home-pc MINGW64 /d/gitstart (dev1)
       $ git rev-parse --short HEAD^2
       e330eac
    // 前三个表示方法是一样的，指向同一个提交记录，但是最后一个与他们不同，这时根据前面提到定义来看就行了，HEAD~~ 实际上是 HEAD~1~1的简写，而~ 后的数字就是指的后退的步数，所以 HEAD~~ 等价于 HEAD~2，属于一种合并计算。
    // HEAD^^ 是 HEAD^1^1 的简写，而 ^ 后面的数字表示后退一步到第几个父提交上，因为数字是1，所以 HEAD^^ 表示退一步到第一个父提交上，在退一步到第一个父提交上，这时与 HEAD~~ 的作用是相同的。
    // HEAD^2 就有些不同了，它表示后退一步到第二个父提交上，所以对照树形图是第二排的第二个节点。
    

  • HEAD~ と HEAD^ の両方の後に数字を続けることができます。数値が 1 より大きい場合、上記のように動作が異なります。HEAD~2 は 2 ステップ戻ることを表し、各ステップは最初の親提出に戻ります。HEAD^2 は 1 ステップ戻ります。このステップは 2 番目の親提出に戻ります。2 番目の親提出がない場合は、次のようになります。次のエラーが報告されました:
    致命的: 曖昧な引数 'HEAD^2': 不明なリビジョンまたはパスが作業ツリーにありません。
    パスとリビジョンを区切るには、次のように '–' を使用します:
    'git […] – […]'

8.Gitのラベルタグ

1. タグとは何ですか

   • タグは主にバージョン ライブラリのタグとして使用され、特定のバージョンを指します。専念のポインタ。
   • タグは主にリリースのバージョン管理に使用され、バージョンがリリースされた後、git に v.1.0.1、v.1.0.2 などのタグを付けることができます。
   • tagとbranch（ブランチ）は似ている部分もありますが、本質や分業は異なります。
   • タグはコミットに対応します。コミットはポイントであり、移動できません。
   • ブランチは、多くの点で結ばれた線である一連のコミットに対応し、HEAD ポインタがあり、HEAD ポインタによって移動できます。
   • したがって、この 2 つの違いによって使用方法が決まります。コードを変更するにはブランチを使用し、変更せずに表示するにはタグを使用します。
   • タグとブランチの相互利用は、v1.0 v2.0 v3.0 の 3 つのバージョンがリリースされているなど、非常に便利な効果をもたらすことがありますが、このとき、既存のコードを変更せずに、新しい機能を追加することをふと思いつきました。 v2.0 をベースとして、v4.0 としてリリースされました。v2.0 コードをブランチとしてチェックアウトし、次に開発ブランチとしてチェックアウトできます。

2. タグの簡単な使い方
   1.タグを作成します。

   • タグの作成はローカル ブランチのコミットに基づいており、ブランチのプッシュとは異なります。つまり、ブランチはリモートにプッシュされましたが、タグはまだプッシュされていません。タグをリモートにプッシュする場合ブランチでは、タグのプッシュコマンドを実行する必要があります。
   • git tag tagName // ローカルタグを作成する
   • git Pushorigin tagName //リモート ウェアハウスにプッシュする
   • git Push Origin --tags // 未プッシュのローカル タグが多数ある場合、それらをすべて一度にプッシュしたい場合
   • 上記はローカルの現在のブランチの最後のコミットに基づいて作成されたタグですが、最後のコミットを使用したくないが、特定のコミットのみをタグとして使用したい場合は、次の条件を満たす限り可能です。コミットのIDはわかっています。
   • git log --pretty=oneline //現在のブランチのコミット履歴を表示します。これにはコミット ID が含まれます
   • git tag -a tagName commitId // 特定のコミットをタグとして使用します

   2.ラベルを確認します。

   • git show tagName // ローカルタグの詳細を表示する
   • git tag または git tag -l // すべてのローカルタグを表示
   • git ls-remote --tagsorigin // すべてのリモート タグを表示

   3.ラベルを削除します。

   • git tag -d tagName // ローカルタグを削除
   • git Pushorigin :refs/tags/tagName // リモートタグを削除

        git tag -d 12345    #删除本地记录
        git push origin :refs/tags/12345    #删除远程记录
     

   • git Push Origin tagName // ローカル タグをリモート エンドにプッシュします

   4.ラベルを確認してください。

   • git checkout -b BranchName tagName
     タグ自体がコミットを指しているため、コミット ID に従ってブランチをチェックアウトすることと同じです。
   • ただし、特別に説明する必要があるのは、コード ブランチをチェックアウトするためにタグを変更する場合、ブランチ内のコードは変更されていても、タグでマークされたコミットは依然として同じであり、タグ付けされたコードは変更されないということです。これには特別な注意が必要です。

   5.その他

   • コマンド git tag -a tagname -m "XXX..." でタグ情報を指定できます。
   • コマンド git tag -a v0.1.0 -m "release 0.1.0 version" は、アノテーション付きタグを作成します。
   • コマンド git checkout [tagname] はタグを切り替えます。

9. Git その他

• git reflog // 現在のブランチの最後のいくつかのコミットを表示します
• gitblame filepath // gitblameは変更履歴とファイルを変更した人を記録し、責任を確認できます
• git Remote // 関連付けられたリモート ウェアハウスの名前を表示します

    git remote // 查看关联的远程仓库的名称
    git remote add url // 添加一个远程仓库
    git remote show [remote]  // 显示某个远程仓库的信息。
  

• git rebase // rebase (rebase とも呼ばれる) は、マージのもう 1 つのオプションです。
  
  リベースの利点は次のとおりです。より洗練された送信ツリーが得られ、各送信を直線的に確認でき、追加の送信ノードがありません。よりエレガントになりたいという理由だけで、一部のパートナーが git pull --rebase というコマンドを使用してコードをプルしているのを何度も見かけます。

9.1、git pull と git fetch の違い

• git プル
  最新のリモート送信を直接取得し、直接プルしてローカルの作業ディレクトリにマージします。慎重に確認しないと、競合が発生する可能性があります。
• git fetch
  git fetch は、まずローカル ウェアハウスとリモート ウェアハウスの違いを確認し、ローカル ウェアハウスに存在しないものを確認してから、これらの変更のコミットをローカルにプルします。
  これは、ローカル作業ディレクトリではなく、ローカル ウェアハウスにリモート送信をプルします。これらの新しいデータは、それ自体で現在の作業ディレクトリにマージされません。これらの変更を現在の作業ディレクトリにマージするには、引き続き git merge を実行する必要があります。。

git pull = git fetch + git merge。対照的に、git fetch はリモート リポジトリからすべてのコミットを取得しますが、ローカル ファイルには変更を加えないため、より安全なオプションです。