patch is Larry Wall's program for applying a diff (context diff, unified diff, or even an ed-script produced by "diff -e") to files. Why bother? Well, suppose I give you my program in file a.c. You fix a bug and end up with a patched version fix/a.c. Rather than send me the entire file, you say
% diff a.c fix/a.c > diffs
and send me just the file diffs. With patch, a.c and diffs available, I can generate fix/a.c.
If that were all, patch wouldn't be remarkable (or even particularly useful -- "diff -e" produces a script you can run through ed!). patch has some additional useful features, though. For instance, with the -R switch I can apply the diff in reverse to get a.c from fix/a.c. patch is also careful: if the diffs don't match, it refuses to apply them without some user application of force.
But wait! There's more!
patch's truly amazing ability is to apply the diffs to a different version of the file! For instance, suppose N-Wing has produced his own version of a.c (presumably supporting EJB, XML, Perl/Tk and Python's tkinter). Being the nice spaceship that he is, N-Wing also emails me his diffs. N-Wing's version is based on my original a.c, too, but doesn't fix your bugs. By applying N-Wing's patches to my original a.c, I can get N-Wing's version; by applying your patches, I can get your version. But patch lets me get both additions!
patch can apply diffs to a changed version of the original file. It uses lucky guessesheuristics to identify where the changes occurred, and apply the diffs where they were meant to be. The closest thing is probably the action of a merge -- except that merges have 3 files available, while patch only has 2! Of course, if conflicts occur, patch cannot resolve them; it "rejects" them, leaving them in a separate file for a human to resolve. It's a bit like working with CVS -- except there is no central repository.
Larry Wall wrote patch after writing the then- wildly popular newsreader rn (which popularised the revolutionary UI concept of "just keep pressing SPACE, and it'll do the right thing"). Many people offered patches to rn in the form of diffs, and these were circulated by email and by Usenet. With n patches on a single version, there are 2n possible subversions people might have -- and Wall couldn't support them all. Worse, if a diff was dropped or rejected by Wall, it would become impossible to apply when the next version of rn came out, because all the line numbers were wrong. Wall's patch problem made it possible for each person to accept or reject patches on the original version. By distributing upgrades (also) in the form of diffs, it also became possible to update your version, while keeping in place any private hacks you might have added to make it work on your particular computer.
Wall didn't write rn in Perl. At the time, he hadn't yet written perl. But it does have the feel of a program by Wall: solid, safe, somewhat predictable, and delegating responsibility to the user only when it must. In short -- a UN*X programmer's program.