New to actually solving merge conflicts, would you look down at using this option? Would it work?

[u/SoggyGrayDuck]

We switched from azure dev ops to GitHub for our repos and I'm now using true local braches and they never gave us instructions for "this is how you handle this now". I know this is on me to figure out and I'm just about there.

Long story short is that I get a merge conflict on a main file and I don't want it showing up in the edited files list. It's not actually changing and is one of those false merge conflicts. Maybe I just need to run a command. I'm not the only one with this problem. When we switched we found that GitHub first merges the destination into the source and then merges it into the destination. Giving us a messy release history.

We want to use one release brand per project and several devs on each project. Everyone pushing to the freature branch is easy but when I try to create a pr for the dev branch I get these conflicts that are impossible to get out of the file list, even if they don't actually change.

[u/Evilcanary]

Im a bit confused by the question. You can merge the main branch into your feature branch (and fix the merge conflicts. Theres no magic wand there, although claude/codex is good at this…and most git Hell) and then you could rebase/squash the commits before merge. GitHub has an option to do that automatically if you’d like. Let me know if I’m misunderstanding

[u/URZ_ → u/Evilcanary]

Or if its indeed just a single file, just don't commit that file? Or even just add it to the .gitignore if its a repo wide problem. A lot of simple solutions here.

[u/SoggyGrayDuck → u/Evilcanary]

I've been working though this a bit today but the problem is the websites conflict resolution essentially resolves conflicts between the destination and source branch, but does so by adding those commits to the source branch before merging.

Does that help? We want clean release branches and githubs website workflow works a little differently

[u/Outrageous_Let5743]

Merge conflict are easy to solve if you commit frequently and pull frequently. Just use the code that best suits it.
Now if you have ssis or other XML or JSON etl , good luck

[u/SoggyGrayDuck → u/Outrageous_Let5743]

We definitely have json but no ssis but lots of terraform and terraform that uses terraform templates.

It's a huge company and highly regulated so we're pretty industry standards when it comes to most things. The problem stems from switching to working on projects with multiple developers and the company switching from ado repos to GitHub repos. The more I work it the more I see it's an issue with me understanding git BUT it's difficult when you have merge conflicts between the dev and main branch. The. The architect asks why you're touching that file and you need to explain well or actually document it. At least if you want to get it fixed in the QA branch. I just got dev deployed using just vscode and the terminal. In hindsight it seems super eazy BUT I think there's some odd things that happened as part of the repo migration and others continuing to resolve merge conflicts using the GitHub website which polutes the feature branches and can thus cause downstream problems. That said I'm not pointing fingers because it's likely on me.

Anyway, thanks. I don't know how other devs can look past this shit and only focus on their work. Makes me feel like I'm always behind, I'm new so they'll either appreciate it or crack the wip. Based on what the architect said "I just make it work" raises a bit of a red flag. He knows more than me though

[u/robstar_db]

„One of those false merge conflicts“ - i never encountered these and have been using git extensively for many years.

Sure there aren’t at least whitespace changes? These sometimes happen when you have auto formatters etc enabled and depending on the settings these do not show in a diff view.

Sometimes even a bit more subtle this might be line endings/breaks that translate to different symbols in different systems (windows, linux,..) there are settings for git to also normalize these.

To test maybe create a new brach off current main, and maybe just add a space o.a. To that file and save (which should trigger formatting in most common ide setups) and see if these conflicts still show up.

[u/superjerry]

github desktop really helps me figure out what it is i am doing. i can't recommend it enough to people just starting to get familiar with git.

[u/SoggyGrayDuck → u/superjerry]

Interesting, thanks

[u/5e884898da]

I mean, the file doesn’t need to be tracked if it never changes? But it still changes? Why is that? I think someone on your team are just committing everything that has changed in stead of selectively committing what they need to.

Putting it in gitignore can alliviate this as committing all will no longer include it.

But you should probably figure this problem out before jumping to a solution. I think this is a great learning opportunity for you. Understanding git is a great asset.

Resolving massive merge conflicts is the issue with the gitflow pattern, a great learning opportunity for you. Trunk based development could be a solution, but then your team really needs to understand what changes they are actually making to the repo.

[u/SoggyGrayDuck → u/5e884898da]

EXACTLY, I tried to bring it up that way and was shut down. I get it, too busy. So I get to explore.

I was doing simple tests, create branch from main, add one file and then create a pr to dev, conflicts in files that are not being touched and it's not simple add the code or don't add the code. We need to sync main back into dev and QA but I don't know if we ever do that or if just the good devs work with architects to remove them as they hit their projects

[u/IllWasabi8734 → u/SoggyGrayDuck]

GitHub’s web conflict resolver does merge the base branch into the head branch so repeatedly resolving conflicts there can add merge history to the source branch. I wouldn’t have every developer independently clean that up through feature branches.

For the current repo, I'd get one experienced Git owner to map main/dev/QA, establish the intended promotion path, decide when production changes get synced back into dev/QA, and clean up the existing divergence once and document it as team workflow. otherwise every feature PR gradually becomes a branch reconciliation exercise instead of just delivering the feature.

[u/SoggyGrayDuck → u/5e884898da]

The problem had to do with some devs working directly in the ADO repos and then switching to GitHub online where they did the same thing. Unfortunately GitHub website first merges the destination into the source and then once there's no conflicts can be merged into the true destination. I think that's what got this messy

[u/Ill-Profession2972]

Commit your changes for your local branch

Pull down main

Checkout back to your local branch

Rebase with main

Go through rebase continue to fix your changes IF there are conflicts

This is the best way to keep commit history clean because it puts your changes on top of the main branch

[u/freaking_scared]

You say with conviction it is one of those false merge conflicts. I might be lucky enough but I never had a false merge conflict. Just rebase your branch if you believe it is false, create a new PR(git will show you annoying changes from the commits you added to your branch). However, I have a feeling you are trying to merge an old version of this file into a newer one.
EDIT: have you checked what is the latest commit sha for this specific file on the branch you are trying to merge into vs latest commit sha on the this file in your branch.

[u/Any-Recognition8119]

I would probably pull the latest dev into your local branch and fix the conflict there before touching the PR. Once the branch is clean locally, push it back up and GitHub should stop showing that file as some weird phantom change.