is this valid git branch behaviour?

Question

So I created a new branch list from master.

git:(master) git co -b list
Switched to a new branch 'list'

Then I made some changes in a file while still in list branch. Then I changed back to master, and opened that file. It shows my changes there as well. Is this expected?

Maybe I am not clear how branching works, but my perception was that it creates duplicate of parent branch(master in this case), then we make modifications in branch(which are not reflected in master) then we merge. Parent(or master) stays as it is.

Please correct me if I am wrong.

Local changes are kept until you `commit` them. So yes, valid behaviour from your description. — Marvin, Feb 13 '16 at 23:13

score 5 · Accepted Answer · edited May 23 '17 at 12:19

5

It shows my changes there as well. Is this expected?

Yep.

The working Directory and the index/stage area are shared at repository level, so unless you commit your changes they will "continue to follow" you regardless on which branch you are in right now (See the image at the end of answer for demo).

Only once you commit them they you can switch to "clean" working directory +clean index.

This is the way git behave.

Maybe I am not clear how branching works, but my perception was that it creates duplicate of parent branch(master in this case)

Git does not create any duplications, When you create branch its simply store a reference to the commit it under a new name located under your .git/ref/heads. The file with the branch name simply contains the SHA-1 which was the previous HEAD in your case.

For example: When you start to work and you suddenly realize that did not ment to work on the current branch but you wish to create new branch instead all the changes are "moving" with you to the new branch. Git store its data inside the repository. When you switch branches you set a new HEAD but the working dir + staging area stays the same.

Here is a demo - creating some files and then switching to a different branch. you can see that the files are "visible" in the new branch as well.

edited May 23 '17 at 12:19

Community

1
1

answered Feb 13 '16 at 23:15

CodeWizard

128,036
21
144
167

Thank you. So, I make the changes in the list branch. Then I commit them there. That commit and the changes will be just in list, right? Or the master will have them as well? – software_writer Feb 13 '16 at 23:23
@akshatKhot: once committed, yes, the changes will only be in that branch. – Lie Ryan Feb 13 '16 at 23:24
Once you commit your changes are in the repository as part of the branch which you committed to. You can always merge/pull/cherry-pick the commits to add them to any desired branch. – CodeWizard Feb 13 '16 at 23:26
In your case they are in list (if you committed them) if you did not commit them they are following you until you discard them or commit them. – CodeWizard Feb 13 '16 at 23:27
Thank you @codeWizard. It worked as expected after the commit. – software_writer Feb 13 '16 at 23:30
Cool. glad to help. Thank you – CodeWizard Feb 13 '16 at 23:34

score 1 · Answer 2 · answered Feb 13 '16 at 23:21

You need to commit the changes first. Git allows you to move between branches with uncommitted changes in your working directory. When this happens, git will try to reapply the uncommitted changes into the new branch.

Git only allow you to move uncommitted changes if it can do it safely, git will prevent you from moving branch if it cannot automatically reapply the changes; in the case that the file with uncommitted changes has changes when moving to another branch, you can "git stash" your uncommitted changes in that case and merge the uncommitted changes.

This behavior is often useful if you start making changes in one branch then realized you actually want to commit them into a different branch or if you have a set of changes that you want to test on multiple branches.

is this valid git branch behaviour?

2 Answers2