まだ Git を使ったことがありませんか?今すぐ手配してください！

この記事は、Git チュートリアル というコラムで、Git の操作方法をとても詳しく紹介しています。以下では、Git の使い方を説明します。Git を必要とする友人の役に立てば幸いです。

まえがき

暗く風の強い夜、ガールフレンドが悲しそうな顔をして突然、「Git が理解できない」と言いました。より良い経験を? 言うには遅すぎましたが、言うのは早かったです。何も言わずに、すぐに書き続けました...

通常のコーディング プロセスでは、まだ何かを行う必要があります。 . Git を操作する能力。しかし、ニーズを満たすためにどの Git コマンドを使用すればよいのか突然思い出せない場合がまだいくつかあります。そのときは、Google/Baidu を開いてさまざまに検索する必要があります。これで何度も時間を無駄にするのではなく、繰り返し作業を行う場合は、よく使用されるコマンドのゲームプレイを研究することをお勧めします。この記事では、これらの一般的に使用される Git システムとコマンドのアプリケーション シナリオと一般的な使用法を紹介する一連の事例も提供します。

もちろん、Git コマンドの使用方法を知ることに加えて、私たちが毎日操作するコマンドをより明確に理解できるように、Git のアーキテクチャ全体がどのようなものであるかを理解する必要もあります。 。

不適切な表現があった場合は、修正していただきありがとうございます。

Git システムの紹介

まずはイメージから始めて、結論は推測に依存します。

Git エリアの理解

• リモート ウェアハウス エリア : これはコード送信の最終目的地であり、何もありません。言う 。
• リモート ブランチのローカル コピー: これは実際には、主にリモート ウェアハウスの各ブランチのデータのローカル コピーを保存します。Git プロジェクトの下にある .git ファイルを開くことができます。 /remotes 内の refs は主にリモートウェアハウスのブランチ情報が格納されており、通常プッシュ、プル、フェッチを実行するとここに更新されます。
• ローカル ブランチ: これは私たちがよく扱う領域です。コミットを実行した後、基本的にこの領域に送信することになります。.git ディレクトリの refs/ を確認できます。このディレクトリには、ローカル支店コード情報が含まれています。
• ステージング領域: この領域は、git add を実行するたびに保存される領域です。ローカル ウェアハウスでキャッシュを作成するために使用されます。また、基礎となる設計でもあります。これは比較的重要な領域でもあり、Git が diff を実行する際の検索パフォーマンスを向上させるのに役立ちます。
• ワークスペース: これは通常、vscode によって開かれたプロジェクトなどのコードを作成する場所であり、コードを編集できます。

stash

さらに、ローカル git ストレージ領域という特別な領域があります。これは何に使用されますか?一般的に、これは特定のシナリオで使用される可能性があります。ローカルでコードを変更することもありますが、突然誰かが別のブランチについて質問しにやって来ます。同時に、ある機能を実装しているのですが、それは半分実装されています。 Git ウェアハウスに送信したくない場合は、git stash save "temporarily save" の使用を検討してください。この時点で、このストレージ領域に保存されます。他のブランチに移動して、作業が終わったら戻ってきて、その後は git stash Pop で大丈夫です。

しかし、作者はこの機能の使用をまだ推奨していません。ある日、一度切り替えてからまた切り替え、このストレージを忘れて別のことを書くと、その時点で騙されてしまうからです。泣く。もちろん、この機能は依然として非常に便利ですが、使用には注意が必要です。

Git の簡単なワークフローの理解

日常業務において、Git を使用する頻繁な対話のプロセスは、大まかに次のとおりです (仕様が異なると多少の違いはありますが、大きな違いはありません)違いは大きくありません):

1. 新しい要件が発生すると、開発のためにマスターから新しい機能ブランチをチェックアウトします。
2. 特定の関数ポイントを開発した後、git add を実行してコードをステージング領域に送信します。
3. 実行git commit コードをローカル ウェアハウスに送信します
4. 実行git Push コードをリモート ブランチに送信します
5. すべての要件を開発した後、dev という名前のブランチなどの特別なテスト ブランチをセットアップし、コードをこのテスト ブランチにマージし、テスト用にテスト環境をリリースします。
6. テストが完了したら、コードをマージする必要があります。この時点で、CR プロセスを通じてコードをマスター ブランチにマージするためのマージ リクエストを開始できます。
7. MR を送信するプロセスでは、通常、マスター ブランチのコードを現在マージする必要があるブランチにマージし、送信して競合を解決する必要があります。

