Git の基本: 共通機能とコマンド ライン

プログラミング 2023-08-11 18:43:59 訪問数: null

記事ディレクトリ


参考:
Git チュートリアル|Cainiao Network
Git チュートリアル - Liao Xuefeng

1. Git の概要

  • バージョン管理システム

Git はオープンソースの分散バージョン管理システムであり、大小を問わずあらゆるプロジェクトを迅速かつ効率的に処理でき、通常はチーム開発プロジェクト中のソース コードの共同編集や管理に使用されます。Git は、2005 年に Linus Torvalds によって開発された C ベースのオープン ソース バージョン管理ソフトウェアで、Linux カーネル開発の管理を支援し、他のカーネル開発者が貢献や変更を送信できるようにします。バージョン管理システムとは何ですか? たとえば、Word で論文を書いた場合、修正するたびに別のファイルを保存する必要があり、最終的には多数のバージョンが存在し、講師が修正する場合は、ファイルを送り返してマージする必要があります。新しいコンテンツは非常に面倒になります。Git は各ファイルの変更を自動的に記録し、ファイルの共同編集をサポートするため、複数の「バージョン」を手動で管理する必要はありません。

  • 分散制御

その他のバージョン管理ツール CVS および Subversion は、集中バージョン管理システムです。バージョン ライブラリは、中央サーバーに集中的に保存されます。個人はサーバーから最新バージョンを取得し、変更後に中央サーバーにプッシュバックされます。これは、ライブラリと類似しています。集中バージョン管理システム。動作するにはインターネット接続が必要です。分散型バージョン管理システムには「中央サーバー」がなく、全員のコンピュータに完全なバージョンライブラリがあるため、ネットワークに接続する必要がなく、セキュリティも非常に高いです。CVS、SVN、ClearCase など、他にも多くのバージョン管理システムがあります。Git が最も人気があります。

2. インストール構成

Git は現在、Linux/Unix、Solaris、Mac、および Windows プラットフォームでの実行をサポートしており、 git-scm公式 Web サイトからダウンロードできます。Windows システムを例に挙げると、gitforwindowsミラーのダウンロード、インストール後には、グラフィカル インターフェイス Git GUI と Git Bash が含まれます。

ここに画像の説明を挿入
ここに画像の説明を挿入

2.1 構成情報の表示

  • git config --list

サーバー情報を構成します。git は分散バージョン管理システムであるため、各マシンはユーザー名と電子メールを設定する必要があります。global を使用して、このマシン上のすべての Git ウェアハウスがこの構成情報を使用することを示します。また、別のウェアハウス ユーザー名を指定することもできますそしてメールで

$ git config --global user.name 'name'
$ git config --global user.email 'email'

# 查看config
$ git config --list

3. ファイル管理

3.1 倉庫の作成

  • git init: ディレクトリの初期化
  • git add：追加ファイル
  • git commit: ファイルを送信する

バージョンライブラリはディレクトリに相当するリポジトリ(リポジトリ)にもなり、このディレクトリ内のすべてのファイルをGitで管理でき、各ファイルの変更履歴を追跡したり復元したりすることができます。まず空のディレクトリを作成しmkdir、ファイルを入力しcd、pwd現在のディレクトリを表示します。git initこのディレクトリを Git が管理できるウェアハウスにすることで、その.gitディレクトリの下に Git がバージョン ライブラリを追跡および管理するためのディレクトリが追加されます。表示されない場合は非表示になっている可能性がありますls -ah。

$ mkdir Desktop/learngit
$ cd Desktop/learngit
$ pwd
/c/Users/pengy/Desktop/learngit

$ git init
Initialized empty Git repository in C:/Users/pengy/Desktop/learngit/.git/

$ ls -ah
./  ../  .git/

次に、learngit で readme.txt ファイルを作成し、新しいファイルを直接作成して、 と をgit add介しgit commitてそのファイルをウェアハウスに送信します。addウェアハウスへのファイルの追加が繰り返し使用できることを Git に伝え、複数のファイルを追加し、commitファイルをウェアハウスに送信すること-mが、この送信の手順です。正常に実行されると、1 つのファイルが変更されました (ファイルが変更されました)、2 つの挿入(+) (2 行が挿入されました) (readme.txt では 2 行) と表示されます。この設定addと2 つの手順は、一度に多くのファイルを送信でき、ファイルを複数回追加できるcommitためです。commitadd

