Day-4 | Merge in Git & Merge Conflicts | 30 Days Of GitLab DevOps

追加: 2026-05-14

[00:00:00]Hello team and welcome back to the day four. Uh so today in today's session we are going to understand about how uh merge request works. How review works for merge request in free plan. How and why squash is important and how it's going to be done while merging. How merge conflicts occur and how to resolve conflicts safely. Okay. Side by side with respect to merge we are going to understand what kind of merge we have.

[00:00:24]For example, we have merge comet, we have squash merge comets, we have rebase, we have fast forwards. All those we are going to see and we are going to understand as well. Right? So make sure to watch this video, make sure to implement it, make sure to make small short notes for your own. Okay? And once you have completed, make sure to put it on LinkedIn as well. Right? I hope keep till day three, you have completed everything that I have shown also. Guys, all the documentations for this uh today's session will be added in discord server in the same uh thread that I have created notes and resources. So, make sure to check it out right and if you are already not in discord server then make sure to join it. Details will be in the description. Now, with that being said, let's get started. So, today is day four and today we are going to understand about the merge request deep dive so that we can understand when merge request happen in companies or in GitLab repositories how exactly it's done and what is the benefit of it and what exactly it is in deep dive. Okay, first what exactly is uh merge request?

[00:01:25]First of all, a merge request is not just a g operation. It's basically a process layer on the top of git on top of git. Okay. So in real workflows what happens? A developer is going to write the source code in separate branch. For example, let's say we have main branch from which we uh we have created a feature branch feature XYZ. Okay. Note that we are working with uh trunkbased development at this point. So developer has created separate branch and he has written the code for new feature inside it. Right? But the thing is this code is not act like not at all trusted yet.

[00:02:02]Okay. So instead of directly merging this uh feature in a feature branch inside main branch, what we do? We create a merge request. Okay, we create a merge request using which we can do a lot of things. A lot of things means uh what things will be done when we create a merge request? First of all, it merge it will become like a place where code will be reviewed.

[00:02:28]code will be reviewed because see we don't want that directly we can merge the see we can merge uh feature branch like using the command get merge but we don't want to directly merge the feature branch inside the main we want that before the feature branch is merged to main branch we should the code written in feature branch the additional code for new feature it should be properly reviewed right whatever changes are added they should be properly discussed test right and if we have pipelines that can uh that can like validate the code it's working fine or not test cases are working or not so if we have pipelines that should also be executed pipeline should be executed right before we merge the code and then only the final [snorts] decision should be made so this will make sure key whatever code we are merging from feature branch to main branch it is correct it is completely correct and we have tested it, we have reviewed the code, pipelines are also validated, then only merging should be happening. This is the main reason that we have merge requests instead of directly merging any code to any branches. Right? So in simple words, we can say in order to understand things in much better way, we can say that a merge request is a control gateway inside your main branch. Okay, that we can say. Now let us understand the merge uh merge request life cycle. what steps are there in order to set up the merge request and like how exactly uh merging will be done right. So let us understand now MR life cycle.

[00:04:06]So let us understand teams step by step.

[00:04:09]So first we have step one. Okay. In step one what is going to be happening? Step one a feature branch will be created.

[00:04:20]Okay. So we can execute command like this. get checkout - B then whatever feature branch you want to create let's say I want to create a branch feature branch which is going to be creating new feature of login okay so using this command we can create a new branch why do we have to create new branch from main branch why do we have to do that because it's going to isolate the work so that developers can separately work on new piece of code right also it will prevent any any break in production whatever production code is there in main branch since we are not directly working there in main branch. So it will make sure key production is not breaking production code is not breaking right.

[00:05:03]So that will be the first step where we have to create the uh feature branch.

[00:05:08]Then we have step two where what we have to do inside the feature branch whatever code has been written by developer it is going to be pushed to feature branch and after that a mr will be created a merge request will be created in order to merge the code from feature branch to main branch right so here once developer has written the code they can push their uh piece of code inside feature branch they can run the command like this get push and origin they are going to make sure define as feature / add login. This is our feature branch. So first they are going to push their code from local machine to remote feature branch. Right?

[00:05:48]Once they have done next what is going to happen? One p push is done then mr is going to be created. Okay. Where source branch will be feature branch and target branch will be main branch. That means we want to merge source branch inside target branch. We want to merge feature branch inside main branch. Okay. Now basically once you create an MR once you create a merge request it basically means that you are proposing we are proposing a merge.

[00:06:26]See creating a merge request does not mean that directly a merge is done.

