Permitir o uso de sistemas externos reais, como bancos de dados e serviços Web, em testes unitários, o que também permite reproduzir ambientes de execução realistas e melhorar a cobertura dos testes. 

Gerar dados de teste aleatorizados em cada execução, de modo a aumentar a variabilidade dos dados de entrada e, dessa forma, melhorar a confiabilidade, cobertura e robustez dos testes unitários.

Utilizar extensivamente a espera temporizada, como em Thread.sleep(), em testes concorrentes, de modo a estabilizar falhas relacionadas com temporização e reduzir a incidência de comportamentos intermitentes.

Lançar mão de implementações simuladas (mockups) em lugar do acesso ao relógio local e a serviços externos, isolando a unidade em teste e garantindo que cada teste seja independente de efeitos externos.

CI encorajar o uso de repositórios distintos para evitar interferência entre as diferentes tarefas de desenvolvimento em um projeto, com integração frequente dos repositórios e uso de testagem automática para garantir a ausência de erros, enquanto CD requer o empacotamento e deployment automáticos para reduzir o impacto de mudanças. 

CI envolver o uso de um repositório compartilhado, com automação de build e testagem a cada commit, enquanto CD envolve o empacotamento automático de cada build bem-sucedida, gerando uma nova release e deixando-a pronta para implantação (deployment) nos diferentes ambientes de produção.

CI requerer a realização contínua e automática de testes de integração para garantir que mudanças no código-fonte realizadas nos diferentes ramos (branches) do repositório não comprometam o comportamento correto dos componentes do sistema, enquanto CD envolve a implantação em ambiente de produção para a realização de testes em ambiente real.

CI determinar o emprego de testes unitários automáticos, eliminando a necessidade de testes manuais e garantindo que o comportamento do sistema permaneça correto após cada mudança, enquanto CD implica a realização automática de testes de integração após cada build e o subsequente empacotamento para deployment.

O branch new-feature é inicializado em um novo repositório, para o qual o conteúdo do repositório original é copiado e ao qual é adicionada a nova versão do arquivo oldfile.c, bem como o arquivo newfile.c. 

O branch new-feature é selecionado e preparado para commit, o qual ocorre subsequentemente, criando uma nova versão, que contém o arquivo oldfile.c modificado, assim como o novo arquivo newfile.c.

O branch new-feature é criado no mesmo repositório e definido com espaço de trabalho, o qual contém a nova versão do arquivo oldfile.c, mas não o arquivo newfile.c.

O branch new-feature é criado no mesmo repositório e nele é criada uma nova versão, a qual contém o arquivo modificado oldfile.c, assim como o novo arquivo newfile.c.