この記事は、Git チュートリアル というコラムで、Git の操作方法をとても詳しく紹介しています。以下では、Git の使い方を説明します。Git を必要とする友人の役に立てば幸いです。
暗く風の強い夜、ガールフレンドが悲しそうな顔をして突然、「Git が理解できない」と言いました。より良い経験を? 言うには遅すぎましたが、言うのは早かったです。何も言わずに、すぐに書き続けました...
通常のコーディング プロセスでは、まだ何かを行う必要があります。 . Git を操作する能力。しかし、ニーズを満たすためにどの Git コマンドを使用すればよいのか突然思い出せない場合がまだいくつかあります。そのときは、Google/Baidu を開いてさまざまに検索する必要があります。これで何度も時間を無駄にするのではなく、繰り返し作業を行う場合は、よく使用されるコマンドのゲームプレイを研究することをお勧めします。この記事では、これらの一般的に使用される Git システムとコマンドのアプリケーション シナリオと一般的な使用法を紹介する一連の事例も提供します。
もちろん、Git コマンドの使用方法を知ることに加えて、私たちが毎日操作するコマンドをより明確に理解できるように、Git のアーキテクチャ全体がどのようなものであるかを理解する必要もあります。 。
不適切な表現があった場合は、修正していただきありがとうございます。
まずはイメージから始めて、結論は推測に依存します。
リモート ウェアハウス エリア
: これはコード送信の最終目的地であり、何もありません。言う 。 リモート ブランチのローカル コピー
: これは実際には、主にリモート ウェアハウスの各ブランチのデータのローカル コピーを保存します。Git プロジェクトの下にある .git ファイルを開くことができます。 /remotes 内の refs は主にリモートウェアハウスのブランチ情報が格納されており、通常プッシュ、プル、フェッチを実行するとここに更新されます。 ローカル ブランチ
: これは私たちがよく扱う領域です。コミットを実行した後、基本的にこの領域に送信することになります。.git ディレクトリの refs/ を確認できます。このディレクトリには、ローカル支店コード情報が含まれています。 ステージング領域
: この領域は、git add を実行するたびに保存される領域です。ローカル ウェアハウスでキャッシュを作成するために使用されます。また、基礎となる設計でもあります。これは比較的重要な領域でもあり、Git が diff を実行する際の検索パフォーマンスを向上させるのに役立ちます。 ワークスペース
: これは通常、vscode によって開かれたプロジェクトなどのコードを作成する場所であり、コードを編集できます。 さらに、ローカル git ストレージ領域という特別な領域があります。これは何に使用されますか?一般的に、これは特定のシナリオで使用される可能性があります。ローカルでコードを変更することもありますが、突然誰かが別のブランチについて質問しにやって来ます。同時に、ある機能を実装しているのですが、それは半分実装されています。 Git ウェアハウスに送信したくない場合は、git stash save "temporarily save"
の使用を検討してください。この時点で、このストレージ領域に保存されます。他のブランチに移動して、作業が終わったら戻ってきて、その後は git stash Pop
で大丈夫です。
しかし、作者はこの機能の使用をまだ推奨していません。ある日、一度切り替えてからまた切り替え、このストレージを忘れて別のことを書くと、その時点で騙されてしまうからです。泣く。もちろん、この機能は依然として非常に便利ですが、使用には注意が必要です。
日常業務において、Git を使用する頻繁な対話のプロセスは、大まかに次のとおりです (仕様が異なると多少の違いはありますが、大きな違いはありません)違いは大きくありません):
git add
を実行してコードをステージング領域に送信します。 git commit
コードをローカル ウェアハウスに送信しますgit Push
コードをリモート ブランチに送信します上記のプロセスは、一般的な Git フロー プロセスを大まかにまとめたものです。企業によっては独自の仕様を設計している可能性があるため、ここではあまり詳しく説明しません。
git stash
git clone
git init
##git merge #git log
git リセット
git reflog
git revert
git Cherry-pick
git tag
コマンド分析
git stash (簡単に説明するために一時的に挿入)
git clone
git clone xxx.git -b Branch1
ウェアハウスをリモートで構築することに加えて、操作のために Git ウェアハウスをローカルで初期化することもできます。このとき、git init を直接簡単に使用できます。現在のディレクトリに対する変更をバージョン管理ライブラリに組み込むことができます。 git リモート
指示。 git remote は、リモート ウェアハウスとのリレーションシップ バインディング処理やその他の操作を実行するために使用されます。
たとえば、初期化されたローカル倉庫と作成されたリモートの空の倉庫がある場合、次の操作を実行してそれらを関連付けることができます。git Remote addorigin xxx.git
まずローカル ウェアハウスに追加しますgit Push -u Origin master
: のマスター ブランチを示します。現在のウェアハウス これをリモート ウェアハウスのマスター ブランチに関連付けると、後でプッシュまたはプル操作を非常に便利に実行できます。 プロジェクトを取得した後、まず現在のウェアハウスに現在どのようなブランチがあるかを確認する必要があります。後から新しいブランチを作成して、次のような問題を見つけないようにしてください。名前が重複している場合は、この時点で git Branch
を使用して関連するブランチを確認できます。
git ブランチ
: すべてのローカル ブランチ情報を表示します。git ブランチ -r
: リモート ウェアハウスのすべてのブランチを表示しますgit Branch -a
: ローカルおよびリモート ウェアハウスのすべてのブランチを表示します一般的に、ブランチが多すぎる場合は、ビジュアル ツールを使用してブランチを表示することをお勧めします。 vscode やソース ツリー、その他のソフトウェアなどの情報。
もちろんIDEAもご利用いただけます。
現在のブランチに基づいて新しいブランチを作成し、それに切り替える場合は、次のコマンドを使用できます。
git checkout -b Branch1
git add
git add -A
ファイルがステージング領域に追加されたら、次のステップを実行できます。 git commit [file1] ... -m [メッセージ]git commit
-m現在送信されている情報を表します
と git commit
を分離する必要がない場合は、git commit -am
を選択できます。便利で早いです。 git rm
これは実際に非常に便利です。たとえば、プロジェクトには .env というファイルがあります。このファイルはプライベートなのでリモートに送信できませんが、誤って送信してしまいました。ローカル ウェアハウスに送信する場合、今回はこのファイルを .gitignore ファイルに追加します。これは、送信が git によって無視される必要があることを示します。ただし、このファイルはすでにローカル ウェアハウスに送信されているため、ローカル ウェアハウスから削除しないと意味がありません。まず git ウェアハウス。
git Push
git Push -- set-上流起点ブランチ 1
作業が完了したら、リモート ウェアハウスに行って確認すると、作成した新しいブランチがプッシュアップされていることがわかります。次に、友人の中には、リモート倉庫にすでにこのブランチ名が付いている場合はどうなるのか、と尋ねる人もいるかもしれません。
通常、現在のブランチがリモート ブランチとの接続を確立している場合、リモート ブランチをマージしたい場合は、 を実行するだけで済みます。 git pull
は問題なく、他のパラメータは必要ありません。ただし、上記の git Push と競合する場合は、接続を確立する前に、マージのためにコードのどのブランチをプルダウンする必要があるかを指定する必要があります。
git pullorigin Branch1
ここでのオリジンは、リモート倉庫 必要に応じて名前を変更できますが、通常は原点が使用されます。
上記の競合の問題に戻ると、git pull を直接使用して、現在のローカル ブランチとマージするリモート ブランチを指定し、ローカルで競合を解決して、変更を送信します。実行 git Push --set-upstream Origin Branch1
コマンドが完了しました。
上記の git pull
コマンドを理解すると、このコマンドは実際に簡単に理解できるようになります。ウェアハウス内の対応するブランチへのはローカルでのみプルされ、自分のワークスペース (現在コードを変更しているワークスペース) に自動的にマージされることは望ましくありません。コードの特定の部分を書き終えた後でマージすることを検討します。最初に git fetch
を使用できます。
フェッチが完了した後、現在作業中の変更をローカル ウェアハウスに送信し、その変更をリモート ブランチでマージしたいと考えています。このとき、git mergeorigin/[ を実行します。現在のブランチ名]
(デフォルトでは、通常、リモート ブランチ プレフィックスを表すためにorigin を使用します)。
指定されたブランチ コードを現在のブランチにマージします。一般的に、私たちがより頻繁に使用するシナリオは、リモート ウェアハウスのマスター ブランチが変更され、現時点では MR について言及する準備をしているため、最初にマスター コードをマージし、競合がある場合は解決する必要があります。
同様に、上で紹介した git mergeorigin/xxx も同じように使用されます。
名前の通り、ログという意味ですが、このコマンドを実行すると、現在のブランチのコミット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复制代码
この時点で、一部の読者は、これは何に使用されるのかと尋ねるかもしれません。簡単な使用法は、誰が何を送信したかを確認することです。より重要な使用法は、実行することです。コードのバージョン管理、ロールバック、またはその他の興味深い操作については、作成者が説明します。
次の分析は、次のパラメータ HEAD^ に基づいています。つまり、git replace HEAD^ です。
。
--soft
: ステージング領域とワークスペースを変更せずに、送信された最新バージョンをリセットします。 --mixed
: デフォルトのパラメータ。最後の送信 (コミット) と一致するようにステージング領域内のファイルをリセットするために使用され、ワークスペース ファイルの内容は変更されません。 --hard
: すべての提出物を以前のバージョンにリセットし、ワークスペースを変更します。これにより、完全に以前の提出物バージョンに戻り、現在の提出物はコード内に表示されなくなります。つまり、ワークスペースの変更も強制終了されます。 長く話していると、なかなか理解できないようです。理解するための例を挙げてみましょう:
例:
git add
を実行します。この時点でステージング領域を確認すると、変更が送信され、vscode によってステージング領域 を実行すると、この時点で送信が完了しました
--soft
:我们对 README 的更改状态现在变成已被提交至暂存区,也就是上面 2 的步骤。--mixed
: 我们对 README 的更改变成还未被提交至暂存区,也就是上面 1 的步骤。--hard
:我们对 README 的所有更改全没了,git log 中也找不到我们对 README 刚刚那次修改的痕迹。默认情况下我们不加参数,就是 --mixed,也就是重置暂存区的文件到上一次提交的版本,文件内容不动。一般会在什么时候用到呢?
可能大部分情况下,比如 vscode 其实大家更习惯于使用可视化的撤销能力,但是呢,这里我们其实也可以稍微了解下这其中的奥秘,其实也很简单:
git reset
git reset HEAD
其实一二都是一样,如果 reset 后面不跟东西就是默认 HEAD。
当你某个改动提交到本地仓库之后,也就是 commit 之后,这个时候你想撤回来,再改点其他的,那么就可以直接使用 git reset HEAD^
。这个时候你会惊奇的发现,你上一版的代码改动,全部变成了未被提交到暂存区的状态,这个时候你再改改代码,然后再提交到暂存区,然后一起再 commit 就可满足你的需求了。
除了这种基础用法,我们还可以配合其他命令操作一下。
某一天你老板跟你说,昨天新加的功能不要了,给我切回之前的版本看看效果,那么这个时候,你可能就需要将工作区的代码回滚到上一个 commit 版本了,操作也十分简单:
git log
查看上一个 commit 记录,并复制 commitIdgit 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复制代码
git log
找到有你这个代码的那个 commitId(也就是 36577ea21d79350845f104eee8ae3e740f19e038)git reset --hard commitId
这个时候你想把复制好的代码写回去,该怎么办呢,你可能会再 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 log 看不到我之前 commitId 了,那么就回到 reset 之前的状态吧!
当然了,如果是针对 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 的按钮选项,让你进行更安全的回滚操作。
其实对于我们工作中大部分场景下应该用不到这个功能,但是呢有的时候这个命令又能挽救你于水火之间,那就是当某个倒霉蛋忘记切分支,然后在 master 分支上改了代码,并且提交到了本地仓库中,这个时候使用git cherry-pick
简直就是神器了。
git cherry-pick
:将执行分支的指定提交合并到当前分支。一听介绍就来精神了,雀氏有点东西,比如我在 master 分支提交了某个需求的代码,同时还没提交到远程分支,那么你就可以先 git log
查看一下当前的提交,找到 master 分支正常提交之后的所有 commitId,然后复制出来,然后再切到你建好的开发分支,接着执行 git cherry-pick master commitId1 commitId2 commitId4
。
完事之后记得清理一下作案现场,把你的 master 分支代码恢复到正常的提交上去。
顾名思义,也就是打标签的意思。一般可能会在你发布了某个版本,需要给当前版本打个标签,你可以翻阅 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
这块其实涉及的玩法会相对来说复杂一点,可能还是需要拿来和 merge 做一下对比才更加有意义,东西有点多,先搁置一下。
WIP...
以上がまだ Git を使ったことがありませんか?今すぐ手配してください!の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。