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?
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.
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.
No, merging does only affect one branch.
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.
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". […]
Just in case if above link becomes void
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.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With