Return to Question

Is it good idea to require to commit only working code?

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.

  1. local files
  2. staging area
  3. commits in local branch
  4. commits in remote personal feature branch
  5. merge with remote develop branch
  6. merge with remote master branch
  7. 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?

Added: There are a couple of highly-voted comments, saying 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.

Is it good idea to require to commit only working code?

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.

  1. local files
  2. staging area
  3. commits in local branch
  4. commits in remote personal feature branch
  5. merge with remote develop branch
  6. merge with remote master branch
  7. 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.

[Is it good idea to require to commit only working code?][1]

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.

  1. local files
  2. staging area
  3. commits in local branch
  4. commits in remote personal feature branch
  5. merge with remote develop branch
  6. merge with remote master branch
  7. 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?

Added: There are a couple of highly-voted comments, saying 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. [1]: Is it good idea to require to commit only working code?

Is it good idea to require to commit only working code?

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.

  1. local files
  2. staging area
  3. commits in local branch
  4. commits in remote personal feature branch
  5. merge with remote develop branch
  6. merge with remote master branch
  7. 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?

Added: There are a couple of highly-voted comments, saying 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.

[Is it good idea to require to commit only working code?][1]

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.

  1. local files
  2. staging area
  3. commits in local branch
  4. commits in remote personal feature branch
  5. merge with remote develop branch
  6. merge with remote master branch
  7. 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?

Added: There are a couple of highly-voted comments, saying 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 hound 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. [1]: Is it good idea to require to commit only working code?

[Is it good idea to require to commit only working code?][1]

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.

  1. local files
  2. staging area
  3. commits in local branch
  4. commits in remote personal feature branch
  5. merge with remote develop branch
  6. merge with remote master branch
  7. 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?

Added: There are a couple of highly-voted comments, saying 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. [1]: Is it good idea to require to commit only working code?