What does remote storage have to do with branch management? Push to your own branch! That's the core idea behind git development paradigm, and on sites like github it's as easy as clicking a "fork" button.

Because remote storage is either my fork of the code I work on, or my private repo which I develop my own software.

Of course it's a branch other than master/main, even if it's on "remote".

The thing is, I do not always continue developing on a single/same system, so I do "transfer" commits. I push unfinished code to its own branch on remote, pull from other system and continue developing.

When the code completes and passes all the tests. I merge to either development to prepare for the next version, or to master if the utility is small enough.

The place where the development branch lives doesn't matter, and --amend ing a single commit during a feature development is not the most correct way either.

Oh, and I don't use GitHub for my own software. That part is over.

Many companies like the idea of working with a single remote where individual developers prefix their branches with their username. The main reason is that the workflow is much simpler with only one remote endpoint. Having only one remote makes continuous synchronisation much easier (you don't need both "upstream" and "origin"). There are other benefits to this: If someone gets sick, you can find their work in the same place, and you can more easily pass over a branch to someone, since everyone shares remote workspace.

The drawback of one remote endpoint is that it becomes less obvious whose rules apply. You could argue that other people can mess up your remotes, but it isn't until you get to very large organisations or public development (e.g. FOSS) that you should need to deal with adversarial behavior.

I've had bosses who got angry that I force-pushed to my own remote branches because they liked to review code without being requested by pulling the branch, and after a force-push that doesn't work. But my defense was always: Let's establish a protocol on how to cooperate; there is surely some way we both get what we want, and that git supports.

Well... you can force push to a remote with sufficient privs, but you really don't want to do that if you can help it.

A remote can be your personal remote endpoint, or it can be on a shared remote endpoint, but prefixed with your username. As long as you `--force-with-lease` to a feature branch you control and agree on a protocol with potential collaborators, the harm is minimal.

I mostly avoid creating these kinds of conflicts when people's limited git experience would cause stress or unnecessary use of people's time fiddling with the history. Or if more than one person is doing stuff independent of one another.

I've had colleagues that frown on rebase, and people who can't not.

One of the beauties (and complexitties) of git is that it allows for this diversity of workflow.

Why should I abuse git while I can commit my developments part by part with nice descriptions?

Because you may want to back up your work remotely before you have the time to write something nice. I had to leave halfway through writing a unit test today. My colleague asked me to back up the code by pushing it. And now I'm back, fixing that test, writing that commit message. Most likely we'll merge right after, so my colleague probably won't need to add more, so the branch is in my control.