$ git add readme.txt
$ git commit -m 'wrote a readme file'
[master (root-commit) 643a68e] wrote a readme file
 1 file changed, 2 insertions(+)
 create mode 100644 readme.txt

go go go
run everyday

3.2 バージョンのロールバック

  • git status: 倉庫の現状を把握する
  • git diff: 変更されたコンテンツを表示します
  • git log: コミット ログを最新のものから最も遠いものまで表示します。
  • git reset: 指定したバージョンにロールバックします
  • git reflog: コマンド履歴を表示して、将来どのバージョンに戻すかを決定します。

readme.txt ファイルの内容を次の内容に変更し、git statusコマンドを使用して結果を表示します。

go go go
sleep everyday

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   readme.txt

no changes added to commit (use "git add" and/or "git commit -a")

git status上記の結果は、readme.txt が変更されたことを示していますが、変更はまだ送信されていません。具体的な変更内容を確認したい場合はgit diffコマンドを使用すると実行がスリープに変更されたことが確認できます

$ git diff readme.txt
diff --git a/readme.txt b/readme.txt
index 9fbbc68..ab0fdda 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,2 +1,2 @@
 go go go
-run everyday
\ No newline at end of file
+sleep everyday
\ No newline at end of file

次に、上記の方法で変更を送信します。

$ git add readme.txt
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   readme.txt

$ git commit -m 'change sleep'
[master 3149571] change sleep
 1 file changed, 1 insertion(+), 1 deletion(-)

$ git status
On branch master
nothing to commit, working tree clean

送信後、送信する必要のある変更はなく、作業ディレクトリの作業ツリーがクリーンであることが示されます。
以下のように、以前の変更方法に従ってファイルを変更します。

go go go
sleep everyday
young and rich

$ git add readme.txt
$ git commit -m 'append line'
[master 0efc261] append line
 1 file changed, 2 insertions(+), 1 deletion(-)

このように、ファイルは継続的に変更され、変更と送信のたびに現在の内容が保持されます。その後の復元に関しては、バックアップのようなものです。現在、readme.txt は 3 回変更されています。

go go go
run everyday

go go go
sleep everyday

go go go
sleep everyday
young and rich

git log最新のものから最も古いものまでコミット ログを表示します。

$ git log
commit 0efc2612b8fbf89a036e4358c4a0c83f9afddffc (HEAD -> master)
Author: bujibujibiu <123456@gmail.com> 
Date:   Wed May 24 14:37:07 2023 +0800

    append line

commit 3149571d74bc882218458f638eb119dae24e1a57
Author: bujibujibiu <123456@gmail.com>
Date:   Wed May 24 14:26:39 2023 +0800

    change sleep

commit 643a68e9294e906037cb37d3c120dac6f02a2127
Author: bujibujibiu <[email protected]>
Date:   Wed May 24 11:31:55 2023 +0800

    wrote a readme file

グラフィカルな Git Gui では、コミット履歴を明確に確認できます。Git
ここに画像の説明を挿入
は、Head現在のバージョンappend line、HEAD^以前のバージョン、HEAD~100および最後の 100を示しますgit reset。以前のバージョンへのロールバックを使用してchange sleep、現在のファイルの内容を表示すると、それが 2 番目になります。バージョン。

$ git reset --hard HEAD^
HEAD is now at 3149571 change sleep

$ cat readme.txt
go go go
sleep everyday

もう一度、git logレコードが 2 つだけであることがわかります。

$ git log
commit 3149571d74bc882218458f638eb119dae24e1a57 (HEAD -> master)
Author: bujibujibiu <[email protected]>
Date:   Wed May 24 14:26:39 2023 +0800

    change sleep

commit 643a68e9294e906037cb37d3c120dac6f02a2127
Author: bujibujibiu <[email protected]>
Date:   Wed May 24 11:31:55 2023 +0800

    wrote a readme file

