A side effect of Git, when using a local repository, is that it changes the way commits are handled in the system. With CVS, you will need to handle conflicts first (if someone else changed something before you pull to update your working directory and resolve issues). Having done this, you can commit your changes to the CVS repository. This is called merge-before-commit. Git works entirely differently, since commits are always done in the local repository. This commit-before-merge strategy means that you merge changes after the commit, and it is also possible to ask the other developer to merge and resolve issues. It can get harder to distinguish changes between commits if there are many merges, but to retain a nice linear history, it is also possible to mimic CVS behavior by using the Git rebase mechanism (git pull --rebase) in which you apply changes on top of the updated state.
The last big difference is in the way people collaborate with each other. Some developers only need a read-only copy of the original software, but they need anonymous read-only access to the source code. Both CVS and Git can accommodate this. Things become different if people want to contribute something back to the project. With CVS, one way of doing this (like with the Linux kernel) is by sending patches via email. This is done by people who change a small amount of code. With Git, it is actually very easy to execute your changes on top of an existing upstream version and then generate an email with git format-patch. With bigger contributions, the functionality and ease of a pull request become important, and this was what Git was designed for. All of this happened because of the snapshot paradigm.