When we perform code integration, we're combining the software that we've written with our teams codebase. It's at this point we often discover a few things:

• How much has changed since we last committed?
• What degree of overlap has there been? For example, if shared code has been changed for different purposes.
• How well does our software work together?

During a commit of our software, we will often need to resolve differences in common code, particularly if several pieces of work are being carried out in the same area of the system simultaneously.

Modern source control systems will highlight the areas that need attention and will not allow the code commit to go ahead without first resolving the issues. We will often employ a tool that allows for comparison of the code that is being merged.  

Still, this will only go so far in helping us complete the integration. There is still the potential for something to be missed, and if the wrong piece of code is chosen during a merge, then the behavior of the software will change unexpectedly after the commit is complete.

Even if you are in the early stages of the development of your product, it's likely the code is already being used by your customer, so a disciplined approach to code check-in and source control is needed.

The consensus is, the more often our developers commit their code, the sooner they are likely to discover any integration issues and resolve them. Small integrations will resolve more easily and will give each developer involved an idea of the direction the others are taking in the code.

This is why, in the Agile community, there has been a movement away from techniques that prolong the length of time before code is integrated, such as feature branching.

Instead, we favor trunk-based development—small discrete code commits to the main development code branch, sometimes using feature flags or branch by abstraction to hide code that isn't ready to be consumed yet. 

Trunk-based development is better known as CI. It involves making regular code commits, at least once a day. The code is built on every commit, if the build and automated tests are successful, the commit is allowed. If the build or tests fail, the commit is not successful and the developer(s) must fix any problems before attempting to commit again. 

In CI, we focus on the integration and validation of code at the unit and integration test-level. To achieve this, it's important that we have a reliable suite of automated unit and integration tests.