Is the following repository pattern properly applied?
I don't like the underscore in the class name, HR_Repository. It's a generic name for a generic class, which is good, but seeing that it implements IRepository&lt;T&gt; I would expect something like this:
public class EmployeeRepository : IRepository&lt;Employee&gt;

I like that you're initializing your private readonly LoginDataContext in the constructor, from a constructor argument.
private readonly  LoginDataContext dataContext;
public HR_Repository(LoginDataContext dataContext)
{
    this.dataContext = dataContext;
}

I like it because this implementation of IRepository&lt;T&gt; has a dependency on the LoginDataContext - by passing it into the constructor, you're doing constructor injection and that's awesome. Ideally the dependency would be an abstraction (abstract class or interface), which makes it easier to inject as a mock or fake implementation when you're writing unit tests. Even if you never write these tests, the fact that your code would be testable is a very good thing.
I don't like that your static helper provides extension methods to IQueryable&lt;Employee&gt;, it's not clear how/where this code is being used, the benefits aren't immediately apparent.

As for the pattern itself, it looks like a hybrid Unit-of-Work / Repository implementation, because of the Commit method. But your implementation exposes ITable and IQueryable, which leaks out the ORM into the calling code.
If you consider the client as, say, a controller class (assuming MVC), the controller would have a dependency on the unit-of-work, which has a dependency on the data context and lets you work with one or more repositories, which all share the data context of the unit-of-work:

(I skipped UML classes, hope this doesn't look too weird)


Disclaimer
I'm biased. I'm not a fan of unit-of-work/repository pattern, at least not with Entity Framework. I think Entity Framework's DbContext is a unit-of-work, and the IDbSet&lt;TEntity&gt; properties it exposes are repositories - I think wrapping this in another level of abstraction has very little benefits and adds a considerable amount of complexity to the code.
Instead, I simply wrap DbContext with an interface:
public interface IUnitOfWork
{
    void SaveChanges();
    IDbSet&lt;TEntity&gt; Set&lt;TEntity&gt;();
}

public class MyContext : DbContext, IUnitOfWork
{
    IDbSet&lt;MyEntity&gt; MyEntities { get; set; }
    // ...
}

Then I usually have a &quot;service&quot; class that takes an IUnitOfWork dependency; I write closely related queries inside that class, but the &quot;service&quot; only returns materialized results, it doesn't expose IQueryable&lt;T&gt;, even less so ITable. A controller will take a factory that can instantiate such a &quot;service&quot;, wrapping its instance in a using block to ensure proper disposal.