Morphisms are a generalization of the idea of a function or transformation within the context of category theory. The name is a sort of reverse portmanteau abstracted from such mathy words as homomorphism, isomorphism, and so on. They are also called arrows, but this name is not as evocative and has been overloaded by functional programming to refer to a special kind of morphism. So I will stick with 'morphism'. The notation for describing morphisms is stolen from the notation for functions. If A and B are objects, then f : A→B would be a morphism from A (its domain) to B (its codomain).
By the category axioms, every object in a category has a special morphism often written as id* : *→*, where * here stands as a wildcard for any object. This is called the identity morphism. It is often a useful way to indirectly refer to an object, much as pointers are used in computer programming. The second category axiom states that when there is an arrow whose codomain is the same as another arrow's domain, one can always find an arrow that goes from the first arrow's domain to the second arrow's codomain directly. This operation is called composition by analogy with the composition of functions, and is written with the same notation. If f : A→B and g : B→C are two morphisms in our category along with the objects A, B, and C, then there's also an arrow h : A→C that is traditionally written as "g · f" or, more confusingly, "gf". Below is a figure of the situation.
A
|.
f| .
| . h!
| .
v v
B--->C
g
This notation, for obscure historical reasons, forces one to read morphisms from right-to-left in order to realize the order of composition. So "g · f" is "Do f, then g". It's also a bit trying in HTML to find a good substitute for the open middle dot used in LaTeX. Therefore, I will adopt the somewhat non-traditional notation invented by Dijkstra and write "f.g". As a added bonus, this permits longer, more descriptive function names: takeNap.fireMissiles is more descriptive than f.g. Apologies to those programmers who come from languages where the dot operator means 'access object/struct member'.
The most relevant feature of a morphism is that it preserves, in some sense, the structure of whatever the objects of the category are supposed to be about. So if our category's objects are the working states of an industrial robot's manufacturing process, we should only consider as morphisms the ways in which it can get from one state to another and forget about what happens when the poor thing breaks down. As a rule of thumb, if one wants to define a category over a bunch of objects of the same type, letting the morphisms simply be whatever functions preserve that type tends to be enough to satisfy the requirements of the category axioms.
There are several special kinds of morphisms: epimorphisms, monomorphisms, isomorphisms, inverses, and zero morphisms.