I think I have a fundamental [Git] misunderstanding, I don't know why a git merge didn't behave as I expected

[rfalanga]

Select Topic Area

Question

Body

Today I finished making some changes to a Minimal API application and a Blazor application that consumes the API. I've spent a couple days working on this. In my own testing, it worked fine. So, I wanted to merge my child branch, which I'll just call "child", back into the main branch. And I also wanted to make sure that there would be as little for the reviewer to handle as possible, so I wanted to make sure I had all the code up to date, locally, before creating a PR to merge child into main. In the past I would create a PR, to go from main to my child branch. However, I've learned that the command git merge main would do the trick. And since I want to get better at using git, I have changed to using that command.

However, it didn't go well at all. As I said I tested the application on my dev box, and it worked fine. After creating the PR to merge child into main, it complained about some code which wasn't even in my child branch! I spent 20 minutes trying to figure out where in heck that code came from. Some going over the sequence of steps taken, this is what happened starting late last week when I created the child branch:

1. I cd into the main branch.
2. I then issued a get pull, to make sure I was up to date with what was in main
3. I then created the child branch to work on the Blazor app
4. I finished coding and testing the app. It built fine and worked.
5. Next, I cd into the main branch on my machine, and performed a git pull, getting it up to date
6. Git told me that the main branch on my PC was up to date. That there were no changes need in my main branch.
7. Then I cd into the child branch
8. I then issued the get merge main, which as I said I understand will merge all the changes in the main branch, into my child branch
9. After that, I created a PR to get child merged into main
10. A colleague reviewed and approved the changes
11. He tried to build the app, but it failed with issues which don't conform to what I've changed in the API and the Blazor app. In fact, the code it complained about isn't even in my child branch?!

Here's a code snippet to illustrate what the code looked like. Note, this isn't exact. I am home now and don't have access to my work GitHub environment. There was about 10 lines of code, at the bottom of a .razor file, which is now in the main branch, but that same .razor file in my child branch doesn't have that code at all. Here is sort of what it looks like:

    // Some C# code before this

    var response = ApiCall.GetData("api/endpoint<APIResponse>/some-data"); // illustration of how the API is called

    // Some C# code after this

The <APIResponse> is wrong. It should have been something like <APIResponse<SomeClass>>. So, I knew that it was wrong and didn't conform to what I've done.

It must be the case that between the time that I updated my local repo from origin, then created the child branch, that someone else had added that code assigning response to the call to the API. That was how the call to the API was done, but then I added a generic to the APIResponse class.

Anyway, I do not understand why the get merge main did not pull all those changes that were in the main branch, into my child branch, where I could have discovered the problem and worked on a fix, before creating the PR. My understanding of how the merging process is done by git in wrong, in some way. I would really appreciate being told how my understanding is wrong, so I can correct my thinking.

[shinybrightstar]

Welcome to the GitHub Community, @rfalanga, we're happy you're here! You are more likely to get a useful response if you are posting your question(s) in the applicable category. Check out this Guide on how to post in the right category. It'll ensure your questions and discussions reach the right people faster!

This particular discussion belongs in the Programming Help category, I've gone ahead and moved it for you. Good luck!

[rfalanga]

Thank you

[spenserblack]

Based on how I read this I'm assuming that you're not working on a forked repository, but you and the other team member(s) work on different branches in the same repository, is that correct? It's not relevant to the issue itself, but it might be relevant to how you investigate the issue.

First thing I would probably do is check the output of git log on the repository's main branch. Where are your changes in the order of commits? Any changes applied after yours?

I'd highly recommend trying out a git bisect. The idea behind git bisect is that you identify one commit as "good" and a later commit as "bad". In other words, you're saying "I know things were working here, and then they stopped working around here, but when exactly?" What git bisect does is jump to the halfway point between the bad and good commits. Then you run your tests again and label that commit as either good or bad. Repeat a few times, and you should land on the exact commit where things went wrong.

Also, did that colleague merge your changes into main before testing? Were there any merge conflicts that they had to resolve? It's possible that they resolved the conflicts incorrectly and added the bug during the merge.

Overall it seems like you did everything correctly. If you were working off of a fork, the issue might be because you merged origin/main (common name for the fork's remote main branch) instead of upstream/main (common name for the source repo's remote main branch).

[spenserblack]

I spent time figuring out where the cold that was in the main branch was introduced (last Friday) and i had created my child branch earlier in the week, so that explains why I didn't have it in some files.

One thing you might want to try is, instead of git merge main, (which merges your local main into your branch), git pull origin main. That will pull changes from the remote main into your branch. Hope that helps!

[Rod-at-DOH]

I had thought that going to the main branch, then performing a git pull would update the main branch. In fact, it did update my main branch. However, when I then changed to my child branch and issued the git merge main it didn't pull those changes in that file, into my child branch. Sorry, I know I'm repeating myself.

What I see you are now proposing is going to my child branch and issuing the git pull origin main while in my child branch. I could give that a try. I'll create a tag of where I'm at now, in my child branch, then issue that command.

[spenserblack]

What I see you are now proposing is going to my child branch and issuing the git pull origin main while in my child branch. I could give that a try. I'll create a tag of where I'm at now, in my child branch, then issue that command.

Going to your main branch, doing a git pull, then switching back to the child branch and calling git merge main should be the same as doing git pull origin main in the child branch. Sorry, I think I misread your comment earlier. But git pull origin main is a few steps less, and a bit easier to get into a habit of doing IMO.

[Rod-at-DOH]

