Before I concentrate on how you might use this with Spring Data Neo4j, I will focus on your domain:
I don't think that storing everything on one node will help you in the long run.
Splitting up your nodes let's say in base data where changes are possible but not common (name, gender,...), related data where changes are more common but still not frequent (address) and relate them to a root node with e.g. the employee's number would be the first step I would take.
This does not mean that there are just three types of nodes now but you have to figure this out for your domain. e.g. I would create an address labeled node for itself and not pollute with cooperate data.
Also if you want to keep track of those informations (see below) you could use two types of relationships like
LIVES_AT for address.
With this status-quo you could then look at the things that are more related to the daily business: vacations and performance (I took the latter one from your other post) as two examples.
Those are complete separated domains and as a consequent also based on different use-cases that will then require different endpoints/controller in your application. But the business logic underneath will, in case of a new vacation entry, just create a new node for vacation either related to the root node mentioned above or a more virtual vacations "parent" node.
So you wouldn't need track the changes because they are still in your database but e.g. a vacation from last year is per-se an historical record.
Please keep in mind that this is just a personal suggestion to solve things without any deeper knowledge about your domain and use-cases.