git doesn't care much about files; it cares even less about folders. What's actually happening here is that you have some commits which git doesn't think need merging. That's because, as far as git is concerned, you already merged them.
The key point here is that reverts don't record what commit they're reverting; each time you run git revert, it just creates a new commit which is like a mirror image of the original. Lets say you create commit abc123, then run git revert abc123: that creates a new commit, def456, which undoes the changes of abc123; but it doesn't undo the existence of commit abc123 in that branch's history.
Let's say your original change was commit b1b1b1, and abc123 was you merging it to release; your history might now look something like this:
release
|
v
+---------<* abc123 <- def456
/ /
... <- 000aaa /
\ /
<- b1b1b1
^
|
my_branch
Now, whenever you try to merge "my_branch" into "release", git will look for commits which don't already exist on that branch. The commit abc123 is still part of the branch, and since that records b1b1b1 as its parent, b1b1b1 is part of the branch as well. So a merge will simply skip that commit - it doesn't know that you've later reverted the changes.
So, you need to "revert the revert" - see How do I "un-revert" a reverted Git commit? and How can I fix a reverted git commit? and probably lots of other similar questions.
In this case, if you run git revert def456, you create a third commit, 789aaa, which undoes the undoing - in other words, it recreates the original changes from commit abc123. If you think of a revert as a mirror image, then reverting a revert is a mirror image of a mirror image - the same as the original.
Given the diagram above, we might first merge "release" to "my_branch", so that abc213 and def456 are on that branch. That way, we have somewhere to put our "revert of the revert" without committing directly on "release". Then when we revert def456, the result is this:
release
|
v
+---------<* abc123 <- def456
/ / \
... <- 000aaa / \
\ / \
<- b1b1b1 ---------------------<* c2c2c2 <- 789aaa
^
|
my_branch
Now if we ask git to merge "my_branch" into "release", it looks again for commits that don't already exist on the target branch. In this case, it finds commits c2c2c2 (a merge commit with no changes) and 789aaa (the reverted revert).
release
|
v
+---------<* abc123 <- def456 -------------------*> 999fff
/ / \ /
... <- 000aaa / \ /
\ / \ /
<- b1b1b1 ---------------------<* c2c2c2 <- 789aaa
^
|
my_branch
In all of these, what git is applying is a change: creating a file is a change, and the mirror image of that is deleting the file; adding a line in a file would also be a change, and the mirror image would be deleting that line. There's no way to simply "remind git that a file exists" - if you try to make a change in the "missing" file and merge that, you'll get a conflict, because there's nowhere for that change to be made.
The bottom line is this: to re-create the files on the release branch, you need to create a new commit which creates those files.
That commit needs to be on a branch where the files don't already exist, so in your situation I believe you need to:
- Merge "release" into "main": it is currently ahead of "main" because of the accidental commit, and the commit where you reverted it.
- Once that's done, the files will be deleted on "main". To get them back, you need to revert the revert.
- That will essentially create a new copy of the original change, recreating the files.
- Merging "main" into "release" will now create the files, as you want.