最新バージョンに戻りたい場合は、それを見つけてcommit idバージョン番号の最初の数桁を書き込むだけで、Git が対応するバージョンを自動的に見つけて、最新バージョンに戻ることがわかります。

$ git reset --hard 0efc
HEAD is now at 0efc261 append line

$ cat readme.txt
go go go
sleep everyday
young and rich

バージョン番号を確認するには、git reflog毎回記録するコマンドを使用できます。

$ git reflog
0efc261 (HEAD -> master) HEAD@{
    
    0}: reset: moving to 0efc
3149571 HEAD@{
    
    1}: reset: moving to HEAD^
0efc261 (HEAD -> master) HEAD@{
    
    2}: commit: append line
3149571 HEAD@{
    
    3}: commit: change sleep
643a68e HEAD@{
    
    4}: commit (initial): wrote a readme file

3.3 ワークフロー

  • ワークスペース - ステージング領域 - リポジトリ ブランチ

前述したように、変更したファイルを送信するには、追加とコミットの 2 つの手順が必要であり、そのプロセスは次のとおりです。 Gitリポジトリには、.gitステージング領域 (インデックス/ステージ)、Git によって自動的に作成される最初のブランチmaster、およびmasterそれへのポインタが含まれていますHEAD。git addファイルの変更を一時記憶域に追加し、git commit一時記憶域のすべての内容を現在のブランチに送信しますmaster。
ここに画像の説明を挿入
たとえば、readme.txt に内容の行を追加し、同時に新しいファイル LICENSE.txt を作成します。これは、git statusファイルが変更されたことを示し、新しいファイルが追跡されていないファイルとして追加されます。次に、git addこれら 2 つのファイル、LICENSE.txt と readme.txt が一時保管領域に配置され、git commit2 つのファイルがmaster支店に提出されます。

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   readme.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        LICENSE.txt

no changes added to commit (use "git add" and/or "git commit -a")

$ git add readme.txt
$ git add LICENSE.txt
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   LICENSE.txt
        modified:   readme.txt

$ git commit -m 'stage works'
[master 2312846] stage works
 2 files changed, 2 insertions(+), 1 deletion(-)
 create mode 100644 LICENSE.txt
$ git status
On branch master
nothing to commit, working tree clean

Git は、たとえば次の操作に従ってすべての変更を管理します。modify readme.txt—add—modify readme.txt—commit—status、commit は最初の変更の内容のみを送信、add は最初の変更を一時記憶領域に置きます。 Git はファイル自体ではなく、すべての変更を管理していることがわかります。

# （1）修改readme.txt，新增track changes
$ cat readme.txt
go go go
sleep everyday
young and rich
crzay life
track changes

# （2）readme.txt存放在暂存区
$ git add readme.txt

# （3）再次修改readme.txt，变成track changes second
$ cat readme.txt
go go go
sleep everyday
young and rich
crzay life
track changes second

# （4）提交暂存区里的readme.txt
$ git commit -m 'track changes'
[master bd56840] track changes
 1 file changed, 2 insertions(+), 1 deletion(-)
 
# （5）显示当前状态，第二次修改的readme.txt没有被提交
$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   readme.txt

no changes added to commit (use "git add" and/or "git commit -a")

git diff HEAD -- readme.txtワークスペースとリポジトリの readme.txt の違いがわかります。

$ git diff HEAD -- readme.txt
diff --git a/readme.txt b/readme.txt
index a8981d7..a7d5c05 100644
--- a/readme.txt
+++ b/readme.txt
@@ -2,4 +2,4 @@ go go go
 sleep everyday
 young and rich
 crzay life
-track changes
\ No newline at end of file
+track changes second
\ No newline at end of file

3.4 変更を元に戻す

  • git checkout -- file: ファイルワークスペースの変更を元に戻します
  • git reset HEAD file: 一時記憶領域の変更を元に戻します

ワークスペースへの変更を元に戻すには、次を使用します。git checkout -- file

# （1）readme.txt文件新增stupid day
$ cat readme.txt
go go go
sleep everyday
young and rich
crzay life
track changes second
no hope
stupid day

