Git "trunk"/"releases" por cliente por produto

Eu tenho usado o SVN há muito tempo e agora estou me mexendo para ficar "na moda".

Meu problema é como git gerentes de projeto/desenvolvedores de software gerenciam as versões de um programa: não do ponto de vista do código, mas da perspectiva do cliente.

Eu tenho alguns projetos que pertencem a um cliente. Cada cliente em uma pasta separada tem uma pasta "projetos" e possivelmente uma pasta "suporte". O código do projeto existe em cada pasta "projetos". Em "suporte" há alguns documentos/scripts de suporte, etc.

Há também o caso em que alguns clientes compartilham um produto. Cada um desses é versões em termos de código ou configuração. Mas é do mesmo produto.

Agora, apenas tentando fazer isso no disco rígido, estou preso em que tenho o .git em cada projeto. Não sob uma pasta do cliente. Eu não gosto disso, como eu acho que isso significa que eu preciso ter um wiki (ou um arquivo de texto?) Para lembrar (!) Onde os repositórios git pertencem (por exemplo, se um laptop é quebrado ... e eu precisa obter todos os repositórios git.Eu tenho que ter de alguma forma obter os repositórios de volta no disco).

Por outro lado, seria melhor ter o repositório git sob a pasta do cliente? Mas, nesse caso, se eu precisar fazer "stash/branch/merge" isso "prejudicaria" o restante dos projetos sob o mesmo diretório "customer-umbrella-git"?

Eu não posso imaginar o que seria stashed/mesclado/ramificado se um cliente precisa de recurso X para o produto Y e ao mesmo tempo eu preciso corrigir um bug para o projeto B. Tendo os repositórios git na pasta do cliente me assusta.

Ou existe uma maneira de colocar uma propriedade git talvez em algum lugar e eclipse/idea/windows explorer (sim claro ...) iria ler isso e me dar um rápido reconhecimento de quais projetos eu tenho em que cliente?

Como você gerencia isso?

0
Você não pode ter certeza do que vai acontecer. Existem projetos que o código é 99% mesmo. Mas há variação. Eu acredito que todos nós enfrentamos esta obscuridade.
adicionado o autor Ant, fonte
Pergunta - quando os clientes compartilham um produto, todas as alterações de código são fornecidas aos dois clientes ou algumas permanecem específicas do cliente?
adicionado o autor Sarov, fonte

2 Respostas

Não tenho certeza de onde você tirou a idéia de que "os gerentes de projeto git/desenvolvedores de software gerenciam as versões [...] de um programa da perspectiva do cliente". Eu uso o git e certamente não tenho um repositório separado para cada cliente ...

De qualquer forma, o seguinte funciona bem para minha equipe:

Para produtos com variações, mas que serão mesclados

Use o sistema de ramificação do git para isso; tem um ramo separado para cada um. Uma abordagem para isso é usar o seguinte sistema de ramificação:

  • Um ramo mestre que representa a versão única 'Live' do código
  • Um ramo Beta por cliente. Depois que um recurso tiver sido aprovado por esse cliente, ele será mesclado na ramificação principal e outras ramificações Beta serão realocadas no mestre para obter a alteração.
  • Um ramo de recursos por funcionalidade. Quando o recurso estiver pronto para a versão beta, ele será mesclado ao (s) ramo (s) Beta correto (s).

Para produtos diferentes que são semelhantes, mas nunca serão mesclados

Tem três repositórios. Um para cliente/produto A. Um para cliente/produto B. E um submódulo/subárvore (Aviso de isenção: nunca usei subárvores) para o código compartilhado.

Dessa forma, as duas "variações do mesmo produto" são realmente tratadas como produtos/repositórios separados; eles apenas compartilham código entre eles.

Para produtos usados ​​apenas por um único cliente

Direto. Um produto, um cliente, um repo.


Desta forma, cada produto sempre tem um e apenas um repositório não-submódulo.

1
adicionado
Muito interessante a ideia toda. Para o primeiro marcador, você sempre entrega ramificação mestre para cada cliente? Você não tem o caso de que uma filial é estável e boa para o cliente-A, mas você não pode entregar ao cliente-B o mesmo código? Por exemplo, final de contrato. Ou outro obstáculo legal. Ou você não pode por causa da lacuna de tecnologia. Falta de .. servidor digamos ... Então você precisa manter uma filial (novo código atualizado) e mestre (para clientes que não recebem atualização). Ou você dividiria o Branch com outro novo mestre inteiramente novo?
adicionado o autor Ant, fonte
Vou considerar sua abordagem e tentar testar isso em projetos "pet". E eu precisarei ter algo como um "mapa" para saber diretamente qual projeto pertence a quem cliente e talvez outras dependências ... Obrigado pelo seu tempo.
adicionado o autor Ant, fonte
@hephestos Como você usa o sistema de ramificação será específico da organização. Faça o que fizer mais sentido para você. Uma abordagem pode ser ter outra camada de indireção; master branch para código totalmente acabado, agências 'Live' específicas do cliente, ramificações 'Beta' específicas do cliente e, em seguida, filiais. Apenas como uma diretriz geral: quando é um produto usar ramificação, quando vários produtos usam repos separados.
adicionado o autor Sarov, fonte

Eu acho que você deveria mudar sua visão. Não é cliente ter versões e ramificações, mas o produto tem. Especialmente, se alguns produtos são compartilhados entre os clientes. Portanto, você deve ter suas pastas ".git" nas pastas do produto.

Se você precisar de configurações de produto diferentes para os clientes, crie a pasta "configurações" na pasta do produto.

Nesse caso, você poderá adicionar novos recursos ao produto e às configurações e corrigir erros em paralelo.

Há também o modelo de design de versão do Git Flow que pode ser útil para voce.

0
adicionado
Obrigado pela resposta Anton, sim, verdadeiramente esta é uma opção. Para me adaptar à máquina. Mas eu realmente não quero fazer isso primeiro. Segundo, gostaria de saber se outras pessoas pensam ou pensaram sobre isso e que outras soluções podem ocorrer. Quando estou trabalhando "solo", fornecendo os recursos, o código, as correções, os patches, e também tenho que manter o que tenho dado a quem, para lembrar datas ou versões. Em seguida, torna-se um luxo ter em mente apenas o controle de versão "subproduto". Então, eu me pergunto se existe uma boa maneira de "guiar o livro" para o caminhão "inteligentemente", se é que posso dizer.
adicionado o autor Ant, fonte