You don't use a hash function to encrypt things. You use an encryption algorithm.
You don't use an encryption algorithm to sign things. You use a signature algorithm.
The text you quote uses to traditional explanation of signatures as "encryption with a private key", which is a very confusing way of stating things, and works only for a specific signature algorithm (RSA), and in fact is wrong and does not work at all for RSA. You'd better forget it altogether.
Instead, let's see how RSA signatures work. The main signature algorithm that is called RSA follows the PKCS#1 standard, and more precisely the "old-style v1.5" method that PKCS#1 calls "RSASSA-PKCS1-v1_5". That method looks like this:
The message to sign is m (a sequence of bits).
The RSA key pair uses modulus n whose length is k bytes. For instance, if the key is said to have length "2048 bits", then this means that 22047 < n < 22048, and k = 256 (2048 bits are encoded over 256 bytes).
To sign the message m, first hash it with a hash function, e.g. SHA-256. This yields a sequence of bytes with a fixed length, 32 bytes in the case of SHA-256. Hash functions are public (no secret parameter) and deterministic (for the same input you always get the same output).
The hash value h(m) is then padded: a sequence of exactly k bytes is built as follows:
0x00 0x01 0xFF 0xFF ... 0xFF 0x00 id h(m)
In plain words, you take one byte of value 0x00, then one byte of value 0x01, then some bytes of value 0xFF, then one byte of value 0x00, then a fixed header (id) that identifies the hash function, then the hash value. The number of 0xFF bytes is adjusted so that the total length (in bytes) is exactly k. This padding process is described in section 9.2 of PKCS#1.
The padded hash value is then converted into a big integer x by interpreting it with big-endian encoding convention. Since the padded value has length exactly k bytes (the same as n) and begins with a byte of value 0x00, it is guaranteed that x will be lower than n (numerically).
The signer uses the private key to compute a number y which is the e-th root of x modulo n, where e is the public exponent (a part of the public key). That is, y is such that:
ye = x mod n
The private key contains some values that make that computation feasible.
The signature s is an encoding of y into a sequence of exactly k bytes, there again using big-endian convention.
To verify the signature, one decodes s into y, uses n and e to recompute x, re-encodes x into bytes, and checks that the resulting string contains a correctly padded hash value, and that the hash value matches that of the purportedly signed message m.
All of the above is deterministic, so if the signer tries to sign the same message again, with the same key, then the exact same signature will be obtained. However, note that:
If a distinct private key is used, then the signature will be different. This is expected: a signature value is specific to a given signed message and to a given signer; otherwise, it would not prove anything.
Though the old-style PKCS#1 v1.5 signature scheme explained above is deterministic, not all signature schemes have that characteristic. Even PKCS#1 includes a "new-style" signature scheme (RSASSA-PSS), that still relies on the RSA modular exponentiation, but with a different padding that includes random bytes. With PSS, the same signer using the same key to sign the same message twice will get two distinct (but equally valid) signature values.
RSA encryption is a different beast, but it is also described in PKCS#1 (in different sections; search "RSAES"). At its core, the same mathematical operation (modular exponentiation) is used for both encryption and signatures, but the padding methods differs a lot, and the padding is crucial for security. RSA signatures really are not a kind of encryption. Also, while RSA signatures and RSA encryption appear to be able to use the same kind of public/private key pairs, there are good reasons not to actually use the same key for signatures and for encryption.