[00:06:30]Creating a merge request basically means that you are proposing a merge so that a feature branch can be merged to main branch once everything is approved.

[00:06:39]Right? This is step two.

[00:06:42]Now step three.

[00:06:45]In step three we need to understand something that is known as draft versus ready. Okay. So basically when you create a merge request you can mark that merge request either as draft which basically means this is not ready for review. The merge request is not ready for review or you can mark your merge request as ready which means it is now ready for review.

[00:07:17]See as I told you before any merge is completed first code review is going to be done. So when you create a merge request you can mark that merge request as draft which basically means key as of now this merge request the code that we have uh created the merge request for that code is not ready to be reviewed right now or we can mark the merge request as ready that means now it could be reviewed. Okay this will be uh step three talking about next step which is step four. In step four what we have in step four the actual review and discussion is going to be done.

[00:07:58]Okay. So basically inside GitLab free version the free version of GitLab that we are using as of now reviewers are not enforced. Okay.

[00:08:10]Whatever reviews can be there, they are not enforced.

[00:08:17]But they can comment on the code. They can comment on code. They can suggest changes and they can start discussions.

[00:08:33]Okay. So B, so as I said key reviews are not enforced. But what exactly does it mean? It means that in the G uh in the free version of GitLab as you know as as of now we are using the free version of GitLab right. So in the free version of GitLab the reviewers that you add to review the course they can for sure check your code they can comment comment the suggestions they can suggest fixes they can discuss issues but but their approval is not mandatory.

[00:09:06]It's not mandatory. That means key a developer can still merge the code without reviewer approval. Okay. And this is we are talking about free free tier of GitLab. Enterprise version you can set up in you can enforce that uh the approval of these reviewers are mandatory for merge request. Okay. So yeah this is the uh step four. Now let's talk about step five.

[00:09:33]In step five, basically we can have pipeline execution. What does it mean? So it basically means that let's say we have main branch and from main branch we had feature branch. Okay, let's say add login. For this feature we have created new feature branch. Right? So before we merge this uh branch to main and new code is added to main what we want? We want to make sure key whatever uh code we have inside this branch it should be properly tested. It should be correct for deployment also. For that what we can have? We can have pipelines right. CI/CD pipelines we can have mainly CI pipeline and trigger event. The trigger means when exactly this pipeline should be triggered. We can set up the trigger event as [snorts] merge request. That means whenever merge request is created the pipeline will be triggered and if it is successful then only merge should be allowed. So that will be uh step five and in this scenario the pipeline will uh become our quality gate.

[00:10:39]Okay. And the status of the pipeline it is successful or not it will appear in MR in the merge request. Okay. And final step we have step six which is the merge decision.

[00:10:57]So that means once everything looks good code review is done uh code is fine pipeline is also passed then finally merge request will be completed and the code from feature branch will be merged to main branch. Okay.

[00:11:12]So now let us understand what kind of merge can be happen. Okay. So the merging can be done in many ways and starting with first example. So first merging can happen using merge commit. Okay, let us understand like what exactly it is with an example.

[00:11:32]So first let's say we have main branch inside which we have commits like A and B commits. Then we created new branch from main branch which is feature branch right and now once we created feature branch from main branch it was having initial commit like this and then we added few more commits like C and D. Now if I want to merge back the feature branch to main branch and I'm using merge commit method what will be the structure? So structure will be something like this A B okay there will be C D and there will be one additional commit added which is M which basically denotes that merge has taken place. Okay. So here one thing will you'll be able to notice that C and D will be preserved. That means key now after merge has been completed from feature branch to main branch C and D commit will be visible. Okay. And there will be one additional commit added which basically is going to showcase that merge has taken place. Okay. So this is uh merge commit method. Talking about second method for merging which is squash merge.

[00:12:49]Let us understand what exactly happens in this. So let us say again we have main branch inside which we have commits a and b then we created feature branch inside which now we have a b and there were additional commits added. Okay. So now if I want to merge feature branch back to main what is going to happen?

[00:13:08]Squash is going to happen. That means there were two new commits added in feature branch. These will be combined and another commit will be added. Let's call it as S. So now after merge has taken place the structure of main branch or the commits in the main branch will be like this. A B and S. And S is what?

[00:13:26]S equal to C + D. Okay. This is squash merge. So basically here S is going to be one clean commit. Okay.

[00:13:38]Okay. And now let us see next one. Next one we have fast forward merge.

[00:13:50]So now let us understand the fast forward merge. Here you need to understand the concept of head. Head basically means whatever the latest commit it points to latest commit. Okay.

