Gitlab でコードをエレガントにプルしてマージする方法について話しましょう

Gitlab でコードをエレガントにプルしてマージするにはどうすればよいですか? Gitlab でコードをプルしてマージする方法を次の記事で紹介しますので、お役に立てれば幸いです。

プルまたはフェッチ

コードのプル操作には、git pull と # # の 2 つの形式があります。 #git fetch, では、この 2 つの違いは何でしょうか?

最初にアーキテクチャ図を見てみましょう

図は完全な git プロセスを示しています。各領域をより明確に理解するために、下に進みましょうそれらの機能を説明します。

• 作業ディレクトリ。 は単に作業を行う領域です。 git の場合、これはローカルの作業ディレクトリです。
• ステージング領域 (ステージ領域、インデックス領域インデックスとも呼ばれる) は、リポジトリに変更を送信する前の移行ステージです。作業ディレクトリの下の .git ディレクトリに index ファイルがあり、一時記憶領域の内容が保存されます。 git add コマンドは、ワークスペースの内容をステージング領域に追加します。
• ローカル リポジトリ、 バージョン管理システムのリポジトリはローカルに存在します。 git commit コマンドが実行されると、ステージング領域の内容がウェアハウスに送信されます。 .git/objects ディレクトリには各送信のレコードが保存され、.git/refs ディレクトリにはブランチ情報とタグ情報が保存されます。
• リモート リポジトリ () は、基本的にはローカル ウェアハウスと同じ概念ですが、違いは、1 つはリモートに存在してリモート コラボレーションに使用できるのに対し、もう 1 つはローカルに存在することです。ローカルとリモートの対話は、プッシュ/プルを通じて実現できます。
• リモート ウェアハウス コピー、 は、ローカルに存在するリモート ウェアハウス キャッシュとして理解できます。 git fetch を使用してリモート コード リポジトリをプルする場合、リモート リポジトリのコピーをローカルに持つことと同じであり、このコピーをローカル リポジトリにマージすることを選択できます。

図からわかるように、

git pull を使用してコードをプルすると、git fetch# を使用しながらローカル ブランチに直接マージされます。 ## コードをプルすると、リモート ウェアハウスのコピーがローカルに生成され、git merge または git rebase を使用してローカル ブランチにマージされます。 git pull

は直接実行できるのに、なぜ複数回実行する必要があるのでしょうか?シナリオを想像してみてください。他の人のコードをマージしたいが、何が変更されたのか、自分のコードとマージできるかどうかはわかりません。これは、

git fetch を使用して簡単に実現できます。 git fetch は、実際にはローカル ブランチとすぐにはマージされません。git fetch の後、次の図が表示されます:

# #上の図は、

test2 ブランチがリモートで追加され、さらに 1 つの送信情報が

test

ブランチに追加されたことを示しています。この時点では、それは .git にあります。 /refs/remotes/origin ディレクトリに追加の test2 ブランチが表示されます。 特定の送信情報を表示するには、git logorigin/test を使用します。

送信されたコンテンツが何であるかを確認したい場合は、

git checkout -b test-origin
git merge test

で新しいブランチを作成できます。ここまで説明しましたが、

git pull

と

git fetch

の違いはすでに理解できたと思います。要約すると: git fetch はより安全でユーザーフレンドリーです

• git pull はより攻撃的で破壊的です

• 一般リーダーは、プロジェクトを管理するときに習慣的に

  git fetch
を使用して、どのブランチが最近追加されたか、どのような変更が加えられたかを確認し、プロジェクトをより適切に管理します。

マージまたはリベース

上記のマージ操作では、通常、git merge <ブランチ名> ブランチを通じて特定のファイルを直接マージします。コード。まず、

git merge

を直接使用する場合の問題を見てみましょう。以下に示すように、非常に不快な Merge ブランチ メッセージが表示されます。 ##次の図はマージ後のフローチャートです。開発のために main ブランチの dev をプルすると、両方のブランチに送信レコードがあります。マージ When すると、通常の状況は、追加の

C7

送信情報 (上記の Merge ブランチ

) を追加するのではなく、main に基づいて直接マージする必要があります。これは明らかに非常に不合理な現象です (もちろん、これは git の通常の動作には影響しません)。

では、この現象によって引き起こされる問題をどのように解決すればよいでしょうか?答えは git rebase (一般にリベースとして知られています) です。 <p>下面我们先来看看变基以后git分支是什么样的了</p><p><img src="/static/imghw/default1.png" data-src="https://img.php.cn/upload/article/000/000/024/10b956edf1b5aacea79a6a88e0d7202e-5.jpg" class="lazy" alt="" loading="lazy"/></p><p>可以看到，当<code>dev分支更新之后，它会指向这些新创建的提交(commit),而那些老的提交会被丢弃。

示例操作

上面讲了这么多，现在让我们来实际操作一下。

场景：远程有一个main分支上有内容更新，现在我们需要把更新的内容合并到本地dev分支上，然后push到远程dev分支，当前分支实在dev分支。

简单实现（就是很朴实无华）：

# 拉取main分支代码
git fetch origin main
# 合并到dev
git rebase origin/main

上面的git rebase还有个快捷的操作，直接一行命令搞定

# 拉取test分支代码合并到dev
git pull --rebase origin test

如果你不想每次都添加rebase，可以在终端中输入下面的命令：

git config --global pull.rebase true

这个配置就是告诉git在每次pull前先进行rebase操作

其他命令参考

# 查看本地分支
git branch
# 查看远程分支
git branch -r
# 查看所有分支
git branch -a

# 拉取所有远程分支代码
git fetch 
# 拉取origin源上所有分支代码
git fetch origin
# 拉取orign源上main分支代码
git fetch origin main

# 拉取远程分支到新建的一个本地分支并
git checkout -b newBrach origin/master
# 合并远程分支到本地
git pull --rebase origin master

# 查看提交日志
git log --oneline
# 查看某个人提交的日志
git log --author=xiumubai --oneline
# 查看某个文件提交的记录
git blame README.md
# 查看某次提交的内容
git show <commitid>
# 查看最近几次的提交

git log -p -n

（学习视频分享：编程基础视频）

以上がGitlab でコードをエレガントにプルしてマージする方法について話しましょうの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。