Singly-linked list implementation
Let's answer your questions first:

What about the memory issues?
If you are not limited to an older C++ standard in any way, it would be the best to use C++11 (or above), since it provides you with a good implementation of smart pointers (reference, in-depth-tutorial). This way, all your memory management becomes easier and more resilient. Also you do not need to manually delete anything and do not run into trouble if someone else is still accessing the element you just removed.

Caution: Smart pointers and raw pointers do not mix very well, so avoid raw pointers whenever possible.

What about type definitions?
In general, many people nowadays do frown upon typedefs. Firstly, they hide the actual composition of the type and may lead to confusion or wrong assumptions - especially in team projects. Second, in C++ you do have the using keyword which is a better choice here, especially since it can be combined with templates. (reference)

What functions should be provided?
If there is a push_back I would expect some kind of pop_back (also a push_front). Usually you have some methods to give you the number of elements in the list, check if the list is empty... You can take Qt's QList class as an inspiration ().

Suggestion: make node a templates class
Defining the inner class list&lt;T&gt;::node is valid code and gets the job done. However, you may find that it would be more convenient to pull it out of the list class and define a stand-alone class node&lt;T&gt;. A list&lt;T&gt; then contains a node&lt;T&gt;. Depending on your design, you then might find that your node class then is re-usable e.g. for queues.

Recommendation: Use namespaces
Namespaces are your #1 tool to structure your code. At least one level of namespaces should be used at all times to avoid cluttering the global namespace.

Suggestion: use #pragma once
If your compiler supports it, this is a good alternative to the include guards. Just put it into the first line of your header and you are good to go. 

Hint: inline is not that important
First, do not waste brain capacity on whether to inline something while developing. Early optimization suffocates progress, diverts attention, and thus kills projects. Get it to run, then optimize one step at a time. Second, modern compilers know best what to inline and what not. Let them do it, they are really good at this. While learning, trust your compiler. You can argue with it later :)

Additional note: Combining templates and inline is used to address issues with the One Definition Rule (ODR). If you define a template, but do not fully specialize it, you may (but do not need to) inline. However if you do also want to provide a fully specialized case, you have to inline, otherwise you conflict with the ODR, since the compiler expands the template and thus already provides an implementation for the case you intended to cover "by hand". See also this question for details and examples. (Kudos to @Cody Gray)

Wrapping things up
I just sketched together a piece of code that sums up the made suggestions/ recommendations to give you an orientation (Note: I prefer the Java-style of camel-casing the type names with an initial upper case letter, but this is a question of personal preference).

#pragma once

#include &lt;memory&gt; // for smart pointers

namespace collection {

template&lt;typename ValueType&gt;
class Node&lt;ValueType&gt; {

private:
    ValueType _data; 
    // alternatively store a smart pointer to the data 
    // if the amount of data is large e.g. an image
    std::shared_ptr&lt;Node&lt;ValueType&gt;&gt; _next;
    // to "delete" the next pointer just reset it to nullptr
    // only hand out the shared pointer, never the thing it points to
    // the receiver has to check if the pointer is null before use
public: 
     //... you know what to do
};

template&lt;typename ValueType&gt;
class List&lt;ValueType&gt; {

private:
    std::shared_ptr&lt;Node&lt;ValueType&gt;&gt; _head;
    // you can also keep track of the tail and whatever...
public:
    // ... all the functions
};

} // end namespace collection


Last but not least
Put your code somewhere accessible (e.g. github) which makes it easier to review code, suggest concrete changes, discuss details, and notify you about the bugs and issues that were found. Post a link and I will have a look at it :)