This commit doesn't need to leave the repository in a working state as:
... we are in early design stages, the code is not yet stable.
... you are the sole developer on the project. You know why things aren't working. Furthermore, you are not stopping anyone's work by committing broken code.
... the code currently doesn't work. We are going to make a big change to it. Let's commit, in order to have a point to revert to if things get ugly.
... the chain is long, no trouble if broken code exists in the local branch. I.e.
- local files
- staging area
- commits in local branch
- commits in remote personal feature branch
- merge with remote
develop
branch - merge with remote
master
branch - merge with remote
release
branch
... commit early,commit often.
So in the above-linked question, the majority of answers say that committing not-compilable code is no problem in local and feature branches. Why? What is the value of a broken commit?
Some of the highly voted comments say that on a local brach one can do whatever one wants. However, I am not interested in the technical side of the question. Rather I would like to learn the best practices - the habits that people who have worked many years in the industry have found most productive.
I am amazed at the vast amount of great answers! They lead me to the conclusion that I am not adept enough at using branches to organize my code.