Nanny Level Tutorial | Merge Request Branch Merge Request

Nanny Level Tutorial | Merge Request Branch Merge Request

What is it ?

First of all I would like to say something about What is branches merge request Merge Request (also called Pull Request , below all with Merge Request or its abbreviation MR refer to), and it what role (if you understand this concept , you can skip What is it ).

MR (or PR ) means to merge the content of the code you developed into the branch it wants to go to in a way of requesting merge. The recipient of this request ( Reviewer ) is generally the person in charge of the project, team or other member .

Generally speaking, the development team Code Review (code review/review/inspection). Because Code Review can indeed improve the quality of the code and reduce the generation rate of BUG

Merge Request is an important part of Code review If you use MR to initiate a merge request, then you can conduct code review with the merged content of your request as a unit during code review. If the review passes, the merge will be successful. The review is handed over to Reviewer , who can be the recipient of the request. If multiple members of the team are sitting together to see your merged content, then naturally the Reviewer is these people. After a review of the code of many, the code will naturally reduce the incidence of the problem, the developer will maintain good coding practices in the development, after all, no one wants to be someone else pointing own code.

However, some teams may not pay attention to Merge Request , at most dev branch (the development branch shared by everyone), and then develop on the new branch, then commit -> push finally merge to dev branch.

Next, we will take Merge Request as the goal, and start from the establishment of the warehouse to describe a complete git workflow and the git operation.

How to do?

Next, we will start from 0 and take the Gitee (Code Cloud) code hosting and R&D collaboration platform as an example to git how to use Merge request in the normal 061edf3e1e5deb workflow.

1. Create a remote warehouse, create the master branch by default

2. Create a local repository and associate a remote repository

After initializing the local repository, create a random file and submit it to the master branch of the remote repository.

git init
touch README.md
git add README.md
git commit -m "first commit"
git remote add origin https://gitee.com/yaodao666/git-merge-requet.git
git push -u origin master

git push -u is to associate and push the content to the branch of the remote warehouse. (There are other ways to associate remote branches later.)

3. Create a dev branch starting from the master branch

We will use the dev branch as the development branch (a branch shared by warehouse members).

4. Add another member to the repository

The member will handle his own Merge Request Reviewer later, and look at our submissions, so as to achieve the purpose of code review.

Then set that user as a code reviewer:

The above operations are all in the management settings options of the Gitee

4. Switch to the dev branch locally and connect to the remote dev branch

At this time, there is no dev branch locally. Can use

git branch -a

command to view all branches.

use it now

git checkout -b dev

to create a local branch of dev. If the -b parameter is not added when the command is executed at this time:

git checkout dev
error: pathspec 'dev' did not match any file(s) known to git

It will report an error as above. Because the command is only to switch branches, and there is no dev branch at this time, it will naturally report an error if it cannot be switched.

OK, now we have created the local dev branch, now let's associate it with the dev branch of the remote warehouse. (Only in this way can pull and push operations be performed!)

git branch --set-upstream-to=origin/dev

That's it!

Execute the following command

git pull
Already up to date.

The above information appears, indicating that the remote dev the link.

In fact, there is a link to a remote repository branch of ways, such as we have in remote repository on to dev branch as a starting point, creating a test branch, then we create a local test a branch, you can perform:

git checkout -b test origin/test

Create the local test branch while linking to the remote test branch.

In the following 5. Create a new feature (feature) branch There will be another way to connect to the remote warehouse branch.

5. Create a new feature branch

In actual development, we often create a new feature branch, which is dedicated to you, and it is dedicated to dealing with a bug or developing a new feature. That is, when there is a new function that needs to be developed or there is a bug and part of the code to be optimized and refactored, we should come up with a new branch to deal with these things.

The way to create dev is the same as above, but instead of creating a branch in the remote warehouse this time, directly creates a branch locally, and then pushes the branch to the remote .

Let's switch to the dev branch first. In normal work, you must pull it to ensure that the code you write will be dev on the latest code on 061edf3e1e608f to avoid unnecessary troubles.

git checkout dev
git pull

