Q: Git revert commit from master but keep in develop I have a unfinished feature developed in master so I cannot deploy to production because of it.
So what I did was to create a develop branch from that master branch and then on master revert the last commit.
Now my question is, when I finish the new feature on develop branch how should I do the merge?
I ask this because in my case I will continue developing new small features directly on master that I will have to merge into develop before merging develop into master.
But if I merge master into develop wouldn't I merge also the revert..?

A: I'd suggest reading through this guide https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
It sounds like you would benefit more from understanding and sticking to a specific git flow rather than me explaining how to fix this one issue you're having.
I would also suggest reading about rebasing here: https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase
Rebasing is a technique which lets you move your commits around before pushing them to an upstrream branch. It can help allot in the kind of circumstances you described where you start working on a feature in branch A but want it on branch B where there are also other changes that don't match up to the first branch.

A: Well, there's a technical answer to the question asked, and there's practical advice for how to do what you're trying to do.
The technical answer is, you've got yourself a situation like this:
A -- B -- ~B -- C -- D <--(master)
      \
       E -- F -- G <--(develop)

where ~B was created by revert of B.
As you noted, if you merge master into develop, then ~B will be brought into develop undoing the changes from B.  Also, if you merge develop into master, the changes in B still won't appear in master because B is already reachable from master.  (In fact, in this example it's the merge base.)
The situation is very similar to what happens if you revert a merge, and the recovery options are the same: 
Option 1: You can "revert the revert" - which I'd do by reverting ~B on master just before merging develop into master, or on develop just after merging master into develop, whichever comes first.  (There are other variations, but that's the one I generally recommend.)
Option 2: You can do a "forced rebase" to create a new commit that "redoes" what B did, but which isn't already in the history of master.
git rebase -f <A> develop

(where you replace <A> by either the ID of, or some expression that resolves to, the commit before the one you reverted; for example
git rebase -f develop~4 develop

in the given example.  You might be able to use git merge-base master develop to help locate the commit if it isn't an easily-counted number of commits back; but remember that in this example you would want the merge base's parent, not the merge base itself.)
Anyway, this would yield
A -- B -- ~B -- C -- D <--(master)
 \
  B' -- E' -- F' -- G' <--(develop)

which would allow master and develop to merge in the expected way.  However, beware that this rewirtes the history of develop, so if you have pushed develiop to a remote where other developers might be sharing it, then this might not be advisable (and requires an effort of coordination at the least; see the git rebase docs).
So that's what you probably should do now, given that you've already done what you've already done.  But the more practical advice is: your needs apparently call for a more sophisticated work flow.  Developing small features on master may "feel" simpler, but it's not saving you anything significant technically and it leads you into problems like this one.
There are many workflows, some simpler and some more complex.  Finding the one that most simply meets your needs is something for you to sort out.  GitFlow is very good but may be more than you really require.  Just using independent feature branches is another option somewhere in between.
