Git is automatically merging changes from a different branch to master

Question

I am having an issue with Git branching. Whenever I make changes to a branch, all those changes get reflected in master branch even though I haven\'t invoked explicit merge

Answer 1

When you are editing files in your working directory, you are not editing "git" files (of any branch or master) at that point, you are just editing your local files, or "working directory" as it's called.

The "git" files (stuff that you have committed) are all in the .git directory. The layout matches your folders and this is where branches are also stored. Sidenote: it stores the actual files(compressed) unlike version control tools like svn that store the delta(difference)

So when you are editing a file you are not actually editing either master or branch, you are just editing the file. If you don't commit but then switch branches you will still have that file, and its changes will be visible even though you have 'switched' to the new branch. This is what usually surprises people initially.

The best advice here is to commit / ignore / discard all your changes before switching branches to avoid these issues. Also tools like gitx (Mac)m and gitg (Ubuntu) make these tasks easier for those whom like gui's and they also have good warnings about such issues.

At any point in the above git status is very useful and can tell you what is not currently committed to any git repo (whether it be master or branches)

gustavotkg also gives good advice using git stash for these issues.

Answer 2

If you need to switch to master branch without commiting the current branch you can use git stash

git stash # all changes will be queued
git checkout master
# do whatever you need in master
git checkout dashboard
git stash pop # get all changes queued back to branch

Answer 3

When you make changes, those changes only exist in your working tree up until to the point when you commit them.

When you switch branches, Git will carry changes in your worktree over to the new checkout. This is often helpful when you notice that you were working on the wrong branch.

There's even a recent discussion about this “unexpected” behavior on the Git mailing list about this. To quote Junio:

"J.V." gmail.com> writes:

OK so "work tree" is a new term for me. I thought we were in isolated sandboxes called "branches" and changes made in a branch would stay in that branch regardless.

Do not think of "branches" as isolated sandboxes.

Rather, "branches" are where the independent states are to be recorded.

The recorded states only exist in the git repository, and to use its contents (e.g. view in the pager or browser, edit in the editor, run the compiler on,...), you need to materialize the contents of the branch somewhere on the filesystem. Such a set of files on the filesystem form the working tree. The act of doing so is called "checking out a branch". […]

---

Edit

Just in case if above link becomes void

Problem

Unexpected git behaviour 

--- 
# First create a local git repo 

$mkdir gitexample 
$git config --global user.name "my name" 
$git config --global user.email "me@me.com" 
$git init 
$git add . 
$git commit -m 'initial commit' 

# Create/Edit an empty file 
$vi readme.txt 

# add a single line: "this was added in the master branch." 
$git commit -a 

# create and checkout a new branch (from master) 
$git branch test 
$git checkout test 

# edit the readme.txt file and do not commit 
# add the text:  "this was added in the test branch.", save and exit 
$vi readme.txt 

#now switch back to master 
$git checkout master 
$cat readme.txt 

#You will see both lines in the master.   

Question #1: 
        Why was this line added in the *master branch? 


--- even further surprising 
In the master branch, now do a commit 
$git commit -a 

cat readme.txt ( you will see the line in the master now that was added in the test branch ) 

Question #2: 
        Why did this happen? 

# Now switch back to the test branch 
$git checkout test 
$cat readme.txt 

You will only see the one line: "This was added in the master branch" 

Question #3: 
        Why did this happen? 

and NOT the line added in that branch: "this was added in the test branch" <= this line is gone 

What is the reason for this? 

1) Why do I see uncommitted changes in the branches made off master in the master branch? 
2) Why, if I commit them in the master, do the disappear in the branch in which they were made? 

This is confusing, I would think the * master branch would be left untouched.  This would solve issue #2. 

Reply

On Fri, Nov 11, 2011 at 12:55:04PM -0800, Jvsrvcs wrote: 
> Unexpected git behaviour 
> 
[ ... switch branches with local modifications ...] 
> #You will see both lines in the master.   
> 
> Question #1: 
> Why was this line added in the *master branch? 
> 

It wasn't. that line was added in the working directory. When you 
switch branches, if the file in the tip of the current branch and the 
file in the tip of the target branch don't differ, it's safe to keep 
your local changes, so git does. This is to support the use-case where 
you start editing a file when the wrong branch is checked out and want 
to change to the right one. 

> 
> --- even further surprising 
> In the master branch, now do a commit 
> $git commit -a 
> 
> cat readme.txt ( you will see the line in the master now that was added in 
> the test branch ) 
> 
> Question #2: 
> Why did this happen?
... [show rest of quote]
... [show rest of quote]
Because you told git to commit the file with that modification in it. 

> 
> # Now switch back to the test branch 
> $git checkout test 
> $cat readme.txt 
> 
> You will only see the one line: "This was added in the master branch" 
> 
> Question #3: 
> Why did this happen? 

Because the file in the 'test' branch only has that line. As you said 
yourself, you edited the file but didn't commit. 

> 
> and NOT the line added in that branch: "this was added in the test branch" 
> <= this line is gone 

Again, that line wasn't added in any branch but in the working 
directory. The active branch was 'test', but doesn't magically mean 
that uncommitted changes travel with it.