Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Git is automatically merging changes from a different branch to master

Tags:

git

git-branch

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 command.

For example,

I created a "dashboard" branch git checkout -b dashboard

then I have made changes in one of my file(say routes.rb) and now I switched to master git checkout master

Now when I open routes.rb, i can see the changes from dashboard branch. Why? Do I have some git settings that should not be there?

like image 429
RubyDubee Avatar asked Nov 13 '11 13:11

RubyDubee


People also ask

How do I stop git from auto merging?

Aborting a Merge If you perhaps weren't expecting conflicts and don't want to quite deal with the situation yet, you can simply back out of the merge with git merge --abort . The git merge --abort option tries to revert back to your state before you ran the merge.

What is auto merging in git?

Git can handle most merges on its own with automatic merging features. A conflict arises when two separate branches have made edits to the same line in a file, or when a file has been deleted in one branch but edited in the other.

Does git merge changes both branches?

No, merging does only affect one branch.

How do I merge changes from branch to master?

First we run git checkout master to change the active branch back to the master branch. Then we run the command git merge new-branch to merge the new feature into the master branch. Note: git merge merges the specified branch into the currently active branch.


2 Answers

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 "[email protected]"  $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.  
like image 99
knittl Avatar answered Nov 08 '22 21:11

knittl


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.

like image 45
Michael Durrant Avatar answered Nov 08 '22 20:11

Michael Durrant