Two Git branch names pointing to the same branch?

Question

I've created a bare git repository ("Core"), cloned from a pre-existing repo ("Production") using gitflow. I've cloned that bare repo again into a non-bare repo ("Staged"), then re-initialized git flow in Staged (because it seems that gitflow didn't come across when I cloned the bare repo?)

But I've just noticed something odd. Let's say I am in the staged repo, on the develop branch, and edit a text file (test.txt). I run git status and it tells me that test.txt has been modified. Awesome.

Now, I do not commit or merge, but I checkout master using git checkout master, then I run git status again and it says that test.txt has been modified!

Correct me if I'm wrong, but any changes I make on the develop branch should not effect the master branch at all right? This leads me to believe that my "master" branch and "develop" branch are actually the same branch.

Clearly I've made an extremely silly mistake somewhere along the line, but where? No idea. Has this happened to anyone before? Any pointers on diagnosing the issue here? Does any silly mistake that I could have made spring to mind to anyone?? Is there a remedy?

(I'd like to point out that I do, in fact, need a develop and master branch)

Update After committing changes on my develop branch, the result is that master does, in fact, return to it's correct state and that develop is now in the updated state. I'm starting to feel that perhaps this is just how git behaves?

Answer 1

With git, there are three important areas: the repository (where all versions are kept), the staging directory, and the working directory. The staging directory is where you stage your changes before you commit (or where files go when you issue "git add" commands). The working directory is the set of files you see in your checked out repository.

Branches are simply pointers to repository snapshots. When you swap the active branch, git tries to preserve changes in the staging and working areas, and change all the files in the working directory to the snapshot pointed by the branch. If it cannot do this safely, it tells you to stash your changes. I haven't experimented with staging area conflicts, because I tend to commit the contents of the staging area before I swap branches.

In your particular situation, you modified your working directory, then swapped branches. Since the modifications are not committed (or added to staging area), when you change your branch, git simply reverts the working directory to the master branch, and preserves your uncommitted changes. This allows you to commit the changes to a different branch if you want to.

Answer 2

As mentioned in the linked question, your changes are not "part of" any branch until you commit them. Until that point they are only changes in your working copy, and as such git will try and keep them around as much as it can