Create a new feature branch with the following command, let's name it feature-beer .

git checkout -b feature-beer

6. Develop on the feature-beer branch and push to the remote.

Just change something on the readme.md Then execute:

git add -A
git commit -m "这是我第一次在feature-beer分支上提交。"

Finally, push the content to the remote warehouse,

git push -u origin feature-beer

At this time, go to the remote warehouse and see that there will be a feature-beer branch, and the submitted content will also be available. So git push -u is not only to associate and push content to the branch of the remote repository, but also to create the branch when there is no remote branch!

7. Merge directly to dev.

Many times, some development teams simply care about using Merge Request for code review when merging, so they will merge the code directly into the dev branch.

Switch to the dev branch and execute the merge command.

git checkout dev
git pull                # 在合并前同样先pull一下dev
git merge feature-beer    # 这里的合并是本地合并，将feature-beer中的内容合并到dev中
git push                # 将本地内容推送到远程仓库

At this point, go to the remote dev branch and take a look:

We feature-beer modify the content has been placed on dev on.

8. Merge Request

However, this simple and rude method often brings many problems. For example, no one pays attention to what you dev . This kind of no one pays attention to the code written by 161edf3e1e61e6 often leads to developers not paying attention during development. Code specification, even the obvious bugs will be submitted, and they will be too lazy to test, and even worse will upload the code that makes the project fail to start.

At this time, if you can have someone to help you check again and see how the code you wrote, it will prompt you to pay more attention to code specification and code robustness when writing code. After all, no one wants to be criticized by others. It's better to be praised. And Merge Request can achieve this effect.

Now, we will simulate the process of Merge Request

Re-switch to the feature-beer branch to write some content, and submit it in two times, and push to the remote branch.

git checkout feature-beer
# 改点内容：这是我第二次在feature-beer上进行开发工作，现在是晚上十一点五十一分了。
git add -A
git commit -m "这是第二次在feature-beer上的开发的第一次提交。"
# 改点内容：这是我第二次在feature-beer上进行开发工作，现在是晚上十一点五十二分了。
git add -A
git commit -m "这是第二次在feature-beer上的开发的第二次提交。"
git push

In this way, the remote branch can see the two commits of this development.

The 061edf3e1e625e operation is provided on Pull Request to implement Merge Request.

In the created Pull Request , you must select the source branch and the target branch. You can also see the commit log and file change information.

After clicking Create, Beer Bear members will receive this request.

He can see the commits in commits and files. After the review is passed, it can be merged. When we created it earlier, we checked to delete the commit branch (but it was not checked in the screenshot, it was checked in actual operation), merged, there would be no such branch .

At this time, look at the branch and branch content again, and find that feature-beer is gone, and there is merged content in dev.

9. Delete local branch and remote branch

At this point we should delete this local branch.

git checkout dev            # 先切换到dev分支
git pull
git branch -d feature-beer

If this command reports an error, it is often

• Most likely you are on that branch.
• This branch contains work that has not yet been merged, which can be merged first or forcibly deleted using the -D parameter.

If your remote branch has not been deleted (in this article, the remote branch was Merge Request when 061edf3e1e6387 passed), you can use:

git push origin --delete feature-beer

Of course, you can also log in to the Gitee webpage to delete the remote branch.

Why delete it? Can't you keep using it?

In fact, you can continue to use it, but it is not recommended, because the purpose of creating this branch is to develop a new module or fix a bug. When the development work is completed, delete the branch and create a new one when dealing with other things.

Some Questions

1. If the local dev has modified content, can these modified contents be brought to the new branch

For example, one day, you are very sleepy, you open the compiler and start working directly. After working for a long time, you find out that this is the dev branch. At this time, there have been many changes to the code, what to do?

Now we add a new line to the dev

Then switch to the new branch: feature-new-beer.

git checkout -b feature-new-beer

Open the file again and you will find this line of information. information is 161edf3e1e642e that can be brought by .

What if I don't want to bring it here? Let's delete this branch first and change it to another branch to see how to not bring it over.

