Question: Is there a way to work on the same file but on different features/branches in GIT?

I'm sure there is a way but what is the easiest?  

I don't want to stash my changes as that's cumbersome. 

With SVN I was able to work on 2 separate branches as 2 different entities without any intervention and easy to switch between the two.

Answer: 
You seem to be fixated on wanting to do it the Subversion way. I can understand that; changing development habits can be a longish process, and up to a point it may be fine to bend the tools to your own habits instead; that's perfectly fine. So here we go:

Think about it this way: with `svn` you have one big directory tree where "branches" are not really first class entities but (technically) arbitrary subdirectories

```
mystuff/trunk
mystuff/branches/feature1
mystuff/branches/feature2
...
mystuff/tags/1.0   
mystuff/tags/1.1
...

```

So, if you are used this to and happy with it, the exact same solution is possible with `git` as well, by checking out different copies of the repository in one (non-git) parent:

```
mystuff/master
mystuff/master/.git
mystuff/feature1
mystuff/feature1/.git
...

```

This is conceptionally exactly the same as before. You keep the different repositories on their respective branch at all times. You'll have a common ancestor to push/pull to/from for merges, as usual (note that this can well be handled locally, no need for a physically remote location, unless you have one anyways; you can/could also in theory use your `master` repository directly as `origin`).

What you do not get, and will never get with `git`, is committing changes in different branches in one go (under one "commit"). A "branch" in `git` is a fundamentally different thing than in Subversion, the same as a "commit" in `git` is a fundamentally different thing there (commit != revision). You *will* have to wrap your head around this, no tool will save you from that.

Some operations:

* Create a new feature branch `feature2` (starting at `master`):

```
mystuff> git clone {URL-or-filesystem-path-of-common-origin-repository} feature2
mystuff/feature2> git checkout -b feature2

```
* Merge your work from a branch to `master`:

```
mystuff/feature1> git add ... ; git commit ...
mystuff/feature1> git push

mystuff/master> git fetch
mystuff/master> git merge origin/feature1

```

Same for any other merges; the `master` branch is technically no different from any other branches in `git`, it's just a naming convention (like `/trunk` being a naming convention in Subversion).
* Get rid of a branch:

```
mystuff/feature1> git push origin :feature1      # deletes the branch on the common repository
mystuff> rm -rf feature1

```

All of this uses up a bit more HDD storage than necessary; there are advanced ways to clone a repository locally, re-using the object store. Let me know in a comment if that is of importance to you; unless you really have space constraints, I frankly would not bother.
I think, that your workflow might be affected by how slow branch switching is in SVN. In Git, you don't need to worry about this - checkout of new branch will take fraction of second (maybe few seconds for very large projects).

The most sensible thing for you would be to work on single branch and once you will do some commits, `cherry-pick` them to other branch. Example: (let's assume that you want to work on file f.txt, which is identical on both branches)

```
$ git fetch
$ git checkout branch-1 # assuming remote branches exists already
$ vim f.txt # do some editing
$ git commit -am "f file changed"
$ git checkout branch-2
$ git cherry-pick branch-1 # <- this will pick single last commit from branch-1
                           # and apply it to branch-2

```

You are not limited to picking last commit, of course - you can pick by commit id, tag, you can use `~` operator to select commit ancestor, etc.
You can even do many cherry-picks at once by rebasing or, even nicer, interactive rebasing.

After your work is done, you need to do two separate pushes per branch (or you can change your `push.default` config option to `matching` to do one push from all local branches).