Merging folders in the same branch in GIT like TFVC

I've been using TFVC on Azure DevOps for a long time and recently was looking at migrating to Git to take advantage of the easy way branches are created and being able to switch between them easily (as opposed to TFVS where you have to check out the whole branch).

TFVS has served me very well and I've got everything setup as I need but I'm finding it difficult in figuring out how this translates to a Git setup.

I currently have a situation where I need to merge the changes in one folder to another folder on the same branch.

This is so Project "A" can have the "Main" features, while Project "B" can have everything "A" has, along with extra features that shouldn't be in "A".

On TFVC, this is as simple as going to Source Control Explorer, right clicking on Project "A" and going to "Branching and Merging", then clicking on "Merge".

A new window pops up, I select Project "B" and click complete.

This merges project "A" with "B" so "B" now has everything "A" has including items specific to "B".

If there's any conflicts, I'll see on VS and can select which values I want to pick easily.

TFVS works well because I have a Shared Project "Z" which is used across Projects "A" and "B" which does NOT need to be replicated.

I'm wanting to get something of a similar setup to this after migrating to GIT, but am unable to figure out how I can achieve this through branching on Git.

I thought the best and cleanest way would be to create a new Repo within the Azure DevOps project. However, I'm unable to select a branch from one repo to another when merging (can only merge within the same repo).

If what I am wanting on Git is not possible - what are the best ways to be able to get this kind of setup?

A plain git repo can't do this really... But you can accomplish similar scenarios in git, but it's not easy.

There are extensions to git, like git submodule and git subtree in which you can "mount" another git repo at a specific version in a master repo. In that case you could merge between branches of the same repo.

Another option is to have multiple forks of the same repo and to merge between the forks. As long as these forks are created from the same master repo, you can merge the contents of the repo between branches of these forks.

There are also tools like gita that can help you manage a folder structure locally that checks out multiple repositories locally and have them be at different versions/branches/tags.

In all of these cases you'll end up with multiple repositories that contain the things you want to version. And then a master repo or configuration that wraps around it.

When creating multiple repositories in Azure Repos, you can either do this using the fork feature to create a merge-compatible copy of the repo. When it's a true fork, Azure Repos will allow you to pull-request between them.

Or you can git clone the repo from repo A and then push that into repo B to allow merges between them. You would then have to do the merges in a local repository that has multiple remotes attached to it.

After trying the solutions suggested by jesse and investigating various different other methods, I've come to the conclusion that there is no easy way to do what TFVS was able to do with merging different folder branches.

I'll write down what has worked for me incase someone else also stumbles onto a similar issue as this as it's working for me (albeit slightly more manual than I'd like).

First, I downloaded a Open Source comparison tool for Windows called "Meld":

https://meldmerge.org/

Using Meld, I compared Folder A with Folder B which showed every changes between the two folders including all files and copied everything needed across using the GUI.

The benefits with Meld was that it allowed me to copy over changes with a click of a button instead of having to manually copy pasting what I wanted.

While it's not as fast as TFVS (which "intelligently knew" what the main differences were between the files and only showed me merge conflicts) this comes at a close second due to the ease of use for me case.