# （2）删除工作区的修改
$ git checkout -- readme.txt

#（3）stupid day已经删除
$ cat readme.txt
go go go
sleep everyday
young and rich
crzay life
track changes second
no hope

add一時記憶領域に到達した場合は、git resetコマンドを使用して一時記憶領域の変更を作業領域にロールバックし、checkout作業領域の変更を破棄します。

# （1）修改readme.txt新增stupid day
$ cat readme.txt
go go go
sleep everyday
young and rich
crzay life
track changes second
no hope
stupid day

# （2）add到暂存区，状态为待提交
$ git add readme.txt
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   readme.txt

# （3）把暂存区的修改回退到工作区，状态为待add
$ git reset HEAD readme.txt
Unstaged changes after reset:
M       readme.txt

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   readme.txt

no changes added to commit (use "git add" and/or "git commit -a")

# （4）checkout撤销工作区的修改
$ git checkout -- readme.txt

$ cat readme.txt
go go go
sleep everyday
young and rich
crzay life
track changes second
no hope

バージョン ライブラリに不適切な変更が送信された場合、この送信をキャンセルしたい場合は、以前のバージョンを使用してロールバックできますが、リモート ライブラリにプッシュされていないことが前提となります。

3.5 ファイルの削除

  • git rm:ファイルの削除
  • git checkout -- file: ワークスペース ファイルを復元します

新しいファイルが追加され、リポジトリに送信されたとします。次に、このファイルを削除する必要があります。最初にrmワークスペース内のファイルを削除し、次にgit rmリポジトリ内のファイルを削除します。

# （1）新增文件test.txt，并add和commit到版本库
$ git add test.txt
$ git commit -m 'add test.txt'
[master 33f52c0] add test.txt
 1 file changed, 1 insertion(+)
 create mode 100644 test.txt

# （2）使用rm命令直接删除工作区的test.txt
$ rm test.txt
$ git status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    test.txt

no changes added to commit (use "git add" and/or "git commit -a")

# （3）使用git rm删除版本库中的test.txt并commit
$ git rm test.txt
rm 'test.txt'
$ git commit -m 'delete test.txt'
[master 2e755a3] delete test.txt
 1 file changed, 1 deletion(-)
 delete mode 100644 test.txt

rmワークスペース内のファイルを削除し、削除が間違っていた場合はcheckout、ワークスペース内のバージョンをリポジトリ内のバージョンに置き換えることができ、ワークスペースが変更されているか削除されているかに関係なく、「ワンクリックで復元」できます。

# （1）新增文件test.txt，并add和commit到版本库
$ git add test.txt
$ git commit -m 'add test new'
[master 943447f] add test new
 1 file changed, 1 insertion(+)
 create mode 100644 test.txt

# （2）使用rm命令直接删除工作区的test.txt
$ cat test.txt
for test
$ rm test.txt
$ cat test.txt
cat: test.txt: No such file or directory

# （3）checkout 恢复工作区的文件
$ git checkout -- test.txt
$ cat test.txt
for test

4. 遠隔倉庫

4.1 リモートライブラリへの接続

Git は、複数バージョンのプロジェクトを管理するための分散バージョン管理ツールです。Github と Gitlab はどちらも Git ベースのコード ホスティング プラットフォームで、一般に Github はオープン ソース プロジェクトをホストするために使用されますが、GitLab はよりプライベートで企業に適しています。ローカル倉庫とリモート倉庫間の送信には SSH 暗号化が必要です。githubを例に挙げます。まず、ローカル Git に設定情報を設定し、メールを使用して Github にアカウントを登録します。

$ git config --global user.name 'name'
$ git config --global user.email 'email'

まずcd ~/.sshSSHが設定されているかどうかを確認し、ファイルがない場合はSSHを設定する内容を入力し、Enterを押し続けるとパスワードを設定できません

$ ssh-keygen -t -rsa -C '[email protected]'
Generating public/private rsa key pair.

.sshディレクトリを再度開き、id_rsa秘密鍵なので外部に漏らすことはできず、id_rsa.pub公開鍵なので公開することができ、id_rsa.pubその内容をGithubのSSHキー設定にコピーします。

