The git plugin presents a user interface and implements most of the Jenkins git use cases, including things like choosing which branches to monitor, polling for changes, publishing changes and tags, ignoring commits based on message content or submitter, remembering reference repositories, remembering timeout values, etc.
The git client plugin provides a git SCM abstraction and allows the user to select one of two implementations, either command line git, or the pure Java JGit implementation. It is called by the git plugin (and by other plugins which need git functionality). The git client plugin was created as a result of the refactoring which created git plugin 2.x. The git plugin 1.x code was hard to maintain, so Kohsuke Kawaguchi, Nicolas de Loof, and others created the git plugin 2.x implementation, with the git client plugin extracted as a git SCM API.
If the command line git implementation is chosen, then the command line git installed on the slave which executes the job is used to perform the git operations. If the JGit implementation is chosen, then git operations are performed within the Jenkins process.
The command line git implementation is the "reference implementation". It has the most features, and seems to be the most frequently used. There are a number of limitations in the JGit implementation which don't exist in the command line git implementation. Those use cases which it implements are generally as capable as the command line git implementation. There is a little more information on command line git vs. JGit at
https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin#GitPlugin-WhyNotJGit .
Mark Waite