You can use tools like gitk, GitStats, or the GitHub graphs tab for a visual representation of repository activity. However, this is usually a bad idea from a project management perspective.
The Wrong Metrics
In general, measuring lines of code (LOC) or commit activity is the wrong way to measure a software project. You get what you measure, after all; if you assess your team members based on volume, then you get volume, regardless of quality or usefulness.
Just as an example, consider the following Ruby code:
a = b = c = 1
a + b + c
# => 3
However, if my performance review is based on lines of code, you will get:
a = 1
b = 1
c = 1
sum = a
sum += b
sum += c
# => 3
and most likely one commit per line of code. That's a 350% increase in verbosity, a significant decrease in productivity, and no discernible impact on functionality. You will have measured your way to reduced productivity!
The Right Metrics
Generally, you will want to measure the quality and timeliness of your deliverables, rather than changes to the code base itself. From a project management point of view, it's the deliverables that matter most; your key metrics should reflect that, rather than falling prey to the 100% utilization fallacy or mistaking busy-work for progress.
Agile methodologies like Scrum treat tasks as done or not-done. You may want to consider adjusting your work breakdown structure to measure features or tasks that can be treated as checklist items, and assessing the team as a whole based on how often they meet the agreed-upon targets.
As a single example, it would be better to measure "add a function to sum three
variables" rather than "write at least 200 lines of code per day." The first will get you a working function; the second gets you some very pretty graphs that you can proudly display on your wall after the project fails.