[00:14:03]So with respect to fast forward example basically what happens here. Here moving of the head happens. Okay. For example, let's say we have main branch inside which we have commits like A. Then we have commit B, we have commit C. Then we created a feature branch from main. Then we have the structure commits. Whatever commits were previously in main those are there. Then we added few more commits D and E. So initially the head was in for main branch head was here.

[00:14:33]And for feature branch now head is here.

[00:14:37]Right? So basically what happens if you're going to merge feature branch back to main using the first forward merge what is going to happen? New uh point new pointer or new head will become E. So it will be like this.

[00:14:57]Okay. So for main also here what is happening for main? Simply movement of head is happening. Simply movement of pointer is happening. Previously it was on C but now it will be on E. Okay, this is the first scenario where uh like fast forward merge will happen without an issue. But one thing you need to understand fast forward has some limitations. So in which scenarios fast forward won't work. So let us say that we had main branch where we have commits like a and b then we created feature branch we had a b then we added few more commits like this right so at this point for feature branch [snorts] head or pointer is here for main branch it was initial here but before merge before we merge feature branch back to main we added some new commit let's say e so Now head is here. Now fast forward fast forward merge won't work here because if when we are going to merge feature branch back to main. So movement of like head is going to happen.

[00:16:01]Movement of pointer is going to happen.

[00:16:04]But it is not possible now because E does not exist inside feature branch. So if it does not exist then we cannot move the pointer in that way. Okay. basically like uh now at this point for main branch pointer cannot move to D okay because merge it won't work for merge won't work here so in this case what we do we use rebase we use another merge strategy which is known as rebase so in case of rebase what exactly is going to happen so first of all rebase is going to rewrite the feature branch right it's going to make new featur basically it's going to rewrite feature branch and Now the uh structure of feature branch will be something like this C dash and Ddash and this note that this is feature branch. Previous feature branch was not having E from main but now new feature branch like uh basically new uh rewrite history of feature branch will be having E as well. Now I can see the here key previously it was C and D but now it's C dash and Dash. The thing is these commit ids may be different but the changes whatever changes were introduced with respect to these commits they are not different. That means the code that were uh like in that were added inside the repository that is not changed even though commit ids might be different.

[00:17:31]Okay. So code has not been changed and with help of rebase only now feature branch structure will be like this.

[00:17:37]Okay. and ddash will be the head now.

[00:17:43]And now since after replace the feature branch has been fixed. So now what is going to happen? Now first feature can work because now E is present inside feature branch also. And okay and now previous head was E. New head is here.

[00:17:57]So now after merge new head will be like this. Head basically moving of the pointer happens. So new will be like this. Final head will be a pointer will be here. Okay. Okay, after merging in main branch. So this is how re rebase plus fast forward is going to work. So team now we are going to see things practically. Okay. So currently we are on main branch. Right. I have cloned it using the SSH method that we have already covered in previous session. So what I'm going to do I'm going to create a new file here. I'm going to name this uh test 1.xt txt and inside that I'm just going to write adita jw and let us save this. Once it is saved we are going to commit and push it to main branch. So I'll run get add dot get commit - m added test one txt and let us push it. Get push origin master.

[00:19:05]Okay.

[00:19:21]As you can see it gave error because we have protected the main branch. So let us quickly modify a few things. I'll go to the repository and here in in your project see this is the project you can scroll down to settings and inside that go to repositories in repositories go to protected branches and here allowed to push and mod so here I'll just select developers plus this and that should solve our problem okay and yeah one second I think.

[00:19:57]Okay. So, let me try again. And this should work now.

[00:20:05]Okay. So, now it's working, right?

[00:20:08]So, let me quickly add one more file.

[00:20:14]I'll add the file as test 2.txt.

[00:20:18]And here also few things I'll just write.

[00:20:22]Save this and we are going to push this as well. So I'm going to run gad dot get commit.

[00:20:32]This will be test test 2.txt and get push.

[00:20:41]Okay. So now this has been done and now we are going to check the logs. I'll check the commit. So I'll run the command git log - one line which is going to show us commits in the simplest format. Okay. So these are the commits and this is the latest commit which is head. So we have added the commit test to txt file. Right now next thing what we are going to do now we are going to create a feature branch from this. So I'm going to run the command get checkout -v features / update app. I'm creating a new feature branch.

[00:21:23]Okay. Now what we are going to do we are going to add some file and we are going to commit that.

[00:21:30]So I can execute this command which you can see I added a file uh app.txt txt inside which I wrote feature change uh added the edit the file then commit the file and then post it to feature branch right so this is done now we will go back to our repository I will go here you'll be able to see feature branch is created right so once feature branch is created next thing what we are going to do we can go to merge request and we can create a merge request Either you can click on here or you can see already it is showing here. So let me click here.

