The problem is that branch1 was already merged into master and you have made no changes in branch1 since then.
There's more than one way to proceed.
One way is simply to checkout branch1 and make some change, even if it is just adding a newline, and add-and-commit. Now you can checkout master and merge branch1 into it again.
I presume, however, that when you do that, you'll get a merge conflict on your file test1.txt. Since you know that the branch1 version is right, you can say
git checkout --theirs test1.txt
git add .
git commit -m'merged branch1 again'
That completes the merge, overwriting test1.txt in master with the incoming version from branch1.
However, that's not what I would actually do. I would have done something completely different when I discovered that issue with the original merge. I would have undone the original merge. Don't make a change in test1.txt in master directly; instead, just turn back the clock to before you made the merge in the first place.
To do so, get onto master, and use git log to find out the SHA of the commit just before the merge. Then say
git reset --hard <SHA>
Poof, the merge is gone; Git has no memory that there was ever a merge. Now checkout branch1 again and test the logic, and if/when it's good, switch to master and perform the merge — which you can now do, because branch1 was never merged into master as far as Git is concerned.
(I like this approach best because the resulting story told by the history is accurate.)