上記のプロセスは、一般的な Git フロー プロセスを大まかにまとめたものです。企業によっては独自の仕様を設計している可能性があるため、ここではあまり詳しく説明しません。

コマンドの概要

• git stash
• git clone
• git init
• #git リモート
• git ブランチ
• git チェックアウト
• git add
• git commit
• git rm
• git Push
#git pull
git fetch
• ##git merge
• #git log
• git リセット
• git reflog
• git revert
• git Cherry-pick
• git tag
• ##git rebase
##一目見たとき私は目がくらんでしまい、その場で諦めて可視化ツールを使うことにしました。パニックにならないでください。著者が説明します。
• コマンド分析
一般的に、Git を使用してリソース ファイルをローカルで管理したい場合は、まずウェアハウスが必要です。最も一般的に使用される方法は、最初に Gitlab/Github にアクセスしてウェアハウスを作成し、それをローカル エリアにプルすることですが、このときは clone コマンドを使用できます。

git stash (簡単に説明するために一時的に挿入)

上記のこのコマンドの使用法に関する予備的な紹介もあります。これは、保存したくないコード変更を一時的に保存するために使用されます。一般的に使用されるコマンドは次のとおりです:

git stash save 'xxx'

: 変更を保存

git stash list
• : 表示ストレージ領域内のすべてのコミットのリスト
git stash Pop
• : 最新のストレージ領域のコード送信をポップアップして適用します
git stash Drop stash @{n}
• : 特定のストレージ レコードを削除します
git stash clear
• : すべてのスタッシュ情報をクリアします
データは refs/ に保存されますウェアハウスの .git ファイルの下に隠します。
• git clone
最も基本的で一般的に使用される使用法は、直接使用することです

#git clone xxx.git

このようにして、倉庫コードをローカルエリアに簡単に引き込むことができますが、これを知っているだけでは十分ではないようです。通常、パラメーターを指定せずに直接クローンを作成すると、デフォルトでマスター ブランチに残りますが、ローカル エリアにプルした後に指定されたブランチに自動的に切り替える方法など、他の要件が必要になる場合もあります。

• git clone xxx.git -b Branch1

ウェアハウスを作成した後は、必ずしも master ブランチで作業できるわけではありません。通常、コードを変更するために新しいブランチを開いて、最終的に完成した後にそれをマスターにマージする必要はありません。その後、以下で紹介する git ブランチ コマンドを使用する必要があります。ただし、具体的なブランチの操作について説明する前に、ローカルウェアハウスを初期化するプロセスがあります。

• git initウェアハウスをリモートで構築することに加えて、操作のために Git ウェアハウスをローカルで初期化することもできます。このとき、git init を直接簡単に使用できます。現在のディレクトリに対する変更をバージョン管理ライブラリに組み込むことができます。

ただし、ローカルの init ウェアハウスはリモートのウェアハウスと対話できないため、github/gitlab にアクセスしてリモート ウェアハウスを作成し、それを関連付ける必要があります。これが

git リモート

指示。

git remote

は、リモート ウェアハウスとのリレーションシップ バインディング処理やその他の操作を実行するために使用されます。

git remote add

: リモート リポジトリの関連付けを追加します

git Remote rm

