- Start at a known good revision of the code
- Branch and make changes
- Meanwhile, someone else completes a change, and puts it into the main line (hopefully after passing review, QA, etc)
- You pull and merge
- You copy back into the main line, again after passing review, QA, etc...
As an aside, I am very pleased to see that Perforce finally, after almost twenty years of procrastination, introduced streams, which implement this exact change process directly, and not as one of many many options in a free-form depot structure.
The trick is to continue following this model as your code base and your team's size grows. Common objections are:
- I don't trust (3), so I don't want to do (4) and risk endangering my code because of (3)'s changes.
- I just know that (3) is completely orthogonal, so I can do (5) without doing (4).
- I don't trust (3), so I'll hold off with (4) until I finally have to do (5).
- Merging other people's code takes up too much of my time, so I'll hold off, especially since the changes seem to be mostly from places I don't care about.
There are two antidotes to these objections:
- Increase the requirements for performing step (5), in order to ensure that your mainline is always clean and releasable. I have come a long way to finally conclude that the best requirement is not only to have passed review and QA, but to actually have been deployed or released prior to getting copied into your mainline. Your mainline should be a true representation of what is in production, and nothing less than that. Later posts will expand on that theme....
- Keep the size of your source tree small. Split your source tree into components, modules, packages, artifacts or whatever is convenient and develop, build and release them separately. Yes, this increases the tracking burden, but it will keep the basic change model intact, and help implement the first point of making your mainline represent production. Again, later posts will expand on that theme.