Um projeto, vários clientes com git?

Question

Im novo para GIT e ainda não sei o quanto isso vai caber minhas necessidades, mas parece impressionante.

Eu tenho um único webapp que eu uso para clientes diferentes (django + javascript)

Eu pretendo usar GIT para lidar com essas diferentes clientes versão como ramos. Cada cliente pode ter arquivos personalizados, pastas e configurações, versões melhoradas ... mas o devem compartilhar o mesmo 'core'. Somos uma equipe pequena e suscribed uma conta github.

é o ramo da boa maneira de lidar com este caso?

Sobre o arquivo de configurações, como você procederia? Você .gitignore o arquivo de configurações específicas do cliente e adicionar um arquivo settings.xml.sample por exemplo, é o repo?

Além disso, existe alguma maneira de impedir que alguns arquivos a serem incorporadas pelo mestre? (Mas comprometidos com o ramo do cliente). Por exemplo, eu gostaria de salvar alguns dados de clientes para o ramo cliente, mas impedir de serem comprometidos com a mestre.

É o específico branch-arquivo .gitignore? YES

Editar Depois de ler todas as suas respostas (obrigado!) Eu decidi primeiro refatorar meu estrutura do projeto Django para isolar o núcleo e os meus diferentes aplicativos em uma subpasta apps. Fazendo isso faz um projeto mais limpo, e aprimorando o arquivo .gitignore torna fácil de usar ramos git para gerenciar os clientes e configurações diferentes!

Ju.

Answer 1

Além de resposta de cpharmston, parece que você precisa fazer alguma refatoração para separar o que é verdadeiramente personalizada para cada cliente e que não é. Então você pode considerar a adição de repositórios adicionais para rastrear as personalizações para cada cliente (inteiramente novos repos, não ramos). Em seguida, sua implantação pode puxar o seu "core" de seu repo principal, e o material específico do cliente de que repo.

Answer 2

Eu não usaria ramos para realizar o que você está tentando fazer.

No controle de origem, ramos têm a intenção de ser usado para coisas que se destinam a estar de volta incorporada no tronco. Por exemplo, Alex Gaynor passou sua summer of code trabalhando em um ramo de Django que permite o suporte para vários bancos de dados , com o objetivo de, eventualmente, fundir-lo de volta para o tronco Django.

Checkouts (ou clones , no caso de Git) pode melhor atender o que você está tentando façam. Você criaria um repositório contendo todos os arquivos de base do projeto (e arquivos .sample, se preferir), e clonar o repo para todos os vários locais que desejam implantar o código. Em seguida, crie manualmente os arquivos de configuração e personalização em cada implantação (cuidar para não adicionar -los para o repo). Sempre que você atualizar o código no repo, executar um puxão em cada implantação para atualizar o código. Viola!

Answer 3

Matthew Talbert está correto, você realmente precisa para separar o material personalizado a partir de material não-personalizado. Se você pode refatorar todo o código do núcleo para ser contido em um diretório, seus clientes podem usá-lo como um read-only submodule git. O benefício adicional é que você bloqueá-los em uma versão explícita do código do núcleo. Isso significa que eles teriam de atualizar conscientemente para uma revisão mais recente, que é o que você quer para o código de produção.

Answer 4

Outras respostas estão corretas que você estará na melhor forma para a manutenção na medida em que você separar o seu código do núcleo do código personalizado por cliente. No entanto, eu vou quebrar da multidão e dizer que se você é incapaz de fazer isso (dizer, porque você precisa adicionar funcionalidade extra para código do núcleo para um determinado cliente), DVCS ramos iria funcionar muito bem para o que você quer fazer . Embora eu provavelmente recomendar ramos por-diretório em vez de filiais em-repo para este fim (git pode fazer ramos por-diretório, bem, não é nada, mas um repositório clonado que diverge).

Eu uso hg, não git, mas todos os meus projetos Django são clonados a partir da mesma base "modelo de projeto" repo que tem scripts de utilidade pública, um conjunto comum básico de INSTALLED_APPS, etc. Isto significa que quando eu fizer alterações a esse projecto modelo, eu posso facilmente mesclar essas atualizações comuns em projetos existentes. Isso não é exatamente o mesmo que o que você está pensando, mas é semelhante. Você irá ocasionalmente têm de lidar com conflitos de mesclagem, se você modificar a mesma área de código no núcleo que você já tenha personalizado para um cliente específico.

Answer 5

Depois de ler todas as suas respostas (obrigado!) Eu decidi primeiro refatorar meu estrutura do projeto Django para isolar o núcleo e os meus diferentes aplicativos em uma subpasta apps. Fazendo isso faz um projeto mais limpo, e aprimorando o .gitignore no arquivo diferentes ramos torna fácil de usar ramos git para gerenciar os clientes e configurações diferentes!