I plan on creating a feature branch, and in addition to the new commits in the feature branch, I might also make file edits to an older commit in the feature branch through git rebase. Then I plan on merging the feature branch to the master branch.
I tested this scenario with a fake test repo, and I actually got a merge conflict with the rebased commit in the feature branch.
How can I avoid having this conflict at merge time?
You're asking the wrong question. Let me ask you a question: Why avoid the conflict at merge time?
Seriously, I do what you describe all the time, reaching back into earlier commits to improve history thanks to interactive rebase. And as I move forward from there, I always get merge conflicts. So what? I expected them, I resolve them, I move on.
Moreover, working in a collaborative environment, I get merge conflicts nearly every day, particularly in situations where one of us has edited a file and another has removed or renamed it. So what? That sort of thing is natural when many people are working on a project. I expect it. I resolve the conflicts, I move on.
Repurpose your thinking. Merge conflicts are not bad. They are not "conflicts" at all. They are merely Git's expression of a situation where normal merge logic is not sufficient to know what you want so as to perform the totality of the merge automatically. But you know what you want, and resolving the "conflict" is how you tell Git what it is. So just play the game the way Git is asking you to play it, and don't worry, be happy.
So there's my answer to your question, "How merge with master without conflict after rebase in feature branch?" Don't try to merge without conflict. Don't want to merge without conflict. Merge, and if you get a conflict, resolve it.
