Animation issue in "Sniper Gun Reload"
There's no single workaround for this sort of problem.  A lot depends on the parentage arrangement and complexity or otherwise of the reload animation.
If the hand is parented to the weapon (Child = hand) then there'd be little reason not to just animate the hand and clip, particularly if it's only a straight case of shoving it up into the housing.  You'd need to use at least a master parent to ensure the animations are local with respect to the character, weapon and other components.

If the reload animation is complex however you can still do this without removing the original parentage.
and that's what you're looking at in the video clip below...

A second and concurrent 'Virtual parent' is used here which forces the hand to follow the clip up into the holder.  Whilst unnecessary for a straight out 'shove', it was done this way for a demo.
Note - this would only be valid when the gun isn't bouncing around during the reload.  If it is, the primary parentage would certainly have to go and there are at least 4 ways you can do that.
Firstly to explain why the parent structure is important...
In both video clips the lower arm bones (wrists) are targeting empties that are acting as their respective handles with which to move them.  The handles are in fact Inverse Kinematics (rigging) targets for the hands.
Those two empties are in turn parented to the weapon, so it's the latter that drags the hands and arms about, not the other way round.
The weapon and character have their own master handles (parents) and these two again are parented to a common overall Master handle, the cube empty.
This keeps the whole thing together and importantly, all components will be locally related to each other.
-=============-
Method 1 - Concurrent Virtual parent -
For a simple shove as we have above, you wouldn't bother.  You'd simply animate the right hand to stay with the clip but if the clip's actions were more complex, some form of secondary parenting would make things easier.
The right hand's handle (empty) is parented outright to the gun.  When the reload is required the clip is animated on it's own and shoved up into the holder.  The clip becomes a virtual parent for the hand by simply copying it's keyframes axis for axis into the hand's handle. (it's empty)
The hand won't be relocated properly but those keyframes can be dragged
an --&gt; axis at a time&lt;-- up and down in the Graph editor to align the hand to the base of the clip.  (Select all in the editor and press G Y)
Once done the editor's handles can then be used to compensate for any drift (if any) between keyframes.
With the clip in place the hand can be returned to where it was before the load.
After that it's business as usual.
-=================-
Method 2 -  A 'Child of' Constraint -
This can indeed remove it's influence but there's a catch -
Some extra trickery is required to circumvent the hand's jump back to where it came from when the constraint's influence slider is wound back to zero.  Worse, the whole thing can come undone when further physics or a constraint is used on the weapon later.
Experience has taught me to stick to the straight out parentage function (CTL-P) unless specifically needing the advantages of the Child-of constraint.
-=============-
Method 3 -
This one is a little cumbersome but clean and dead stable. It would normally be considered when involved in a very large project.

Split the action between two or more Blend files.

The frames up to the reload would be handled in the first file, the reload itself in the 2nd which will have the right hand unparented, then with the reload complete, a third to continue on with the right hand parented as before.
Each file only renders out the frames necessary and all should be LOSSLESS video using the SAME CODEC.
All three videos can be joined up in the VSE.  The switch-overs are undetectable in vers 2.77

A little more detail -
At the frame where the load is to commence, Save the Blend file as it stands and also &quot;save as&quot; a new filename.
In the 2nd file, remove ALL of the hand's animations and constraints so you end up with a 'frozen' hand as it was in the first file at the exit frame.  This is less troublesome when using a straight out parentage. (CTL-P &amp; ALT-P)
From there, animate the hand and clip as required for the load.  The hand can be directly parented to the clip if desired.
With the clip in place, and at the last frame plus a few, save that and a copy to a 3rd filename.
In the 3rd file restore the original hand parentage and continue on.
Obviously the frame where each file is to hand over to the next should be noted down.  You don't want any twitch or jump.
-==============-
Method 4, Baking -
Baking the hand's action will certainly remove the parentage including a 'Child-of' constraint, and without fuss. Be sure to tick all the bake panel's boxes and enter the correct frame range. (Open the &quot;Object&quot; menu in the window's header and select &quot;Animation --&gt; Bake&quot;)
All previous keyframes that are in that range will be replaced along with any constraints placed on the object.  Physics will have to be switched off manually, and it's two redundant strips left behind in the Dopesheet deleted.  If things go awry when played, save the file, exit Blender and reload to reset the physics cache.