git checkout dev
git branch -d feature-new-beer

We use

git stash

Temporarily store the memory on the dev branch, and this line will not be visible on the dev.

Then we switch to the new branch again: feature-new-beer.

git checkout -b feature-new-beer

At this time, there will be no such line of information on the branch. But if you execute at this point:

git stash pop

You will find that line appears again, and when you switch to dev , this line also appears on dev

Why does the above phenomenon occur? In fact, it is because git , and these two areas are shared by all local branches.

When there is content modification, the modification information will be placed in the workspace. At this time, if a new branch is directly checked out, the content of the workspace will be taken over.

And if the modified information is temporarily stored (stash) in the temporary storage area, it will not be taken over if it is temporarily stored. However, since this area is also shared, when the temporary storage content is popped, all branches will be restored at the same time. these modifications.

If I check out the new branch after dev on stash , and add another line, what happens pop

git stash pop

It will prompt an error: your local changes (changes on the new branch) will be overwritten.

At this time if:

git stash
git stash pop

Then the local change will overwrite the modification dev , that is, the following information is also on dev

As said at the beginning of this question, if you have written a lot dev pull latest code first, and then check out to the new branch to continue development.

You can go back to dev at any time and do discard changed (rollback to the original unmodified version) directly.

If you are really worried, wait for the new branch code to be written and submitted before you delete it on dev

2. If I have many commits on the new branch, can I merge these commits into one commit before committing

This is possible, and many times we recommend it. For example, a module takes three days to complete. You may have submitted six or seven times in these three days, but in fact you have only completed the development of a new module.

If in your few commits someone dev commit the record dev when you finally make a merge request to 061edf3e1e65c4 and it goes through? Let's try it together.

We first Question1 in the dev modify the branch discard changes look (back unmodified state, that the previous version), and then just delete the branch and create a new branch feature-many-commits .

# use "git checkout -- <file>..." to discard changes in working directory 这是官方提示
git checkout -- README.md        # 该文件回到未修改的状态

git branch -d feature-new-beer
git checkout -b feature-many-commits

Now let's write something random on the new branch and commit.

# 随便加一行：我在 feature-many-commits 分支上写东西。现在是晚上22:25,写完这行立马提交。
git add -A
git commit -m"feature-many-commits,晚上22:25"

Now and then dev write something and submit and branch push (analog which is another person code delivery up), but in order to avoid conflict, we will not README write a file, create a new txt file.

Now we go back to new branch the point just write content and submit, then push to the remote and go Gitee performed on MergeRequest .

# 随便加一行：我在 feature-many-commits 分支上写东西。现在是晚上22:34,写完这行立马提交。
git add -A
git commit -m"feature-many-commits,晚上22:34"
git push -u origin feature-many-commits

There are two options here, one is to merge the branch and the other is to flatten the branch. Looking at the explanation, you should be able to guess what it means. The first means direct merge, the latter is to feature-many-commits on 061edf3e1e66c0 into a new commit - this is what we want, and then merge into on dev.

But let's take a look at directly merging :

Now we can answer the question at the beginning based on the commit record shown in this figure: "If someone dev in several of your commits, then when you finally merged to dev and succeeded, the record of commit How is it?".

As the picture shows, the dev commit is sandwiched between the two commits on the new branch, which is really messy and unsightly.

So we should use flatten the branch in many cases to merge.

Write some content to submit, and try again in a flat way:

# 随便加一行：我在 feature-many-commits 分支上写东西。现在是晚上22:43,写完这行立马提交，希望这个提交最后会与接下来的commit被合并到一个commit中。
git add -A
git commit -m"feature-many-commits,晚上22:43"

# 随便加一行：我在 feature-many-commits 分支上写东西。现在是晚上22:44,写完这行立马提交，希望这个提交最后会与之前的commit被合并到一个commit中。
git add -A
git commit -m"feature-many-commits,晚上22:44"
git push

It was found that the two commit were indeed successfully merged into one! And the time of submission is the time of passing Merge Request（Pull Request） .

