On the evil of feature branching [Highlight] We achieve this when committing frequently, multiple times a day, regardless of code complexity or team size [Highlight] This means if the build is too slow, we need to speed up the build; if tests are too slow, we need to write better and more concise tests; if the hardware is too slow, we need to buy faster hardware; if the codebase is too coupled, preventing us to write concise tests, we need to decouple the codebase [Highlight] As long as we have not yet merged our branch back to mainline, the rest of the team simply does not know in which direction we are taking the code to implement the feature we are working on. [Highlight] To summarise: Working on mainline forces communication! [Highlight] Because feature branches hide work for the rest of the team, it also discourages the adoption of refactoring. [Highlight] Collective Owernership is one of the key practices from Extreme Programming: anyone who sees an opportunity to add value to any portion of the code is required to do so at any time. [Highlight] The bigger the batch size, the more work we have in progress. The more work in progress the more inventory we have. Inventory is just money stuck into the system. [Highlight] Because long-running branches create batch-work, they also create bigger changesets. Bigger changesets mean more risks. [Highlight] If we commit more frequently to mainline, the Continuous Integration process will process a smaller changeset. If the build happens to break, finding the root cause will be fairly easy because the changeset is so small