$ cd ~/.ssh
$ ls
id_rsa  id_rsa.pub
$ cat id_rsa.pub

接続が成功したかどうかを確認するには、次のステートメントを入力して「認証は成功しましたが、GitHub はシェル アクセスを提供しません」と表示します。

$ ssh [email protected]

4.2 ローカルからリモートへのアップロード

  • git remote add origin *********.git: リモート倉庫に接続します
  • git push: ローカル ブランチのコンテンツをリモート ライブラリにプッシュします
  • git remote -v: 遠隔倉庫情報の表示
  • git remote rm <name>: リモートリポジトリを削除します

以前の 3.1 でローカル ウェアハウスを作成した後、Github または Gitlab に Git ウェアハウスを作成する場合で、2 つのウェアハウスがリモートで同期されている場合は、まず「Github でのリポジトリの作成」で空の Git ウェアハウスを作成し、次にローカル ウェアハウスの内容をコピーします。ウェアハウス GitHub ウェアハウスにプッシュし、ローカル ウェアハウスでコマンドを実行します

$ git remote add origin *********.git

*********これはリモート ウェアハウスのアドレスです。追加後のリモート ウェアハウスの名前はorigin、Git のデフォルト名である になります。git Remote -v を使用してリモート ライブラリ情報を表示する

pengy@LAPTOP-7A77J86V MINGW32 ~/Desktop/CPCS (master)
$ git remote -v
origin  https://github.com/bujibujibiu/learngit.git (fetch)
origin  https://github.com/bujibujibiu/learngit.git (push)

追加時のアドレスが間違っている場合、またはリモート ライブラリを削除したいだけの場合は、次のgit remote rm <name>コマンドを使用できます。

$ git remote rm origin

ローカル ライブラリのすべてのコンテンツをリモート ライブラリにプッシュするgit pushと、matserブランチのコンテンツが Github にプッシュされ、変更されるたびにこのコマンドを通じてリモート ウェアハウスを更新できます。

$ git push origin master

リモート ライブラリとローカル ライブラリの両方が初期化されており、それらを同期する必要がある場合は、まずリモート ライブラリをローカルにプルし、次にプッシュする必要があります。

$ git pull origin master

「致命的: 無関係な履歴のマージを拒否する」エラーが発生した場合、次の方法を使用して強制的にマージします。

pengy@LAPTOP-7A77J86V MINGW32 ~/Desktop/learngit(master)
$ git pull origin master --allow-unrelated-histories
From https://github.com/bujibujibiu/learngit
 * branch            master     -> FETCH_HEAD
Merge made by the 'ort' strategy.
 README.md | 3 +++
 1 file changed, 3 insertions(+)
 create mode 100644 README.md

pengy@LAPTOP-7A77J86V MINGW32 ~/Desktop/learngit(master)
$ git push origin master
Enumerating objects: 9, done.
Counting objects: 100% (9/9), done.
Delta compression using up to 12 threads
Compressing objects: 100% (7/7), done.
Writing objects: 100% (8/8), 95.42 KiB | 13.63 MiB/s, done.
Total 8 (delta 1), reused 0 (delta 0), pack-reused 0
To https://github.com/bujibujibiu/learngit.git
   7ec29b2..fb58fc0  master -> master

4.3 リモートライブラリからローカルへのクローン作成

  • git clone *****: リモート リポジトリのクローンをローカル ファイルに作成します

4.2 最初にローカル ウェアハウスがあり、次にリモート ウェアハウスがある リモート ウェアハウスを関連付ける方法は、最初にリモート ウェアハウスがあると仮定して、ローカル ウェアハウスにクローンを作成する必要があります。たとえば、最初に Github ウェアハウスを作成して確認し、GitHub がそのウェアハウス用のファイルをInitialize this repository with a README自動的に作成するようにします。README.md次のステップでは、git cloneコマンドを使用してローカル リポジトリのクローンを作成します。

$ git clone https://github.com/bujibujibiu/learngit.git

このようにして、learngit ライブラリがローカルに表示され、README.mdファイルが存在します。

5.支店管理

