1

I have read the official git checkout documentation and some questions here and haven't found an answer to the behaviour I'm seeing.

Locally, I have a dev branch. From within the dev branch, I create a new feature branch

git checkout -b myBranch

Then, I add a new file

echo foo > myFile.txt

If I immediately go back to the dev branch

git checkout dev

the myFile.txt is already there, even though

1) I did not stage the file 2) I haven't merged the branches

My expectation is that any changes I make to the files while in the feature branch will not propagate over the other branches.

Why is this happening?

Pablo Gonzalez
  • 1,710
  • 3
  • 21
  • 36
  • 1
    If you don't `commit` or `stash` the changes then the changes will go the branch you checking out – Sajib Khan Feb 13 '19 at 13:48
  • I confirmed this to be the expected behaviour, thanks @SajibKhan – Pablo Gonzalez Feb 13 '19 at 13:57
  • To add to the previous two comments, `myFile.txt` is not in branch `dev` yet either, it's just in your sandbox, untracked. Even a `git reset --hard` won't touch untracked files. The only command I know that touches untracked files is `git stash --include-untracked`. – joanis Feb 13 '19 at 14:19
  • @phd that's not really the right duplicate, but I can't find a good one. – torek Feb 13 '19 at 17:01
  • @torek https://stackoverflow.com/a/246285/7976758 – phd Feb 13 '19 at 17:13

2 Answers2

3

E.Omar's answer is correct (and upvoted), but it's worth emphasizing that your work-tree—the place where you see, and work with, your files—is not a branch. It is not a commit, and it will not be preserved! It is merely the place where you do your work.

What will be preserved—forever, or as long as the commit itself exists, anyway—is the complete snapshot that you make when you make a new commit. But this snapshot is not a copy of your work-tree at all! Instead, it is a snapshot of what you put into Git's index.

The index—which is also called the staging area or sometimes the cache—is a complicated thing, but it is, I think, best thought of as: All the files that Git will put into the next commit that you make, when you make it. It starts out being a copy of all of the files saved in the commit that you checked out when you ran git checkout name.

If you create a new file in your work-tree, or after you have modified an existing file, nothing has happened to the index. It's still a copy of what was in the commit. Running git add tells Git to copy the file from the work-tree into the index, making it ready to go into the next commit. Until then, it's just a file in the work-tree: an untracked file, if there's no copy of it in the index.

See also the answer that phd linked-to in a comment on the question Modified files in a git branch are spilling over into another branch (which we've used as a duplicate for a closer for this question). Note that causing the new file to become tracked (by git add-ing the new file) is not sufficent: you must also run git commit to make a new commit that contains a frozen-forever copy of the file (plus, of course, all the other files). Until then, it's just an untracked or tracked file, but not in any commit.

torek
  • 448,244
  • 59
  • 642
  • 775
1

This is happening because you created the new file while you are on the new branch but you haven't tracked it. Therefor the new file isn't only exist on the new branch, instead it belongs to the working directory and not to any specific branch.

E.Omar
  • 109
  • 1
  • 11