I've got a meeting with the end users in 30 minutes, so I'm going to wait until later. Perhaps even tomorrow, as I've got yet another meeting (yet another meeting) after the next meeting in 30 minutes.

[Rod-at-DOH]

BTW, I should have mentioned this in the original post. I am working with Git version 2.53.0.windows.1

[Abdumajidov2005]

1. Your workflow and the problem

From your description, your workflow was:

You switched to main and did git pull → local main was up-to-date.

You created a child branch and started working.

You finished coding and tested locally.

You switched back to main and did another git pull → git said your local main was already up-to-date.

You switched to child and did git merge main → this merged your local main into child.

You created a PR → reviewer built the app → build failed, complaining about code that wasn’t in your child branch.

2. What went wrong

Your main misunderstanding is:

“I thought git merge main would automatically bring all changes from main, including any remote commits, into my child branch so I could review them before creating a PR.”

The reality is:

When you created child, your local main was up-to-date at that moment.

Someone else may have pushed new commits to the remote main after you created your child branch.

When you ran git merge main on your child branch, Git only merged your local main, not the remote main.

So your PR didn’t include the latest changes from remote main → reviewer’s build failed.

3. Correct workflow

Before creating a PR, you should always sync your branch with remote main. For example:

git checkout main
git pull origin main # Update your local main with remote changes
git checkout child
git merge main # Merge the updated main into your child branch

Or in one step from child:

git pull origin main # Pulls remote main directly into your child branch

If there are conflicts, resolve them locally.

Now your child branch contains all the latest changes from remote main, so your PR will be safer.

4. Key takeaway

git merge main only merges your local main. It does not automatically include commits that exist on the remote main but not locally.

Always run git fetch or git pull from remote main before merging into your feature branch.

This ensures you see any potential issues (like your error) before creating the PR.

5. Summary

Your understanding wasn’t entirely wrong, but the missing piece is: merge doesn’t pull remote commits automatically.

PR failures usually happen because your local main was outdated.

Safe workflow: always update local main from remote before merging into your feature branch.

[MeNafi]

What you experienced is a fairly common Git workflow misunderstanding. The key issue is timing and synchronization between your local repository and the remote main branch.

From the sequence you described, the most likely explanation is that new commits were pushed to origin/main after you last pulled but before or during the PR process.

Why git merge main didn’t include the code you saw later

When you ran:

git merge main

Git only merged your local copy of the main branch, not the latest state of origin/main on GitHub.

If someone pushed new commits to the remote main branch after your last git pull, your local main branch would not contain those commits yet. As a result:

1. Your child branch merged with an older version of main
2. Your PR was created against the current remote main
3. GitHub then tried to combine your branch with the newer commits that appeared in main
4. That’s why code appeared in the PR that you never saw locally

So the code in the .razor file likely came from a teammate’s commit pushed to main after your last pull.

The safer workflow

Before merging main into your feature branch, make sure your local main is synchronized with the remote repository.

A typical workflow looks like this:

# Update remote references
git fetch origin

# Update your local main branch
git checkout main
git pull origin main

# Go back to your feature branch
git checkout child

# Merge the updated main branch
git merge main

This ensures that your feature branch contains the exact same commits that exist in origin/main before you open the PR.

Alternative approach: Rebasing

Many teams prefer rebasing a feature branch on top of the latest main:

git fetch origin
git checkout child
git rebase origin/main

This moves your work on top of the latest main branch history, making the PR cleaner and easier to review.

How to verify what changed

If something unexpected appears again, these commands help investigate:

git log origin/main
git diff main origin/main

They show whether the remote branch has commits your local branch does not yet contain.

Key takeaway

The important distinction is:

• main → your local branch
• origin/main → the remote branch on GitHub

If the remote branch changes after your last pull, git merge main won’t include those commits until you update your local main.

Once you consistently fetch/pull before merging, situations like this become much easier to avoid.

[Rod-at-DOH]

Thank you for this additional information. It is useful and I'm going to hold onto it.

BTW, personally and professionally, in my work environment, I do NOT like rebasing. The problem we've had here is people will completely replace the whole git history with their own version. It has resulted in not being able to use anything in the remote vs. local, because there is no longer a shared history. Unfortunately, there are some people who are better off working alone, because they don't care about their coworkers. I trust that other people at other companies do a better job using rebase.

[MeNafi]

I completely understand your perspective, and you’re not alone — many teams run into issues when rebasing isn’t coordinated carefully.

Key Points from Your Experience

• Rewriting history via rebase can indeed be destructive if multiple collaborators push conflicting histories.
• This can break the connection between local and remote branches, making merges and PRs much harder.
• In environments where team members work asynchronously or without coordination, rebasing can cause more problems than it solves.

Alternative Approaches

• Merge-based workflows: Using git merge main or feature-branch merges keeps history intact and avoids accidental overwrites.
• Feature branch isolation: Encourage developers to work in isolated branches, merge to main only after review, and avoid rebasing shared branches.
• Protected branches: Enforcing rules on main or develop (requiring PR reviews, no force pushes) can prevent accidental history rewrites.

Context Where Rebase Works Well

• Rebase works best in smaller, coordinated teams, or when used on local-only feature branches before merging to main.
• Many teams combine rebase for local cleanup with merge for shared history, striking a balance between tidy history and safety.

---

Bottom line: your caution is justified. Git workflows are highly context-dependent — what works for one team can be disastrous for another. The key is consistency and clear communication around how history should be managed.

Personally, in larger or less coordinated teams, merge workflows often provide the safest and most predictable approach.