question concerning branches

Avery Pennarun [off-list ref] writes:

You seem to have forgotten the "git commit" step before switching back
to master.

No, I passed over the commit in my example. I know that after the commit the
things are as they ought to be, but what if I can't do a commit because I am
in the middle of coding and have to have a break?

You have a modified file in your repository; what did you *want* to happen
when you switched branches?

I want an unchanged file in master if I switch there (because I worked in a
different branch) and a changed version in the test branch.

Why is the *master* different depending on whether my work in test in still
going on or committed?!

Actually, I cannot image how branches are practicable if I always have to
have in mind possibly still uncommitted work. Shouldn't it be git's work
to ensure that master will remain it was when branching?

Without git I'd make a copy for testing new features. With git, it seems that
I have to do the same (a clone). This is what I don't understand.

(Many people find the current behaviour very convenient.)

I find it highly confusing. I understood a branch as something I can do in
whatever I want without affecting master. But now a learn that everything I
do in the branch will happen in master, too, until I commit. Strange. Very
strange.

You might also want to look at the "git stash" command.

Yes, but isn't it annoying to leave the test branch always either with stash
or commit in order to have an unchanged master?!

Ingo