Program based on Vigenère’s cipher
Your code is pretty clean and well-formed, but I do have several critiques.
Unexpected behavior
Your program will exhibit unexpected behavior if the phrase entered by the user is longer than GETNAME_SIZE - 2 chars.  In that cases, the fgets() call in getPhrase() will leave the tail of the line unread, and reading should be expected to pick up there in the subsequent getChangedPhrase() call (to terminate no later than the end of that line).  The user will no doubt expect the phrase to be encoded according to the next line they enter, not the tail of the first.
To fix that, you should either arrange in getPhrase() to keep reading through the end of the line.  You can discard characters after the GETNAME_SIZE - 1th if you like, or you can arrange to append them to the phrase (you'll need realloc()).  Just don't leave a tail of the line unread.
getChangedPhrase() behaves similarly when it reads the key, which again could be surprising.  It is not certain to be sufficient to limit the input key length to the message length because you don't necessarily use all of the key characters (you skip those that aren't ASCII letters).  Cutting off the tail of the key can therefore change the result.
This fragment looks wrong:
                if( phrase[i] + pace &gt; 90 &amp;&amp; code[j] &lt; 90)
                phrase[i] = phrase[i] + pace - 26;

I think you mean
                if( phrase[i] + pace &gt; 90 &amp;&amp; phrase[i] &lt; 91)
                phrase[i] = phrase[i] + pace - 26;

See also below.
Flawed implementation
Your code can easily be made to overrun the bounds of the code array.  In fact, that will happen if the number of usable key characters is smaller than the number of letters in the message.  To (partially) fix this, you need to wrap around the end of the key inside the while loop, rather than at the end of the for loop where you now do that.
That will, however, expose another flaw in your implementation: it does not handle the case where there are zero usable key characters.  Your current implementation will just immediately run off the end of the array in that case; after the fix, it will loop infinitely.  See below for a suggestion that will help.
Error handling
getPhrase() does a decent job of noticing when memory allocation fails or nothing is read from the input.  It helpfully returns NULL in those cases.  main(), however, ignores those signals and unconditionally passes the result to getChangedPhrase().  For its part, getChangedPhrase() assumes that its argument is always valid.  Either main()'s behavior or getChangedPhrase()'s could be ok in isolation, but together they constitute a flaw producing undefined behavior under some circumstances.
Similarly, getChangedPhrase() returns NULL in some failure conditions, but main() pays no attention, assuming that the return value is a valid pointer, in attempting to print it.
Implementation improvement
If you have strdup() (which is standardized by POSIX, not C itself) then it is a convenient alternative to strlen() + malloc() + strcpy().
getChangedPhrase() calls fflush(stdout); before prompting for the encoding key.  This is useless.  Move the flush after the prompt, or remove it altogether.  Since the prompt ends with a newline, it is probably unnecessary to flush even after printing the prompt.
I remarked above on problems with your key handling.  I observe also that you handle your key inefficiently if it is short relative to the phrase to encode.  You shouldn't need to check on each pass through the key which characters are usable.  You shouldn't need to account for upper- vs. lowercase on each pass, either, if indeed you make them behave the same way.  Instead, process the key once, before the encoding loop: remove characters other than letters, and convert all the letters to a standard case.  Then it's also easy to validate result to ensure that there is at least one (or two, or whatever) key characters.
It doesn't make sense to me that your encoding code is not parallel for upper- and lowercase key characters.  The code for uppercase keys looks equally applicable to lowercase keys except the computation of pace, but you use a more complicated and difficult to follow scheme for lowercase key characters.  Indeed, one of the alternatives for lowercase keys cannot even be exercised, because code[j] &lt; 90 and code[j] &gt; 96 cannot be true at the same time.
Design improvement
Your function getChangedPhrase() modifies the input string in-place, but also returns a pointer to it.  On the other hand, the function's name suggests that it will create a new phrase.  I suggest changing that function's signature to
void encodePhrase(char *);

to clarify what it's doing.  If you wish to have the ability to signal an error, then you could consider using an int return value to signal the status, following the model of many standard library functions.