Why do teams merge their code many times a day?
Small merges are easy and big ones are a nightmare, so the winning move is to merge before the pain builds up.
▶ Start the storyTeams merge their code many times a day because small merges are easy and big merges are not. If two developers work apart for weeks, their versions drift. When they finally combine them, the pile up, and the work of combining can take longer than the original work did. Continuous integration is the habit of merging changes frequently, and checking every time that the combined code still works.
The checking is done by an automated system. Developers merge their changes into one shared line of work, called the or , and a server builds the software and runs its tests. Martin Fowler's rule of thumb is that everybody should to the mainline every day, and experienced teams do it more often. Integrating at least once a day is considered good practice, and more often is better.
The reason is size. Checking in a week's worth of work risks conflict, both in how likely it is and in how complex it gets. Small are significantly easier to resolve than large ones. With continuous integration the merges are so small that they usually pass without comment, and an awkward one is a merge that takes more than a few minutes.
Merge rarely
- Versions drift apart for weeks
- One huge, unpredictable merge
- Integration can take longer than the work itself
Merge daily
- Many tiny merges
- are small and easy
- The shared code stays workable
There is one rule that holds the system together. If the fails, it must be fixed right away, because the has to stay healthy. Kent Beck, who developed the practice, said nobody has a higher priority task than fixing the build. A team that follows this gets many small merges instead of one frightening one.
Quiz me
0/3
Recap
Merge small and merge often, let a machine check every merge, and fix a red build before anything else.
💡 A trick to remember it · Small and daily beats big and late: a pebble now, not a boulder later.
Surprising fact · Before the practice, some teams spent months integrating work that had taken years to write.
Sources (2)
No source, no claim. Every fact in this lesson (16 claims) cites at least one of these.