5.1 ブランチの作成

  • git branch: ビューブランチ
  • git branch name: 新しいブランチを作成します
  • git checkout (branchname): 分岐切り替えコマンド
  • git checkout -b (branchname): 新しいブランチを作成し、すぐにそれに切り替えます

Git 管理の変更は、これらの送信をタイムライン (つまりブランチ) に文字列化することです。Git が初期化されると、ブランチが自動的に作成され、現在masterのバージョンが最新の送信ポイントを指しますHEAD。コミットするたびにブランチは 1 つ前に進み、コミットが続くとブランチ行はどんどん長くなります。たとえば、新しいブランチを作成し、同じコミットをポイントし、次にそれをポイントする場合、現在のブランチが最上位にあることを意味します。これ以降、ワークスペースの変更と送信はブランチに対して行われます。たとえば、新しい送信後、ポインタは 1 ステップ進みますが、ポインタは変化しません。以下のように: learngit フォルダーを作成し、3.1 の操作で新しいウェアハウスを作成し、readme.txt ファイルを追加します。mastermastermastermasterdevmasterHEADdevdevdevdevmaster
ここに画像の説明を挿入
ここに画像の説明を挿入
ここに画像の説明を挿入

$ cd learngit
$ git init
Initialized empty Git repository in C:/Users/pengy/Desktop/learngit/.git/

$ git status
On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        readme.txt

nothing added to commit but untracked files present (use "git add" to track)

$ git add .

$ git commit -m 'create readme file'
[master (root-commit) dd8bad0] create readme file
 1 file changed, 6 insertions(+)
 create mode 100644 readme.txt
 
$ git status
On branch master
nothing to commit, working tree clean

$ git branch
* master

次に、新しいブランチを作成しtest、testそのブランチに切り替えます

~/Desktop/learngit (master)
$ git branch test

~/Desktop/learngit (master)
$ git branch
* master
  test

~/Desktop/learngit (master)
$ git checkot test
git: 'checkot' is not a git command. See 'git --help'.

The most similar command is
        checkout

~/Desktop/learngit (master)
$ git checkout test
Switched to branch 'test'

testブランチの下に新しいフォルダー test.txt を追加すると、ブランチの下に readme.txt と test.txt の 2 つのファイルがあることlsがわかり、ブランチtestに戻り、readme.txt ファイルだけが残ります。master

~/Desktop/learngit (test)
$ ls
readme.txt

~/Desktop/learngit (test)
$ echo 'runoob.com' > test.txt

~/Desktop/learngit (test)
$ ls
readme.txt  test.txt

~/Desktop/learngit (test)
$ git add .
warning: in the working copy of 'test.txt', LF will be replaced by CRLF the next time Git touches it

~/Desktop/learngit (test)
$ git commit -m 'add test file'
[test d20d68d] add test file
 1 file changed, 1 insertion(+)
 create mode 100644 test.txt

~/Desktop/learngit (test)
$ ls
readme.txt  test.txt

~/Desktop/learngit (test)
$ git checkout master
Switched to branch 'master'

~/Desktop/learngit (master)
$ ls
readme.txt

git checkout -b (branchname)新しいブランチを作成し、このブランチに切り替えるために使用しますnewtest。ファイルはmaster次のものと同じです。

~/Desktop/learngit (master)
$ git checkout -b newtest
Switched to a new branch 'newtest'

~/Desktop/learngit (newtest)
$ ls
readme.txt

5.2 ブランチの削除

  • git branch -d (branchname): ブランチの削除

git branch -d (branchname)以前に作成したブランチを削除するために使用しますnewtest。別のブランチに切り替えることに注意してください。現在のブランチは削除できません。

~/Desktop/learngit (newtest)
$ git branch
  master
* newtest
  test

~/Desktop/learngit (newtest)
$ git branch -d newtest
error: Cannot delete branch 'newtest' checked out at 'C:/Users/pengy/Desktop/learngit'

~/Desktop/learngit (newtest)
$ git checkout master
Switched to branch 'master'

~/Desktop/learngit (master)
$ git branch -d newtest
Deleted branch newtest (was dd8bad0).

~/Desktop/learngit (master)
$ git branch
 * master
  test

