Do you feel comfortable merging code?

Question

This morning, I read two opinions on refactoring.

• Opinion 1 (Page not present)
• Opinion 2 (Page not present)

They recommend branching (and s

Answer 1

Working in a code base of millions of lines of code with hundreds of developers branching is an everyday occurrence. The life of the branch varies depending on the amount of work being done.

For a small fix:

• designer makes a sidebranch off the main stream
• makes changes
• tests
• reviews
• merges accumulated changes from main stream to sidebranch
• iterates through one or more of the previous steps
• merges back to main stream

For a multi-person team feature:

• team makes a feature sidebranch off the main stream
• individual team member operates on feature sidebranch as in "small fix" approach and merges to feature sidebranch.
• sidebranch prime periodically merges accumulated changes from main stream to feature sidebranch. Small incremental merges from the mainstream to feature sidebranch are much easier to deal with.
• when feature works, do final merge from main stream to feature sidebranch
• merge feature sidebranch to main stream

For a customer software release:

• make a release branch
• deliver fixes as needed to release branch
• fixes are propogated to/from the main stream as needed

Customer release streams can be very expensive to support. Requires testing resources - people and equipment. After a year or two, developer knowledge on specific streams starts to get stale as the main stream moves forward.

Can you imagine how much it must cost for Microsoft to support XP, Vista and Windows 7 concurrently? Think about the test beds, the administration, documentation, customer service, and finally the developer teams.

Golden rule: Never break the main stream since you can stall a large number of developers. $$$