[00:22:10]New mo request.

[00:22:14]Okay.

[00:22:16]Source branch will be this. Target branch will be one second. Yeah. Target branch will be master.

[00:22:28]Okay.

[00:22:30]So now we can click on compare branch and continue.

[00:22:35]And now we have to provide details here.

[00:22:38]Okay. So here title I can give as day four merge request demo we can add that request demo. Okay I told you two options available mark as draft or ready. So for ready you don't have to do anything but if you want to mark it as draft you can simply select this option.

[00:23:07]Okay. So that we have done in description also if you want you can add some description like this.

[00:23:18]So team once we have given the description we can go to assenee. So assenee is the person who's going to be responsible for MR. For example, let's say developer created the merge request and he has assigned this merge request to a technical lead. So that person the technical lead is responsible for making sure that it is completed on time.

[00:23:36]Review is done and everything is done.

[00:23:38]Okay. So for example, say as of now only I am the part of this organization. So I'll just assign it to myself. Reviewer reviewer is going is going to be the person who is going to be reviewing the code before the merge happens. So again as of now only I'm here. Merge can start anytime. That option you can uh select or you can set up like after schedule date only. But for now, I'll just keep it anytime.

[00:24:03]Then delete source branch. If your requirement is completed uh with respect to feature branch, you can make sure to delete it. Generally in companies, we delete the feature branches. Okay. And then you can click on create mod request.

[00:24:17]So mod request is created.

[00:24:20]You can go to review. Here you can uh provide comment se comments for example you can click on approve and let's say provide I can provide the comment here as review is done code is fine something like that you can write and submit review okay so I have like I have approved the merge request right so once merge request is approved then I can click on merge also Okay. And you can see the status here. It says most that means if I go to master branch then we should be able to see whatever new changes we added. App do.ext test one test two like that. It is done right. Next thing what we want to know we want to set up the squash option as you know combining of the commits before merge happens right. So what we are going to do we are going to go to settings we are going to go to merge request.

[00:25:33]Here in merge request there is a section squash commits merging. Right. So here you can see multiple options available encourage require.

[00:25:43]Okay. So either you can select encourage or require. Both of them will work fine.

[00:25:49]Okay. So if I select require then squash is going to be always performed. If I select encourage then it's going to give us a checkbox making sure that uh whenever merge happens we can click on the button to make sure that squash is also done. So Tim here you can see the options that is available in squash.

[00:26:09]First do not allow that means the squashing is never performed. Allow that means the checkbox is visible and unselected by default. If you want to make sure the checkbox is visible and selected by default you can select encourage. Require squashing is always performed. Okay. So let us go with encourage and let us save this.

[00:26:33]Okay. So these changes should be added now. And now let us go to uh set up a demo for checking out that uh squashing works fine.

[00:26:42]So now let us get started with the squash demo. So since we have merged the feature branch inside our project. So it has been deleted. We'll go back to our VS code right. And as you remember previously we were on VS code and feature branch. But as of now we want to pull the changes from master branch. So I'm going to run the command get pull origin master. It's going to pull the changes that have been added to master branch. So let's wait for this.

[00:27:10]Okay. So pull has been done. Next thing what we want to do, we want to create a new branch which will be squash demo feature branch. So we can run quick uh get checkout hyphen view feature squash demo.

[00:27:23]It has been created from master branch.

[00:27:25]Right. We [snorts] have uh switched forommit. Next thing what we want to do?

[00:27:30]We want to add some new commits. So I'm going to uh add some new line to uh this file app.txt file. So we can run this echo add line one to app.txt. Then add it. Then run the commit.

[00:27:48]That is done. Then we are going to add second commit.

[00:27:52]Similar kind of thing. Uh echol line to app.txt get add dot. Then commit that.

[00:27:58]Right? Then add one more commit three.

[00:28:03]Again similar kind of thing. This time fix typo but again we are doing add these additions to app.txt file and let us do last commit for our feature branch.

[00:28:16]Final change to app.txt and commit the changes. Right. So four commits we have done. Next thing what we want to do? We want to push these changes to remote repository. So we can run get push origin then feature branch name.

[00:28:34]This is done. Next thing what we want to do let us quickly uh check out the commit history for our feature branch.

[00:28:42]So for that we can run get log -1 line so that we can see in proper format.

[00:28:48]And here you can see here add line one add line two fixed typo final update.

[00:28:52]These are like four new commits that we have added to the feature branch. Right?