5.3 ブランチのマージ + 競合の解決

  • git merge (branchname): 任意のブランチを現在のブランチにマージします (メイン ブランチではない場合があります)。

masterブランチに新しいファイル runoob.php を作成します。ブランチには readme.txt と runoob.php の 2 つのファイルがあり、commitブランチには readme.txt と test.txt の 2 つのファイルがあります。mastertest

~/Desktop/learngit (master)
$ git branch
* master
  test

~/Desktop/learngit (master)
$ touch runoob.php

~/Desktop/learngit (master)
$ git add .

~/Desktop/learngit (master)
$ git commit -m 'add runoob file'
[master 3dcca8c] add runoob file
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 runoob.php
 
~/Desktop/learngit (master)
$ ls
readme.txt  runoob.php

~/Desktop/learngit (master)
$ git checkout test
Switched to branch 'test'

~/Desktop/learngit (test)
$ ls
readme.txt  test.txt

testブランチをブランチにマージしますmaster。2 つのブランチの下に test.txt ファイルがあり、それらが異なると仮定すると、マージによって競合が発生します。

pengy@LAPTOP-7A77J86V MINGW32 ~/Desktop/learngit (test)
$ cat test.txt
runoob.com
study
new
amazing
HAPPY

pengy@LAPTOP-7A77J86V MINGW32 ~/Desktop/learngit (master)
$ cat test.txt
runoob.com
study
new
new again

pengy@LAPTOP-7A77J86V MINGW32 ~/Desktop/learngit (master)
$ git merge test
Auto-merging test.txt
CONFLICT (content): Merge conflict in test.txt
Automatic merge failed; fix conflicts and then commit the result.

test.txt を開くと、競合するコンテンツが表示されます。

pengy@LAPTOP-7A77J86V MINGW32 ~/Desktop/learngit (master|MERGING)
$ cat test.txt
runoob.com
study
new
<<<<<<< HEAD
new again
=======
amazing
HAPPY
>>>>>>> test

Git は通常、マージ操作を実行するときに、マージ メッセージの内容を保持するために MERGE_MSG スワップ ファイルを生成します。Git が作業ディレクトリでこのスワップ ファイルを見つけた場合、最後のマージ操作が正常に完了しなかったことを意味し、エディタ プロセスが予期せず終了した可能性があります。入力rm .git/.MERGE_MSG.swp

masterプロンプトに従ってブランチ下の test.txt ファイルを変更し、commit再起動後に成功を示す [master 2bf0895] を表示します。

$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
        both modified:   test.txt

no changes added to commit (use "git add" and/or "git commit -a")

pengy@LAPTOP-7A77J86V MINGW32 ~/Desktop/learngit (master|MERGING)
$ git add .

pengy@LAPTOP-7A77J86V MINGW32 ~/Desktop/learngit (master|MERGING)
$ git commit -m 'merge change'
[master 2bf0895] merge change

pengy@LAPTOP-7A77J86V MINGW32 ~/Desktop/learngit (master)
$ git status
On branch master
nothing to commit, working tree clean

おすすめ

転載: blog.csdn.net/weixin_45526117/article/details/130830720
おすすめ
ランキング
uni.request在接口状态码403等还是走success
Springboot は mybatisplus を統合しており、ページング クエリによって返される Page オブジェクトの合計は常に 0 です。
System.InvalidOperationExceptionが：「BuildWindowCoreは、子ウィンドウのハンドル搭乗を返しません。」
[Example 08] IPD system advancement: version naming rules for version management
カスタム NavigationBar -- UIView による描画
データとデータの移行を復元します（個人的なメモ、無用リーダー）
4. 2次元配列で検索する
vim的私人订制
Flutterのカスタムルーティング切り替えアニメーション
Javaコンテナの方法の簡単なアプリケーションのArrayList
アーカイブ
もっと
2024-05-12(27)
2024-05-11(31)
2024-05-10(33)
2024-05-09(30)
2024-05-08(18)
2024-05-07(34)
2024-05-06(6)
2024-05-05(0)
2024-05-04(18)
2024-05-03(8)

コードワールド

© 2018 codetd.com