Is this a proper singly linked list?
When possible, use an initializer list:

Node() : rightNode()
{ }




I don't think you're using C++11, but in case you are, use nullptr.



Giving Node a full constructor would be very advantageous for simplifying a lot of boilerplate code.

For example, everything like:

Node&lt;T&gt; *temp = new Node&lt;T&gt;();
temp-&gt;data = data;
temp-&gt;rightNode = startNode;


Could become a one liner:

Node* temp = new Node(data, startNode);


Also, a proper constructor avoids the exception safety problem that user1703394 mentioned.

Just for reference, the Node with a constructor would look like:

struct Node {
    T data;
    Node *rightNode;

    Node(const T&amp; val, Node* rightNode) : data(val), rightNode(rightNode)
    { }
};


Note that the member order was changed since it needs to match the initialization list order. Changing the order allowed the constructor to be more natural (since the constructor argument order should match the initialization list order).



In C++, it's much more common to see T* var rather than T *var. It's just a stylistic qualm, but something to be aware of.



You should have blank lines between your methods.



A non-constant operator shouldn't exist on a list. If you can't provide it in constant time, don't provide it. It's very non-standard, and it's misleading to a consumer of the class. Note that the idiomatic way to expose the data is via a forward iterator.



There's a grave lack of understanding of memory ownership in get. In particular, unless you want the ownership of the node to end, you should not be freeing it.

As a general piece of advice, whenever you have doubts about memory management, consider using something like valgrind.



Try to simplify your code down to a general case rather than having lots of special cases. As others have noted, a sentinel node can heavily simplify this. As a random note, if you do use a sentinel node, and you're concern about performance, try to not dynamically allocate it. That saves you an allocation on an empty list.



Is LinkedList actually ever going to be extended (as implied by the virtual destructor)? Considering all of the properties are private and none of the methods (other than destructor) are virtual, there's not really a meaningful way that you can extend it.



Don't use the implicit private visibility of classes. Everything should be in either a public, private, or protected block. (There's nothing technically wrong with it of course, it's just good to be consistent.) Note that this doesn't apply to structs. Structs are almost always only public, so there's no potential confusion.



Be mindful of what can cause copies. In particular, get can cause an extra copy for no reason. T tempData = temp-&gt;rightNode-&gt;data; creates a copy, and then returning could, in theory--though never in practice--create a copy. If you just return directly, you can avoid a possible copy (though one will still have to happen).



Better yet, should get really be returning a copy? You could be returning either a reference or const reference (depending on if either a const or non-const version of get is called) so that the caller can modify the data, or so that a needless copy can be avoided in the read-only situation.



Your header stuff should have more spacing in it:

#ifndef LINKEDLIST_H_
#define LINKEDLIST_H_

#include &lt;iostream&gt;

using std::cout; // These should not be here!
using std::endl;




#endif /* LINKEDLIST_H_ */


The comment is just useless noise unless you have a lot of nested directives. Considering you only have one, this comment is useless. Also, most modern IDEs make these types of comments useless even if there are a ton of directives since they can highlight the counterpart. (I'm of the school of thought that even without highlighting, if there's enough levels for the comments to be necessary, something is very, very wrong with the the structure of the code.)



There's not a technical need to do so, but it's nice to try to be consistent with the standard library. This allows someone who is using your class for the first time to very intuitively pick up it's use. For example, I would expect size() rather than getSize(). I also might use pop instead of remove.



Sometimes an else clause is less confusing than a hidden return, especially in void functions. For example, the following is much clearer to me:

void pushFront(T data) {
    if (size &gt; 0) {
        Node&lt;T&gt; *temp = new Node&lt;T&gt;();
        temp-&gt;data = data;
        temp-&gt;rightNode = startNode;
        startNode = temp;
        size++;
    } else {
        pushBack(data);
    }
}


I actually had to stop and pause for a long moment the first time I read through your code to make sure you weren't adding twice.



There are a lot of const correctness issues in your code. Please look into it. The short explanation is that any time something is only being read, it should be accepted by const reference.



Consider having each node own it's rightNode. This would mean that instead of a looping destructor, you could simple delete the head node and let the deletion cascade. This would work particularly well with a automatically allocated sentinel node since it would mean you could have a default destructor in the list.



Sized based looping on a linked structure is rather rare. The standard way to do it is to loop on the pointers. In the situations  you've used it though, the uses are arguably just as clear as the pointer case.



Consider keeping a tail pointer. That lets you push and pop to/from the end in constant time.