[00:28:58]So what we are going to do now we have to merge the feature branch to production branch. Sorry. Uh we have to merge the feature branch to uh master branch. So now we will go to our repository.

[00:29:09]We'll go to here settings merge request right.

[00:29:18]And here we have already enabled this option squash commit. So that should not be an issue for us. So once we have already done the settings on the merge request inside settings section, next thing we can loop. Go to code then merge request.

[00:29:33]Then click on new merge request.

[00:29:36]Here we will select the branch.

[00:29:39]Source branch will be squash demo.

[00:29:41]Target branch will be master. Right.

[00:29:44]Click on compare branch and continue.

[00:29:49]Okay. So now we can we want to merge the uh new merge we want to merge uh featur uh features squash demo branch to master branch right. So here let me add this uh this mod master or something meaningful you can write and we can add some description here something like this.

[00:30:16]We will assign it to ourself because as of now only we are available.

[00:30:21]Now you can see automatically squash option is added right. So we will click on create merge request because see there were many commits there were total five commits as you can see here right so we can add review again since we are on free version so it's not mandatory for us to approve it but still we are going to add it okay we are going to approve it as part of best practice submit review and then we are going to merge it right. So that has been done. So as you can see in master branch basically after we have merged the squash demo. So only these two are present but there is no uh there is no uh mention of like added the but whatever like multiple commits we did that is not present because all the commits were squashed. So team I am on uh VS code locally. So as you as you remember that while we merged the feature branch to um main branch feature branch was deleted from the remote repository but actually it is still present here on the local machine. So what we are going to do we are going to delete that feature branch from local as well. So first I'll be switching to uh master branch and then we are going to run the get branch hyphen d the feature branch name to delete it. Right. So now it is deleted from local also. Now what we are going to do, we are going to create a branch uh new feature branch.

[00:32:06]We have created new feature branch. So now what we are going to do, we are going to add some uh changes to the feature branch. Okay. And we are going to push it to feature update uh this update app branch. So I'm going to add changes to this app.txt file. We are going to add it. Run get commit and then push it to feature update app branch.

[00:32:31]Okay, these changes are added now.

[00:32:34]Right. Next thing what we are going to do, we are going to again switch to master branch and we are going to run a get pull command and then we are going to create a new branch.

[00:32:53]So I'm going to create a new branch feature conflict test. Okay. So now we have created new branch and now from that new branch conflict test branch we are going to add some changes to app.txt file similar kind of things that we did previously.

[00:33:12]Okay. Now as you can remember in case of uh this new uh new branch feature conflict test branch we have added in app.txt txt we have added this line conficting change right while in the previous uh feature branch we have added change feature change so these two things are added in the same file right so basically what we have done uh in the uh using two different feature branches we have modified the same file right now what we are going to do we are going to uh we are going to create a merge request for our first feature branch Uh so let us go here go to merge request new merge request and we want to merge the update app to master branch.

[00:34:10]Okay. And I'll just let me just create merge request.

[00:34:18]We are currently merging the changes that were added by update app feature branch. You can see here it says merged block merge block. Why? Because at this point merge has conflict because uh two feature branches have tried to update the same file inside main branches.

[00:34:36]Okay. So here like module is not allowed because you can understand if I go back here we had this app.txt txt file.

[00:34:50]Okay. So in app.txt file this conflicted change this was added by the second feature branch conflicting test branch while the first uh first uh feature branch that we had feature update app it has added feature change.

[00:35:08]So both the branches have added different changes in the same file in the same line. So because of this conflict will appear and merge is not going to happen right. So how exactly we have to fix it? So we have to resolve the merge. We have to resolve the merge conflicts.

[00:35:28]So we have to fix the uh branch issue.

[00:35:30]So you can see currently when I ran the get branch command it shows these are the branches and currently we are on feature branch. Right? So what we are going to do we are going to update this file app.txt txt and when I manually update this file then this becomes the final change. Okay. So I will write something like this. Hello updated by Adita. I'll save this and I will add it.

[00:35:53]So let us do that.

[00:35:56]get add dot get commit m in a message fix conflict get push origin then branch name which is this So changes have been pushed to feature uh update app branch and once you up like push the changes from feature update app branch automatically the issue that was showing here that has been also removed automatically right and you can see now it says ready to merge right so everything is done so either you can set it to auto merge or you can click on uh merge immediately.

[00:36:56]So you can see it's going to merge right.

[00:37:00]So merge is in progress. Actually once it is completed then merge will be done.

[00:37:05]So this is completed. So this is how we make sure key uh if any merge conflicts happen it should be resolved.