The term I think you're looking for is a 'cherry pick'. That is, take a single commit from the middle of one branch and add it to another:
A-----B------C
D
becomes
A-----B------C
D-----C'
This, of course, can be done with the git cherry-pick command.
The problem with this commit is that git considers commits to include all history before them - thus, if you have three commits like so:
A-----B-----C
And try to get rid of B, you have to create an entirely new commit like so:
A-----------C'
Where C' has a different SHA-1 ID. Likewise, cherry picking a commit from one branch to another basically involves generating a patch, then applying it, thus losing history that way as well.
This changing of commit IDs breaks git's merging functionality among other things (though if used sparingly there are heuristics that will paper over this). More importantly though, it ignores functional dependencies - if C actually used a function defined in B, you'll never know.
Perhaps a better way to handle this would be to have more fine grained branches. That is, instead of just having a 'master', have 'featureA', 'bugfixB', etc. Perform code review on an entire branch at a time - where each branch is very focused on doing only one thing - and then merge that one branch when you're done. This is the workflow that git is designed for, and what it's good at :)
If you insist on dealing with things at the level of patches, you may want to look at darcs - it considers a repository to be a set of patches, and thus cherry picking becomes the fundamental operation. However this has its own set of problems, such as being very slow :)
Edit: Also, I'm not sure I understand your second question, about the two scripts. Maybe you could describe it in more detail, possibly as a separate question to keep things from getting confusing?
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…