Git forking and fixing - can you explain the theory of this cryptic (to me) behavior?

Question

I have a master branch, and everything is in order. Then I create a branch called experimental, and I create a new file. In my experimental branch, I add this file using the git add command. Then I check my master's branch. In my main branch, I run git status and find that this file has also been added to my master branch. Then I run git commit -m "message" until a git commit -m "message" occurs in my main branch. Then I switch to my experimental branch and run git status and find that the file was also committed to my experimental branch.

Here's what I would expect: after going to the main branch after adding a new file, I would expect the file to not appear there. In the end, I did not create the file in the main branch, and I did not add it to the master branch. Therefore, when I switch to the main branch and run git status , why does it find the file is already added and ready to commit? And when I then do this in the lead branch, why did I also find that it was fixed in the experimental branch when I switch back? Did he pass two branches at once?

Answer 1

When you run git add , the file is not fixed, it is added only to Git "index". You probably wanted to run git commit after running git add in your experimental branch.

When switching branches in Git, changes in the working directory and index are transferred until they conflict with other files that change during branch switching.

To solve your specific problem:

... and find that this file has also been added to my main branch.

If you did not run git commit , then the file has not yet been added to any branch.