Branch lifecycle

This has been extracted from an email

A new branch should be created for new tasks. New commits should not be appended to an existing branch. Assume a developer has three tasks: 1 (feature one), 2 (enhancement to feature one), and 3 (feature two). The branch for task 1, 1-feature-one, would be created off of the master branch. The branch for task 2, 2-feature-one-enhancement, would be created off of the 1-feature-one branch since it depends on the changes in task 1. The branch for task 3, 3-feature-two, would be created off of the master branch since it doesn't depend on changes in tasks 1 or 2.

Because we are going to be opening pull requests and merging frequently, the 2-feature-one-enhancement branch will be created after the pull request for 1-feature-one has been opened. Once the pull request for 1-feature-one has been opened, that branch is no longer private to the developer; therefore, the history should not be rewritten while the pull request is open. If I make comments on the pull request indicating that changes are necessary, these changes should be in new commits on the 1-feature-one branch. Only if I close the pull request unmerged because significant changes are necessary should the branch be treated as private to the developer again, making it acceptable to rewrite history on the branch.

Development on the 2-feature-one-enhancement branch will likely commence while the pull request for 1-feature-one is still open. Again, because the history for 1-feature-one is no longer private, the changes in 2-feature-one-enhancement should not be squashed into any changes from 1-feature-one.

If the pull request for 2-feature-one-enhancement is opened while the pull request for 1-feature-one is still open, 2-feature-one-enhancement will include the 1-feature-one commit(s). If 1-feature-one has been merged, only the new changes from 2-feature-one-enhancement will be in the pull request.