: リモート リポジトリの関連付けを削除します
• たとえば、初期化されたローカル倉庫と作成されたリモートの空の倉庫がある場合、次の操作を実行してそれらを関連付けることができます。
  1. git Remote addorigin xxx.gitまずローカル ウェアハウスに追加します
  2. git Push -u Origin master: のマスター ブランチを示します。現在のウェアハウス これをリモート ウェアハウスのマスター ブランチに関連付けると、後でプッシュまたはプル操作を非常に便利に実行できます。

  git ブランチ

  プロジェクトを取得した後、まず現在のウェアハウスに現在どのようなブランチがあるかを確認する必要があります。後から新しいブランチを作成して、次のような問題を見つけないようにしてください。名前が重複している場合は、この時点で git Branch を使用して関連するブランチを確認できます。

  • git ブランチ: すべてのローカル ブランチ情報を表示します。
  • git ブランチ -r: リモート ウェアハウスのすべてのブランチを表示します
  • git Branch -a: ローカルおよびリモート ウェアハウスのすべてのブランチを表示します

  一般的に、ブランチが多すぎる場合は、ビジュアル ツールを使用してブランチを表示することをお勧めします。 vscode やソース ツリー、その他のソフトウェアなどの情報。

  もちろんIDEAもご利用いただけます。

  git checkout

  現在のブランチに基づいて新しいブランチを作成し、それに切り替える場合は、次のコマンドを使用できます。

  • 指定された新しいブランチを作成して切り替えます: git checkout -b Branch1
  ##git add
  現在、特定のブランチを作成しています。ブランチ コードを変更して送信する場合、最初に行う必要があるステップは、

  git add

  • git add [file1] [file2 ]# を実行することです。 ##: 一時記憶領域に 1 つ以上のファイルを追加します。
  通常、これを使用する場合、より一般的に使用されるファイルは次のとおりです。
  ## git add .
  : 現在のディレクトリにあるすべてのファイルの変更を一時記憶領域に追加します
  • git add -A
  : 現在のウェアハウスにあるすべてのファイルの変更を一時記憶領域に追加しますarea
  作者にとって、ほとんどの場合、すべての変更を一時記憶領域に追加する必要があるため、git add -A コマンドが最もよく使用されます。あなたはそれを忘れています。

  git commit

  ファイルがステージング領域に追加されたら、次のステップを実行できます。
  git commit [file1] ... -m [メッセージ]
  : ステージング領域の内容をローカル git バージョン リポジトリに送信します
  • -m現在送信されている情報を表します
    -a git 管理に含まれているファイル (以前にファイルを送信したことがある) の場合、このコマンドは上記の
    • git add - A## の実行を支援するのと同等です。 #、再度追加する必要はありません。git で管理されていないファイル (つまり、新しく追加されたファイル) については、正しくコミットする前に
    git add -A
    • を実行する必要があります。 . ローカル git リポジトリ。
    通常、より頻繁に使用するのは、現在のコミット情報を設定する
    git commit -m 'feat: do something'
  です。もちろん、
  git add

  と git commit を分離する必要がない場合は、git commit -am を選択できます。便利で早いです。 git rmこれは実際に非常に便利です。たとえば、プロジェクトには .env というファイルがあります。このファイルはプライベートなのでリモートに送信できませんが、誤って送信してしまいました。ローカル ウェアハウスに送信する場合、今回はこのファイルを .gitignore ファイルに追加します。これは、送信が git によって無視される必要があることを示します。ただし、このファイルはすでにローカル ウェアハウスに送信されているため、ローカル ウェアハウスから削除しないと意味がありません。まず git ウェアハウス。

  右クリックして削除しても、このファイルのレコードはリモート ウェアハウスに保存されたままで、他の人があなたの情報を閲覧できるため、最初にこのファイルを git ウェアハウスから削除する必要があります。

  git rm .env
  : このコマンドの実行後、.env ファイルが git ウェアハウスから削除されたことを意味します。すべての将来の .env ファイルの変更がリモート ウェアハウスに送信されることを心配する必要はありません。

  • git rm -r dist
  : ディレクトリを削除したい場合は、-r パラメータを追加するだけです。

  • git Push

  次に、新しく作成したブランチをリモート エンドにプッシュします。一般的に、git Push を使用する必要があるかもしれませんが、これは新しいブランチであり、リモート ウェアハウスとはまったく接続されていないため、それらを接続するためにいくつかのパラメーターを追加する必要があります:
  ブランチをプッシュして関係を確立します:

  git Push -- set-上流起点ブランチ 1

  • 作業が完了したら、リモート ウェアハウスに行って確認すると、作成した新しいブランチがプッシュアップされていることがわかります。次に、友人の中には、リモート倉庫にすでにこのブランチ名が付いている場合はどうなるのか、と尋ねる人もいるかもしれません。
  ここには 2 つのタイプがあります:
  1. 1 つは、ローカル コードとリモート コードの間に競合がなく、ローカルに新しい送信がある場合でも、上記のコマンドを実行できます。これにより、現在のローカル ブランチがリモート ブランチに直接マージされます。接続して、同時に変更を送信します。
  2. もう 1 つは、ローカル ブランチとリモート ブランチの間に競合がある場合です。このとき、上記のコマンドを実行すると、競合プロンプトが表示されます。その後、そのコードをプルダウンする必要があります。現在のリモート ブランチを実行して解決します。競合がある場合は、git pull コマンドを使用する必要があります。

  git pull

  通常、現在のブランチがリモート ブランチとの接続を確立している場合、リモート ブランチをマージしたい場合は、 を実行するだけで済みます。 git pull は問題なく、他のパラメータは必要ありません。ただし、上記の git Push と競合する場合は、接続を確立する前に、マージのためにコードのどのブランチをプルダウンする必要があるかを指定する必要があります。

  • 指定されたリモート ブランチをプルし、ローカルの現在のブランチにマージします。 git pullorigin Branch1

  ここでのオリジンは、リモート倉庫 必要に応じて名前を変更できますが、通常は原点が使用されます。

  上記の競合の問題に戻ると、git pull を直接使用して、現在のローカル ブランチとマージするリモート ブランチを指定し、ローカルで競合を解決して、変更を送信します。実行 git Push --set-upstream Origin Branch1 コマンドが完了しました。

  git fetch

  上記の git pull コマンドを理解すると、このコマンドは実際に簡単に理解できるようになります。ウェアハウス内の対応するブランチへのはローカルでのみプルされ、自分のワークスペース (現在コードを変更しているワークスペース) に自動的にマージされることは望ましくありません。コードの特定の部分を書き終えた後でマージすることを検討します。最初に git fetch を使用できます。

  フェッチが完了した後、現在作業中の変更をローカル ウェアハウスに送信し、その変更をリモート ブランチでマージしたいと考えています。このとき、git mergeorigin/[ を実行します。現在のブランチ名] (デフォルトでは、通常、リモート ブランチ プレフィックスを表すためにorigin を使用します)。

  git merge

  指定されたブランチ コードを現在のブランチにマージします。一般的に、私たちがより頻繁に使用するシナリオは、リモート ウェアハウスのマスター ブランチが変更され、現時点では MR について言及する準備をしているため、最初にマスター コードをマージし、競合がある場合は解決する必要があります。

  1. master ブランチに切り替え、git pull して最新のコードをプル
  2. 開発ブランチに戻り、git merge master を実行します。マスターコードをマージするには

  同様に、上で紹介した git mergeorigin/xxx も同じように使用されます。

  git log

  名前の通り、ログという意味ですが、このコマンドを実行すると、現在のブランチのコミットIDや送信時刻の説明などの送信レコード情報が確認できます。これはおそらく次のようになります:

  commit e55c4d273141edff401cbc6642fe21e14681c258 (HEAD -> branch1, origin/branch1)
  Author: 陌小路 <44311619+STDSuperman@users.noreply.github.com>
  Date:   Mon Aug 1 23:16:11 2022 +0800
  
      Initial commit复制代码

  この時点で、一部の読者は、これは何に使用されるのかと尋ねるかもしれません。簡単な使用法は、誰が何を送信したかを確認することです。より重要な使用法は、実行することです。コードのバージョン管理、ロールバック、またはその他の興味深い操作については、作成者が説明します。

  gitリセット

  • gitリセット [--soft | --mixed | --hard] [HEAD]

  HEADについて:

  • HEAD は現在のバージョンを表します
  • HEAD^ 前のバージョン
  • HEAD^^ 前のバージョン
  • HEAD^^^ 前のバージョン
  • HEAD~n n バージョンを取り消します。これもまた便利です。

  パラメータ分析

  次の分析は、次のパラメータ HEAD^ に基づいています。つまり、git replace HEAD^ です。 。

  • --soft: ステージング領域とワークスペースを変更せずに、送信された最新バージョンをリセットします。
  • --mixed: デフォルトのパラメータ。最後の送信 (コミット) と一致するようにステージング領域内のファイルをリセットするために使用され、ワー​​クスペース ファイルの内容は変更されません。
  • --hard: すべての提出物を以前のバージョンにリセットし、ワークスペースを変更します。これにより、完全に以前の提出物バージョンに戻り、現在の提出物はコード内に表示されなくなります。つまり、ワークスペースの変更も強制終了されます。

  長く話していると、なかなか理解できないようです。理解するための例を挙げてみましょう:

  例:

  1. README ファイルを変更しました。ワークスペースで変更が発生しましたが、現時点ではステージング領域に送信されていません。vscode では、ワークスペース変更のマークとして表示されます。
  2. Then git add を実行します。この時点でステージング領域を確認すると、変更が送信され、vscode によってステージング領域
  ## に送信されたものとしてマークされていることがわかります。 # そして
  3. git commit を実行すると、この時点で送信が完了しました
  次にこの送信を取り消したいと思います。上記の 3 つのパラメータによって反映されるパフォーマンスは次のようになりますこれ：＃＃＃
  • --soft：我们对 README 的更改状态现在变成已被提交至暂存区，也就是上面 2 的步骤。
  • --mixed： 我们对 README 的更改变成还未被提交至暂存区，也就是上面 1 的步骤。
  • --hard：我们对 README 的所有更改全没了，git log 中也找不到我们对 README 刚刚那次修改的痕迹。

  默认情况下我们不加参数，就是 --mixed，也就是重置暂存区的文件到上一次提交的版本，文件内容不动。一般会在什么时候用到呢？

  场景一（撤销 git add）

  可能大部分情况下，比如 vscode 其实大家更习惯于使用可视化的撤销能力，但是呢，这里我们其实也可以稍微了解下这其中的奥秘，其实也很简单：

  • 方式一：git reset
  • 方式二：git reset HEAD

  其实一二都是一样，如果 reset 后面不跟东西就是默认 HEAD。

  场景二 (撤销 git commit)

  当你某个改动提交到本地仓库之后，也就是 commit 之后，这个时候你想撤回来，再改点其他的，那么就可以直接使用 git reset HEAD^。这个时候你会惊奇的发现，你上一版的代码改动，全部变成了未被提交到暂存区的状态，这个时候你再改改代码，然后再提交到暂存区，然后一起再 commit 就可满足你的需求了。

  除了这种基础用法，我们还可以配合其他命令操作一下。

  场景三

  某一天你老板跟你说，昨天新加的功能不要了，给我切回之前的版本看看效果，那么这个时候，你可能就需要将工作区的代码回滚到上一个 commit 版本了，操作也十分简单：

  • git log 查看上一个 commit 记录，并复制 commitId
  • git reset --hard commitId 直接回滚。

  场景四

  如果某一个你开发需求正开心呢，突然发现，自己以前改的某个东西怎么不见了，你想起来好像是某次合并，没注意被其他提交冲掉了，你心一想，完了，写了那么多，怎么办？很简单，回到有这份代码的那个版本就好了（前提你提交过到本地仓库）。

  假设我们有这么两个提交记录，我们需要下面那个 365 开头 commitId 的代码：

  commit e62b559633387ab3a5324ead416f09bf347d8e4a (HEAD -> master)
  Author: xiaohang.lin <xiaohang.lin@alibaba-inc.com>
  Date:   Sun Aug 14 18:08:56 2022 +0800
  
      merge
  
  commit 36577ea21d79350845f104eee8ae3e740f19e038 (origin/master, origin/HEAD)
  Author: 陌小路 <44311619+STDSuperman@users.noreply.github.com>
  Date:   Sun Aug 14 15:57:34 2022 +0800
  
      Update README.md复制代码

  1. 抢救第一步 git log 找到有你这个代码的那个 commitId（也就是 36577ea21d79350845f104eee8ae3e740f19e038）
  2. 抢救第二步 git reset --hard commitId
  3. 第三步：Ctrl + c 你的目标代码

  这个时候你想把复制好的代码写回去，该怎么办呢，你可能会再 git log 看一下我们 reset 之前的 commitId，你会发现，完了，之前的 commitId 都没了，只有这个 365 了。

  commit 36577ea21d79350845f104eee8ae3e740f19e038 (origin/master, origin/HEAD)
  Author: 陌小路 <44311619+STDSuperman@users.noreply.github.com>
  Date:   Sun Aug 14 15:57:34 2022 +0800
  
      Update README.md复制代码

  不要慌，请记住一句话，只要你不删你本地的 .git 仓库，你都能找回以前所有的提交。

  git log 看不到的话，我们就可以祭出我们的绝招了：git reflog

  36577ea (HEAD -> master, origin/master, origin/HEAD) HEAD@{0}: reset: moving to 36577ea21d79350845f104eee8ae3e740f19e038
  e62b559 HEAD@{1}: reset: moving to e62b559633387ab3a5324ead416f09bf347d8e4a复制代码

  这里我们可以看到两行记录，一个是我们执行 reset 到 365 的记录，另一条不知道是啥，不重要，我们想回到我们刚刚 reset 之前的状态也很简单，直接复制它上一次的变动也就是这个 e62b559，然后执行 git reset --hard e62b559，然后你会惊奇的发现，你之前的代码又回来了。

  接下来把你以前版本的代码，再 Ctrl + v 放进来就完成了。

  git reflog

  介绍：用来查看你的所有操作记录。

  既然 git log 看不到我之前 commitId 了，那么就回到 reset 之前的状态吧！

  git revert

  当然了，如果是针对 master 的操作，为了安全起见，一般还是建议使用 revert 命令，他也能实现和 reset 一样的效果，只不过区别来说，reset 是向后的，而 revert 是向前的，怎么理解呢？简单来说，把这个过程当做一次时光穿梭，reset 表示你犯了一个错，他会带你回到没有犯错之前，而 revert 会给你一个弥补方案，采用这个方案之后让你得到的结果和没犯错之前一样。

  举个栗子： 假设你改了 README 的描述，新增了一行文字，提交上去了，过一会你觉得这个写了有问题，想要撤销一下，但是又不想之前那个提交消失在当前历史当中，那么你就可以选择使用 git revert [commitId]，那么它就会产生一次新的提交，提交的内容就是帮你删掉你上面新增的内容，相当于是一个互补的操作。

  PS D:\Code\other\git-practice> git revert 3b18a20ad39eea5264b52f0878efcb4f836931ce
  On branch branch2
  Your branch is ahead of 'origin/branch2' by 1 commit.
    (use "git push" to publish your local commits)

  这个时候，它会提示你可以把新的改动 push 上去了。

  其实你如果在 gitlab 进行 mr 之后，想要回滚这个 mr，一般它会给你一个 revert 的按钮选项，让你进行更安全的回滚操作。

  git cherry-pick

  其实对于我们工作中大部分场景下应该用不到这个功能，但是呢有的时候这个命令又能挽救你于水火之间，那就是当某个倒霉蛋忘记切分支，然后在 master 分支上改了代码，并且提交到了本地仓库中，这个时候使用git cherry-pick简直就是神器了。

  • git cherry-pick：将执行分支的指定提交合并到当前分支。

  一听介绍就来精神了，雀氏有点东西，比如我在 master 分支提交了某个需求的代码，同时还没提交到远程分支，那么你就可以先 git log 查看一下当前的提交，找到 master 分支正常提交之后的所有 commitId，然后复制出来，然后再切到你建好的开发分支，接着执行 git cherry-pick master commitId1 commitId2 commitId4。

  完事之后记得清理一下作案现场，把你的 master 分支代码恢复到正常的提交上去。

  git tag

  顾名思义，也就是打标签的意思。一般可能会在你发布了某个版本，需要给当前版本打个标签，你可以翻阅 vite 的官方 git 仓库，查看它的 tag 信息，它这里就标注了各个版本发布时候的 tag 标签。

  它有两种标签形式，一种是轻量标签，另一种是附注标签。

  轻量标签

  • 创建方式：git tag v1.0.0

  它有点像是对某个提交的引用，从表现上来看，它又有点像基于当前分支提交给你创建了一个不可变的分支，它是支持你直接 checkout 到这个分支上去，但是它和普通分支还是有着本质的区别的，如果你切换到了这个 tag "分支"，你去修改代码同时产生了一次提交，亦或者是 reset 版本，这对于该 tag 本身不会有任何影响，而是为你生成了一个独立的提交，但是却在你的分支历史中是找不到的，你只能通过 commitId 来切换到本次提交，看图：

  

  那如果你从其他分支通过 commitId 切换到这个改动上，它会提示你以下内容：

  Note: switching to 'be276009'.
  
  changes and commit them, and you can discard any commits you make in this
  state without impacting any branches by switching back to a branch.
  
  If you want to create a new branch to retain commits you create, you may
  do so (now or later) by using -c with the switch command. Example:
  
    git switch -c <new-branch-name>
  
  Or undo this operation with:
  
    git switch -

  大致意思就是你可以选择丢弃或者保留当前更改，如果需要保留的话直接使用下面的 git switch 命令创建一个新分支即可。

  附注标签

  • 创建方式：git tag -a v1.0.1 -m "发布正式版 1.0.1"

  引用官方文档的描述：

  而附注标签是存储在 Git 数据库中的一个完整对象， 它们是可以被校验的，其中包含打标签者的名字、电子邮件地址、日期时间， 此外还有一个标签信息，并且可以使用 GNU Privacy Guard （GPG）签名并验证。

  从概念上看，轻量标签更像是一个临时的标签，而附注标签更加正式一点，能够保留更多的信息。它创建的方式和轻量标签区别主要是 -a 和 -m 参数，如果你的 -m 参数不传，那么编辑器会让你手动填写。

  对比标签信息

  打完标签之后，我们可以使用 git show 命令来看看这两种标签最终体现的信息有哪些。

  轻量标签

  commit dcbd335be87f51eaa0cc1852400e64e9f46e84d8 (HEAD -> test-branch1, tag: v1.0.2, tag: v1.0.1)
  Author: STDSuperman <2750556766@qq.com>
  Date:   Tue Aug 16 22:54:36 2022 +0800
  
      xx
  
  diff --git a/README.md b/README.md
  index 715766a..b4cdea6 100644
  --- a/README.md
  +++ b/README.md
  @@ -1 +1,3 @@-# git-practice\ No newline at end of file
  +# git-practice
  +
  +test tag

  附注标签

  tag v1.0.1
  Tagger: STDSuperman <2750556766@qq.com>
  Date:   Tue Aug 16 22:58:27 2022 +0800
  
  发布正式版 1.0.0
  
  commit dcbd335be87f51eaa0cc1852400e64e9f46e84d8 (HEAD -> test-branch1, tag: v1.0.1)
  Author: STDSuperman <2750556766@qq.com>
  Date:   Tue Aug 16 22:54:36 2022 +0800
  
      xx
  
  diff --git a/README.md b/README.md
  index 715766a..b4cdea6 100644
  --- a/README.md
  +++ b/README.md

  从信息丰富度上来说，附注标签能保留的信息会更多。

  推送标签

  • git push origin tagName

  $> git push origin v1.0.1Enumerating objects: 6, done.
  Counting objects: 100% (6/6), done.
  Delta compression using up to 12 threads
  Compressing objects: 100% (3/3), done.
  Writing objects: 100% (4/4), 448 bytes | 448.00 KiB/s, done.
  Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
  To github.com:STDSuperman/git-practice.git
   * [new tag]         v1.0.1 -> v1.0.1

  当然，附注标签和轻量标签都是可以被推送到远端的。

  其他命令

  • 查看标签：git tag
  • 筛选标签：git tag -l v1.0.1
  • 删除标签：git tag -d v1.0.1
  • 删除远程标签：git push origin --delete v1.0.2
    • 另一种删除远程方式（表示将“:”前面空值替换到远程，也不失为一种方式）：git push origin :refs/tags/v1.0.1

  git rebase

  这块其实涉及的玩法会相对来说复杂一点，可能还是需要拿来和 merge 做一下对比才更加有意义，东西有点多，先搁置一下。

  WIP...

以上がまだ Git を使ったことがありませんか?今すぐ手配してください！の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。