Você e a maioria dos respondentes abordam isso como um problema de comunicação entre dois colegas, mas eu realmente não acho que seja. O que você descreve parece mais um processo de revisão de código horrivelmente quebrado do que qualquer outra coisa.
Primeiro, você menciona que seu colega é o segundo em comando e espera-se que ele revise seu código. Isso está errado. Por definição, as revisões de código por pares não são hierárquicas e, certamente, não são apenas para encontrar defeitos. Eles também podem fornecer experiências de aprendizado (para todos os envolvidos), uma oportunidade de interação social e provar uma ferramenta valiosa para a criação de propriedade coletiva do código. Você também deve revisar o código dele de tempos em tempos, aprender com ele e corrigi-lo quando ele estiver errado (ninguém faz o certo toda vez).
Além disso, você menciona que seu colega faz alterações imediatamente. Isso também está errado, mas é claro que você já sabe; você não teria feito essa pergunta se a abordagem dele não fosse um problema. No entanto, acho que você está procurando uma solução no lugar errado. Para ser perfeitamente honesto, seu colega me lembra um pouco de ... eu, e o que funcionou para mim em situações semelhantes foi um processo de revisão sólido e bem definido e um conjunto de ferramentas impressionantes. Você realmente não quer impedir seu colega de revisar seu código e pedir que ele pare e fale com você antes que todas as pequenas mudanças não funcionem. Pode demorar um pouco, mas em breve ele chegará a um ponto em que tudo ficará muito irritante e você voltará aonde começou, ou pior: ele simplesmente deixará de revisar seu código.
Uma chave para uma resolução aqui pode ser uma ferramenta de revisão de código por pares. Normalmente evito recomendações de produtos, mas para revisões de código Crisol de Atlassiané realmente um salva-vidas. O que ele faz pode parecer muito simples, e é, mas isso não significa que não é incrivelmente incrível. Ele se conecta ao seu repositório e oferece a oportunidade de revisar conjuntos de alterações individuais, arquivos ou grupo de arquivos. Você não pode alterar nenhum código, mas comentar sobre tudo que não parece certo. E se você absolutamente precisar alterar o código de outra pessoa, basta deixar um comentário com o conjunto de alterações explicando suas alterações. Vale a pena assistir ao vídeo introdutório na página do produto do Crisol, se você quiser mais detalhes. Os preços do Crisol não são para todos, mas existem inúmeras ferramentas de revisão por pares disponíveis gratuitamente. Com quem trabalhei e gostei foi o Painel de Revisão e tenho certeza de que você encontrará muitos outros com uma simples pesquisa no Google.
Qualquer que seja a ferramenta que você escolher, ela mudará completamente seu processo. Não há necessidade de parar, levantar da cadeira, interromper a outra pessoa e discutir as mudanças; tudo o que você precisa fazer é dar um tempo toda semana e passar pelos comentários (uma vez por semana é apenas uma sugestão. Você conhece melhor sua programação e rotina diária do que eu). Mais importante, as análises principais são armazenadas em um banco de dados em algum lugar e você pode recuperá-las a qualquer momento. Eles não são discussões efêmeras em torno do bebedouro. Meu caso de uso favorito para revisões antigas é ao apresentar um novo membro da equipe à nossa base de código. É sempre bom quando eu posso orientar alguém novo na base de código, apontando onde exatamente estávamos presos, onde tínhamos opiniões diferentes etc.
Seguindo em frente, você menciona que nem sempre acha o código desse colega legível. Isso me permite saber que você não possui um conjunto comum de padrões de codificação, e isso é uma coisa ruim. Novamente, você pode abordar isso como um problema de pessoas ou como um problema de processo e, novamente, sugiro fortemente o último. Reúna sua equipe e adote um estilo comum de codificação e um conjunto de padrões o mais rápido possível. Realmente não importa se você escolheu um conjunto de padrões comuns no seu ecossistema de desenvolvimento ou se criou o seu próprio. O que realmente importa é que seus padrões sejam consistentes e que você os cumpra. Muitas e muitas ferramentas por aí podem ajudá-lo, mas essa é uma discussão totalmente diferente. Apenas para você começar, uma coisa muito simples de fazer é ter um gancho de pré-confirmação executando algum tipo de formatador de estilo no seu código. Você pode continuar escrevendo seu código da maneira que desejar e deixar a ferramenta "corrigi-lo" automaticamente, antes que alguém o veja.
Por fim, você menciona em um comentário que a gerência não acredita que sejam necessários ramos de desenvolvimento individuais. Bem, há uma razão para chamá-los de "ramificações de desenvolvimento" e não "ramificações de gerenciamento". Vou parar por aqui, pois não há razão para o discurso retórico que está se formando em minha cabeça sair.
Tudo isso dito, saiba que não duvido que seu colega esteja (um pouco) culpado aqui. Esse não é o meu ponto, meu argumento é que todo o seu processo de desenvolvimento também está errado, e isso é algo mais fácil de corrigir. Arme-se com as ferramentas adequadas, explore os inúmeros processos formais e informais e escolha aqueles que se encaixam na sua equipe. Em breve você chegará a um ponto em que perceberá que a maioria dos seus "problemas com as pessoas" não existe mais. E, por favor, não ouça ninguém (inclusive você) que traga a desculpa de "somos uma equipe pequena, não precisamos de tudo isso". Uma equipe de desenvolvedores competentes pode configurar as ferramentas necessárias em menos de uma semana, automatizar tudo o que pode ser automatizado e nunca olhar para trás novamente.
PS. "Propriedade do código" é um termo nebuloso, constantemente debatido, e significa coisas diferentes para pessoas diferentes. Você pode encontrar uma coleção brilhante da maioria das opiniões diferentes (e às vezes antitéticas) sobre C2 .