Vários repositórios git com um núcleo comum lib

5

Eu tenho vários repositórios git para um projeto da web que compartilham uma biblioteca de código comum. Eu não quero repetir o código comum dentro de cada repo. Quais são algumas das maneiras pelas quais os outros resolveram esse problema?

submódulos Git parecem ter muito ódio porque tendem a para causar mais problemas do que eles resolvem

Eu poderia ter apenas um repositório separado para o lib central, mas então não haveria maneira de encontrar versões correspondentes se os repositórios estivessem sendo desenvolvidos por equipes separadas. (Por exemplo, se v1.0.2 em um repositório requer v2.0.0 no core lib, essas informações devem ser rastreadas em algum lugar).

No Android, build.gradle mais ou menos resolve esse problema. Existe algo semelhante para o git? Por exemplo:

compile 'com.android.support:appcompat-v7:25.0.1' refere-se a uma versão específica de uma dependência remota. (Fonte: documentos do Android )

    
por Zach Rattner 28.11.2016 / 20:07
fonte

1 resposta

6

Você pode tratar o código compartilhado como código ou como um pacote. Se você tratá-lo como código, então git submodules é a resposta correta. Se você quiser tratá-lo como um pacote, você precisa introduzir o gerenciamento de pacotes como parte de seu processo de desenvolvimento.

Você já pode estar usando um gerenciador de pacotes como maven, nuget ou npm para incorporar pacotes de terceiros em seus projetos. A idéia é publicar seu código compartilhado em um repositório de pacotes que você controla (existem repositórios de pacotes gratuitos e comerciais disponíveis para esses sistemas de pacotes); seus desenvolvedores que usam o código compartilhado podem incorporá-lo em seus projetos da mesma forma que um pacote de terceiros; isso fornece a funcionalidade de rastreamento de versão que você precisa.

Tratar o código compartilhado como um pacote gera alguma sobrecarga e pode não valer a pena se o código compartilhado for usado por poucos clientes. Mas quando você começa a ter mais projetos clientes para o código compartilhado, cada um com agendas de lançamento independentes, tratar o código compartilhado como um pacote se torna mais atraente.

    
por 28.11.2016 / 20:42
fonte