Let's talk about how to elegantly pull and merge code in Gitlab

How to pull and merge code elegantly in Gitlab? The following article will introduce to you the method of pulling and merging code in Gitlab. I hope it will be helpful to you!

pull or fetch

There are two forms of pulling code operations, git pull andgit fetch, So what is the difference between the two?

Let’s take a look at an architecture diagram first

The picture shows a complete git process. In order to understand each area more clearly, let’s go down Explain their functions:

• Working directory, is simply the area where you work. For git, it is the local working directory.
• Staging area (stage area, also called index area index), is a transitional stage before submitting modifications to the repository. There is a index file in the .git directory under the working directory, which stores the contents of the temporary storage area. The git add command adds the workspace contents to the staging area.
• Local repository, The repository of the version control system, exists locally. When the git commit command is executed, the contents of the staging area will be submitted to the warehouse. The .git/objects directory stores records of each submission, while the .git/refs directory stores branch information and tag information.
• Remote repository, is basically the same concept as the local warehouse. The difference is that one exists remotely and can be used for remote collaboration, while the other exists locally. Local and remote interaction can be achieved through push/pull;
• Remote warehouse copy, can be understood as a remote warehouse cache that exists locally. When using git fetch to pull a remote code repository, it is equivalent to having a copy of the remote repository locally. You can choose to merge this copy into the local repository.

As can be seen from the picture, when we use git pull to pull the code, it is directly merged into the local branch, while using git fetch When pulling code, a copy of the remote warehouse will be generated locally, and then merged into the local branch using git merge or git rebase.

Since you can directly git pull why do you need to do it multiple times? Imagine a scenario where you want to merge other people's code, but you don't know what they have changed and whether it can be merged with your code. This can be easily achieved through git fetch. git fetch will not actually merge with the local branch immediately. After git fetch, the following figure will be displayed:

The above picture shows that a test2 branch has been added remotely, and one more commit information has been added to the test branch. At this time, it is in .git/refs/remotes/origin You can see an additional test2 branch in the directory.

Use git log origin/test to view specific submission information

If you want to see what the submitted content is, just You can create a new branch by

git checkout -b test-origin
git merge test

. Now that I have talked about it, I believe you already understand the difference between git pull and git fetch. To summarize:

• git fetch is safer and more user-friendly

• git pull is more aggressive and destructive

General Leaders habitually use git fetch when managing projects to check which branches have been added recently and what modifications have been made, so as to better manage the project. control.

merge or rebase

For the merge operation mentioned above, generally we directly merge a certain file through git merge <branch name></branch> branch code. Let’s first look at the problem of using git merge directly. There is a very unpleasant Merge branch message, as shown below:

The following picture is a flow chart after the merger. When we pull a dev in the main branch for development, both branches have submission records. When we merge When , the normal situation should be to merge directly on the basis of main, instead of adding an additional C7 submission information, which is the Merge branch mentioned above. This is obviously A very unreasonable phenomenon (of course this does not affect the normal work of git).

So how to solve the problems caused by this phenomenon? The answer is git rebase, commonly known as rebase.

下面我们先来看看变基以后git分支是什么样的了

可以看到，当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</commitid>

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

The above is the detailed content of Let's talk about how to elegantly pull and merge code in Gitlab. For more information, please follow other related articles on the PHP Chinese website!