To summarize the problem: merging the branches directly would make every commit of both branches commit by the time of 061edf3e1e67a1, which would look messy. We can pass gitee the way we flatten the branch on MR .

3. In addition to choosing a flattened branch when merging after the Merge Request is passed (merging multiple submissions into one commit), is there any way to achieve this effect?

Indeed, this operation of merging multiple submissions into one submission is performed on gitee . If I don’t go to gitee to perform Pull Request , and directly perform merge , won’t this effect be achieved?

It should be noted that, in fact, Gitee Gitlab have this function, so if you Merge Request (or Pull Request ) on their platforms, this effect will definitely be achieved.

But what if I don't go to the code hosting platform to initiate a merge request? I just want to finish local development, and then merge it to dev (from the local dev branch push to the remote dev branch), what should I do? At this time, a git rebase command is about to come out.

The function of this command is to commit a branch into one commit , and then there will be only one commit when merge

The process goes like this (an example of feature-many-commits contents of the 061edf3e1e684a branch onto dev ):

# 假设现在开发完毕 并且已经在feature-many-commits上提交了多次
git checkout dev
git pull            # dev保持最新的代码
git checkout feature-many-commits
git rebase dev        # 将feature-many-commits上所有的commit，重新在新的dev的HEAD上commit一遍
git checkout dev    # 再次切换到dev上
git merge feature-many-commits # 将feature-many-commits上的内容合并到dev上
git push            # 推送即可

This process is relatively simple, and many people are doing it, so I won't demonstrate it here.

Summary

Now let's sort out the key processes of the MR

Assuming that the dev branch is a branch shared by everyone, we need to inspect the new branch for development work on this basis, and finally merge it into the remote branch Merge Request :

1. switch to dev branch

   git checkout dev

2. Update the dev branch code

   git pull

3. Based on the dev branch, check out a new branch feature-beerbear

   git checkout -b feature-beerbear

4. Develop and commit your code

   git add -A
   git commit -m"xxxxxx"

5. Push the local feature-beerbear branch to the remote

   git push -u origin feature-beerbear  # 会创建一个远程feature-beerbear分支

   If it is not the first push, you can use it directly

   git push

   Steps 4 and 5 will be repeated in the actual development work.

6. After the development work is completed, go to the code hosting platform for Merge Request (or Pull Request ) operations.

7. After the merge request is approved. You can delete the local branch.

   git branch -b feature-beerbear

8. A new task is coming, start from 1 again.

At step six, the following may happen:

① If it does not pass, then continue 4 , but it is no longer necessary to propose a new MR(Merge Request) .

At this time, you may be wondering, why don't you need to mention it again?

Because this merge refers to a merge between branches, when your remote feature-beerbear branch changes, MR will perceive the change.

In fact, if the source branch and target branch MR you want to create are the same as those in the MR

You have to close the previous one, of course not at all.

② Conflict occurs

While you when you create a new branch pull a bit dev branch, and then created based on this new branch, but after all, your MR may be issued several days later, dev branches is certainly not original state. So it will cause a conflict to be reminded when MR What should I do when there is a conflict between the prompts? All it takes is a few commands:

git checkout dev
git pull
git checkout feature-many-commits
git merge dev                        # 如果在这一步发生冲突，那么手动解决冲突即可
git push

In fact, the dev code updates, and then dev code merged into feature-many-commits up.

In fact, we can go through the above few lines of commands before MR , so that conflicts MR

It's not that you just executed the above command, and when you are about to submit MR , someone dev , which just happens to cause a conflict - if so, you can buy a scratch-off to try your luck.

Thanks

This is the end of Merge Request First of all, thank you for reading this article!

Secondly, I very much hope that this article will help you, maybe not very much. If you like this article or really have something to gain, please like or bookmark it, preferably leave a message in the comment area and let me know!

Although I put a lot of effort into writing this article, after all, our level is average and our abilities are limited, so there will definitely be some poor sentences, unclear expressions and even mistakes.

I would be very grateful if you could point out problems and give me some advice, and your suggestions and advice will urge me to keep improving this article! Welcome to friendly exchanges!