Different Git branches seem not to work independently

Question

Here an experiment to make me understand how branching works on Git. First of all

mkdir gitEx

Then I put a file named thatsAFile inside it.

Next steps are its initialization and the verification of its status

git init
git status

Which shows thatsAFile in red.

Next steps are adding and committing.

git add .
git commit -m "that's a commitment!"

As far as I understand, once I did that, I have a local branch.

Now I want to modify the project with a good backup, which means I want to generate a new branch and I'm going to move to it

git branch newBranch
git checkout newBranch

And I put a file named thatsSecondFile inside the gitEx folder. Of course, the command

git status

Provides the thatsSecondFile in red, and I believe that adding and committing is done ONLY on the newBranch, but from my experiment its not like this and that's my problem!

git add .
git commit -m "message"

so I type

git checkout master
git status

and I expect that thatsSecondFile to be in red, but the software answer is "On branch master

nothing to commit, working tree clean"

Which may means the two branches are exactly the some.

What's wrong with this?

Furthermore, if I type ls on master branch, than I find ONLY thatsAFile and if I type ls on newBranch, than the ls command provides both thatsAFile and thatsSecondFile. So, from this point of view it looks like working.

Finally I go to the gitExp with the graphical tool (not via terminal) and there is not the thatsSecondFile.

All this stuff is confusing me. Can someone explain to me what's going on?

Answer 1

Let's go through step by step...

First of all

mkdir gitEx

Then I put a file named thatsAFile inside it.

Next steps are its initialization and the verification of its status

git init
git status

Which shows thatsAFile in red.

More specifically, it will show it under the heading "Untracked files", meaning "files that are lying around on disk, but don't have any existence in your git repository".

"git status" shows quite a lot of information, it's worth reading all of it, not just looking at the colour coding.

Next steps are adding and committing.

git add .
git commit -m "that's a commitment!"

As far as I understand, once I did that, I have a local branch.

Correct. The first command does two things: tell git you want it to track the file, and tell it you want to include the current content of that file in your next commit.

The second command creates a commit, with a snapshot of your whole directory.

Now I want to modify the project with a good backup, which means I want to generate a new branch and I'm going to move to it

git branch newBranch
git checkout newBranch

It's important to note that this creates a new branch from what you currently have checked out. So "all" the history of master (your first commit) is part of this branch too.

And I put a file named thatsSecondFile inside the gitEx folder. Of course, the command

git status

Provides the thatsSecondFile in red

Again, look at the labels not the colours: "Untracked files".

and I believe that adding and committing is done ONLY on the newBranch

git add .
git commit -m "message"

Correct. More specifically, it will track the file, and add it to a new commit. That commit is a snapshot of the current state of your directory, with both test files in it. The current branch ("newBranch") is then pointed at that commit, while your other branch ("master") stays pointing at the first commit.

so I type

git checkout master
git status

This looks at the branch "master", looks what its current commit is, and then makes your working copy match that commit.

and I expect that thatsSecondFile to be in red, but the software answer is

"On branch master

nothing to commit, working tree clean"

Which may means the two branches are exactly the some.

What's wrong with this?

Nothing is wrong. "git status" is telling you that there are no changes which you have made which are not committed. It's not comparing "master" and "newBranch", it's comparing the files that exist right now with the files snapshotted in the commit you have checked out. Since you just checked out the branch, and haven't made any changes, it tells you that you haven't made any changes.

Furthermore, if I type ls on master branch, than I find ONLY thatsAFile and if I type ls on newBranch, than the ls command provides both thatsAFile and thatsSecondFile. So, from this point of view it looks like working.

Correct, this is exactly what's happening: when you check out "master", "thatsSecondFile" doesn't exist, because it didn't exist in the snapshot for that commit.

Think of it this way: when you switch from "newBranch" to "master", git clears away all the things that it knows are part of the snapshot you made on "newBranch", and then it puts in places all the things that were part of the snapshot on "master".

The whole point of version control is that you can say "make my directory look like it did at this previous moment".

Answer 2

"On branch master nothing to commit, working tree clean"

Which may means the two branches are exactly the some.

No, it doesn't mean that they're the same, it means that there's nothing in the working tree that differs from what's committed in the branch. But the commit history in the two branches will be different: your newBranch and master will each give different answers if you run git log.

Furthermore, if I type ls on master branch, than I find ONLY thatsAFile and if I type ls on newBranch, than the ls command provides both thatsAFile and thatsSecondFile. So, from this point of view it looks like working.

That's because it is working. thatsSecondFile doesn't exist in master because master doesn't have the commit that added that file. If you want master to have that file, you'd do a git merge from newBranch to master to bring in the commit that added the file. Or, you could make changes in master and commit them, and then master would also have changes that don't exist in newBranch.

Answer 3

The branches are not the same, if you check the commits via git log you will see the difference.

The master branch will have only 1 commit ("that's a commitment!") and the newBranch will have 2 commits ("that's a commitment!", "message")

You can read more about branches and merges here: https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging