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: 
use the git worktree.

***`git worktree`***
====================

Git worktree was introduced in 2007 under the `contrib` folder in the git repo and was called `new-workdir`. 

In **git V2.5** it was named `worktree` and it allows you to have multiple instances of the same repository across different folders.

for example:

```
git worktree add <second path>

```

will create another folder on your computer which allows you to work on different branch simultaneously.

---

If you want to remove the worktree, delete the folder and then execute `git worktree prune` which will remove the worktree reference.

> 
> ***`prune`***  
> 
>  Prune working tree information in `$GIT_DIR/worktrees`.
> 
> 
> 

### Creating new worktree

```
# create new branch inside the worktree folder 
git worktree -b <branch name> <path>

```

### Removing worktree

```
# do your code and once you have done 
# commit, push and now you can delete your folder
rm -rf <path>

# Tell git to remove the workdir copy
git worktree prune

```

**Update**
In the coming versions (git 2.17+) a `git worktree delete` will be exposed as a new command for deleting worktrees.

### Listing worktree

[![enter image description here](https://i.stack.imgur.com/PCngz.png)](https://i.stack.imgur.com/PCngz.png)

---

If you use rebase later on:

* Note: ([Since Git 2.7](https://github.com/git/git/blob/master/Documentation/RelNotes/2.7.0.txt))  

you can also use the `git rebase [--no]-autostash` as well.
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.