Why are changes in one branch visible in another branch?

Question

I execute the following sequence of commands:

git init rep
cd rep/
echo '111' > 1.txt
git add 1.txt 
git commit -m '1'
git checkout -b dev
echo '222' > 1.txt 
git checkout master
more 1.txt 

As a result of these commands I see

222

And I do not understand why. As you can see I create and go into the 'dev' branch. I do some changes there but I do not add and do not commit them. Why after going back from 'dev' to 'master' I do see the changes that I did in 'dev'? Shouldn't they stay in dev until I add, commit and merge them back to master?

Solution 1

All the untracked files does not get impacted when you move in between different branches. As they belong to your filesystem and, GIT is unaware that to which branch these files belong. So when you commit those files, then GIT is aware of which files belong to which branch. And can remove or add files in working area based upon your branch.

Solution 2

This is because you didn't commit your changes to branch dev. So the uncommitted changes is not tied to a parent commit yet.

Do

git checkout dev
git add .
git commit -m "changed 1.txt"

If you want to remove the changes do

git reset --hard master

EDIT

The dev and master branch are pointing to the same commit hash. Have a look inside the folder .git/refs/heads, this is where the branches are stored in seperate files. The content is the commit hash that the particular branch is pointing to. So the branch is simply a pointer to a commit.

In your particular case when you checkout master or dev, they both point to the same commit, and therefore the operation doesn't change the working tree. Otherwise you would get an error. Try changing something on the dev branch now, then you should get an error when git checkout master

Solution 3

As other has guided, either commit your changes or stash them. One simple solution is to stash your changes ( i.e., temporary saved) before checkout. example

git checkout -b dev
echo '222' > 1.txt 
git stash
git checkout master
# on return to dev, restore changes via following
git stash pop

now you are on the old state of documents.

Solution 4

git checkout -b dev
echo '222' > 1.txt 
git checkout master

The changes you operated on the 1.txt file in the lines above are not on any branch because they were not committed (they were not even added to the index).

A Git branch is just a pointer to a commit. When you changed the branch from dev to master you, in fact, didn't change the currently checked out commit. This is why Git didn't need to update the index or the content of 1.txt in the working tree.

Solution 5

The same thing happened to me but adding and committing files didn't help. Then I found out that I after creating the branch locally with checkout -b I must also push the branch remotely:

git push origin [name_of_your_new_branch]

View more solutions

Comments

[ElpieKay]

Changes are made in the work tree. git add stages the changes into the index. git commit takes a snapshot of all the tracked files in the index as a commit. A branch is a ref that points to a commit. In your case, the changes are still in the work tree. The branch doesn't know about them yet.

[Roman]

Your instructions worked well. Now the two branches have different versions of the file and changes made in the "dev" branch are not visible in the master (as I wonted and expected). However, I still do not understand why the changes that I did in "dev" migrated to "master". Isn't the case that not committed changes should disappear or stay in the original branch?

[Alexey Shevelyov]

It is very easy to overlook this - this is simple yet very important point. Thank you!

[smerlung]

@Roman I have edited the question to answer your question

[Wakan Tanka]

but should not git warn you about overwriting the existing file with one from master branch?

[herve]

Yes but when a file is created under a branch, it knows the branch no ?