Gerenciamento de patches em um ambiente multi-repositório

Navegue suas respostas
5

Aqui está o problema e como gerenciamos isso no momento.

Temos uma receita de buildout que busca vários repositórios git. Às vezes, é necessário corrigir um módulo de um repositório que não possuímos (repositório público). Na minha posição anterior em uma empresa diferente, costumávamos separar todo o repositório público e enviar patches em diferentes filiais. Este trabalho funciona bem, mas, em alguns casos, é muito mais difícil de manter e, às vezes, os patches são realmente específicos para um determinado cliente, então fica difícil entender quais ramificações são relevantes e é mais fácil gerenciar 50+ repositórios se você precisar dar permissão para empurrar para desenvolvedores. Ao mesmo tempo, nós gerenciamos arquivos de patch que podem ser aplicados diretamente sem bifurcar qualquer repositório.

No meu trabalho atual, decidi me limitar aos arquivos de patch porque isso simplifica o processo. Aplicar tecnicamente um patch e mesclar um branch é basicamente a mesma coisa.

Os patches são armazenados em um repositório por cliente e aplicados no processo de criação. Já que com a busca de múltiplos repositórios, algum patch deve ser aplicado em projectA e algum outro em projectB ...

Neste momento, estou escrevendo cada patch que precisa ser aplicado no arquivo de configuração da compilação, mas fiquei me perguntando se havia uma maneira de torná-lo menos acoplado à configuração.

Como em vez de aplicar um patch, eu aplicaria um conjunto de patches que seria mais próximo de uma mesclagem que pode aplicar vários "commit". Mas o conjunto de correções deve poder aplicar correções em vários diretórios / repositórios. Geralmente, o patch é feito para o repositório específico usando git format patch .

    
por Loïc Faure-Lacroix 20.02.2017 / 12:34
fonte

2 respostas

3

Para o cenário semelhante, usamos uma ferramenta Quilt - utilitário de gerenciamento de conjunto de patches: link

Basicamente você tem um diretório patches na raiz do seu projeto que contém vários patches independentes, gerenciados pelo quilt . O diretório do patch pode ter esta aparência: 

patches/100_asserts.diff
patches/101_terminate_call.diff
patches/102_status_code477.diff
patches/107_parser.diff
patches/110_ssldefault.diff

Os patches são aplicados sequencialmente ( quilt push ), podem ser aplicados ( quilt pop ),  atualizado ( quilt refresh ) e assim por diante. Faz sentido separar patches para arquivos de acordo com sua lógica.

Na situação com mais repositórios, você pode criar um novo repositório git com dependências como submódulos git. 

patches/  <-- patches repo01, repo02
repo01/   <-- git submodule
repo02/   <-- git submodule

Neste exemplo, o diretório de correções é gerenciado pelo git.

No caso de uso de repositório único, usamos o fork do repositório, adicionamos o diretório patches e mantemos as correções no mesmo repositório.

A atualização também é possível: colocando todos os patches por quilt pop -a , git pull , quilt push patch um por um, resolva o conflito, se necessário, geralmente quilt refresh faz o trabalho.

Existem também ferramentas que se integram diretamente ao git:

por 04.05.2017 / 10:49
fonte
0

Pelo que entendi em sua pergunta, você pode estar usando patches com muita frequência quando a melhor solução talvez seja usar o sistema de controle de versão diretamente. Patches foram feitos apenas para correções rápidas.

Então, se estivermos usando repositórios que não possuímos, poderemos usar:

  • correções em uma versão do repositório público
    • mas solicite a nossa integração de correções o mais rápido possível para usar o repositório diretamente sem patches sempre que possível, reduzindo os patches a serem aplicados.
  • clone / bifurque o repositório público e mantenha nossa própria evolução orgânica (e, por exemplo, use Submódulos integrar em nosso projeto completo) [isso é equivalente a ter patches no repositório público] ( como trabalhar com submódulos)

Se "os patches são realmente específicos de um cliente em particular" talvez não desejemos corrigir esses repositórios públicos (foi construído com outra filosofia / casos de uso / arquitetura em mente), e é melhor usar alternativas como:

  • faça as alterações em nosso código que usa esses repositórios externos
  • crie um decorador / wrapper do repositório externo
  • use um repositório público externo alternativo (ou crie o nosso próprio)

Eu sei que você pediu uma ferramenta de gerenciamento de patches. Mas isso parece um sistema de versionamento (SVN, git, mercurial)!

Mas, se você realmente precisa usar um sistema de correções, você pode criar um arquivo de configuração no projeto A, outro no projeto B, (etc) que descreverá os patches necessários para serem usados. E os patches existirão em um repositório independente.

    
por 21.02.2017 / 13:40
fonte

Tags

Como converter o último rc (ou outro pré-lançamento) na versão de produção usando o semver? É uma prática ruim chamar outra API de um filtro?