Let Me Tell You About Patches
Let's break this down real simple, all a patch is is a file that documents changes to files. Don't believe me? According to Drupal.org:
A patch is a structured file that consists of a list of differences between one set of files and another.
That's right, it's a file that lists changes to your files--and yes the redundancy is intentional. The idea is someone can change some files from state "A" to state "B" and make a patch that tracks said changes. Then a program such as patch or git can read the file, make sense of the changes it's tracking, and apply them and someone else can confidently make the same changes to get their files from state "A" to state "B".
In a worst-case scenario you can even apply patches by hand, but I recommend against it because it's not reliable and you're doing yourself a disservice by not learning how to apply patches.
When Will I Need to Use a Patch?
Maybe never, but unless you plan on building the most boring site in the world you're going to end up needing to patch one or more contributed modules. A common scenario is that a user of the module has found a case where a module doesn't work as expected and someone has posted a patch in the Drupal.org issue queue.
Another common usage of patches applies to developers deploying changes to live sites. We can argue about the merits of allowing changes to be made on production servers but sometimes it happens and those changes need to be captured. If you're using a service like GitHub or BitBucket you can use deployment keys, which provide read-only access to the repository.
So if you've got some changes queued up and can't push them into the repository, what do you do? Easy. Create a patch, apply it on a development environment or somewhere that can push into the repository, then push it into the repository.
I hope this has cleared up any confusion you may have had about patches. If you're looking for details on how to make and apply patches, let me direct you to the Drupal.org documentation.