A git repository can be thought of as a partially ordered set of revisions (where one revision is earlier than another in the order if it is a direct or indirect successor of the earlier one). The partial orders that you get from git repositories tend to have low width (the size of the largest set of mutually independent revisions) because the width is directly related to the number of active developers and the number of different forks any individual developer might be working on.
Based on this background, I would suggest Dilworth's theorem, which states that the width of any partial order equals the minimum number of chains (totally ordered subsets) needed to cover all of the versions. And to make it on-topic for this board, you could also mention the graph matching based algorithms for computing the width and finding a cover by a minimum number of chains in polynomial time.
One way this could be relevant for actual use in Git is in a system for visualizing the version history of a system: most Git visualization systems that I've seen draw time on the vertical axis, and independent versions of the repository horizontally, so this would give you a way to organize the visualization into a small number of independent vertical tracks.
Alternatively, if you want something more ambitious and advanced, try Demaine et al.'s blame tree data structure, which is directly motivated by conflict resolution in git-like version control systems.