Controle de origem baseado em Git na empresa: ferramentas e práticas sugeridas?

Eu uso o git para projetos pessoais e acho ótimo. É rápido, flexível, poderoso e funciona muito bem para o desenvolvimento remoto.

Mas agora é obrigatório no trabalho e, francamente, estamos tendo problemas.

Pronto, o git não parece funcionar bem para o desenvolvimento centralizado em uma organização grande (com mais de 20 desenvolvedores) com desenvolvedores de habilidades e níveis variados de sofisticação - especialmente comparado com outros sistemas de controle de origem como Perforce ou Subversion, que visam esse tipo de ambiente. (Sim, eu sei, Linus nunca pretendeu isso para isso.)

Mas - por razões políticas - estamos presos ao git, mesmo que seja péssimo para o que estamos tentando fazer com ele.

Aqui estão algumas das coisas que estamos vendo:

• As ferramentas da GUI não são maduras
• Usando as ferramentas de linha de comando, é muito fácil estragar uma mesclagem e eliminar as alterações de outra pessoa
• Ele não oferece permissões de repositório por usuário além dos privilégios globais somente leitura ou leitura / gravação
• Se você tem permissão para QUALQUER parte de um repositório, pode fazer o mesmo com TODAS as partes do repositório, portanto não pode fazer algo como criar uma ramificação de rastreamento de pequenos grupos no servidor central que outras pessoas não podem mexer com.
• Fluxos de trabalho que não sejam "vale tudo" ou "ditador benevolente" são difíceis de incentivar, e muito menos impor
• Não está claro se é melhor usar um único repositório grande (que permite que todos mexam com tudo) ou muitos repositórios por componente (que causam dores de cabeça ao tentar sincronizar versões).
• Com vários repositórios, também não está claro como replicar todas as fontes que outra pessoa possui, retirando do repositório central, ou fazer algo como obter tudo a partir das 4:30 da tarde de ontem.

No entanto, ouvi dizer que as pessoas estão usando o git com sucesso em grandes organizações de desenvolvimento.

Se você estiver nessa situação - ou se você geralmente possui ferramentas, dicas e truques para tornar mais fácil e produtivo o uso do git em uma organização grande, onde algumas pessoas não são fãs da linha de comando - eu adoraria ouvir o que você tem sugerir.

BTW, eu já fiz uma versão desta pergunta no LinkedIn e não tenho respostas reais, mas muitas "nossa, eu adoraria saber isso também!"

ATUALIZAÇÃO: Deixe-me esclarecer ...

Onde trabalho, não podemos usar nada além de git . Não é uma opção. Estamos presos a isso. Não podemos usar mercurial, svn, bitkeeper, Visual Source Safe, ClearCase, PVCS, SCCS, RCS, bazar, Darcs, monótonos, Perforce, Fossil, AccuRev, CVS ou até o bom e velho projetor da Apple que usei em 1987. Portanto, enquanto você pode discutir outras opções, não receberá a recompensa se não discutir sobre o git.

Além disso, estou procurando dicas práticas sobre como usar o git na empresa . Coloquei uma lista completa de problemas que estamos tendo no topo desta pergunta. Novamente, as pessoas são bem-vindas para discutir teoria, mas se você quiser ganhar a recompensa, me dê soluções.

Contra a opinião comum, acho que o uso de um DVCS é a escolha ideal em um ambiente empresarial, pois permite fluxos de trabalho muito flexíveis. Vou falar sobre o uso de um DVCS vs. CVCS primeiro, melhores práticas e depois sobre o git em particular.

DVCS vs. CVCS em um contexto corporativo:

Não vou falar sobre os prós / contras gerais aqui, mas focar no seu contexto. É a concepção comum, que o uso de um DVCS requer uma equipe mais disciplinada do que o uso de um sistema centralizado. Isso ocorre porque um sistema centralizado fornece uma maneira fácil de impor seu fluxo de trabalho; o uso de um sistema descentralizado requer mais comunicação e disciplina para manter o cumprimento das convenções estabelecidas. Embora isso possa induzir sobrecarga, vejo benefícios no aumento da comunicação necessária para torná-la um bom processo. Sua equipe precisará se comunicar sobre código, alterações e status do projeto em geral.

Outra dimensão no contexto da disciplina é incentivar ramificações e experimentos. Aqui está uma citação da recente entrada do bliki de Martin Fowler nas Ferramentas de controle de versão , ele encontrou uma descrição muito concisa para esse fenômeno.

O DVCS incentiva a ramificação rápida para experimentação. Você pode criar ramificações no Subversion, mas o fato de elas serem visíveis para todos desencoraja as pessoas a abrir uma ramificação para trabalho experimental. Da mesma forma, um DVCS incentiva a verificação do trabalho: cometer alterações incompletas, que podem nem mesmo compilar ou passar em testes, no seu repositório local. Novamente, você poderia fazer isso em uma ramificação de desenvolvedor no Subversion, mas o fato de que essas ramificações estão no espaço compartilhado torna as pessoas menos propensas a fazê-lo.

O DVCS permite fluxos de trabalho flexíveis porque eles fornecem rastreamento de conjunto de alterações por meio de identificadores globalmente exclusivos em um gráfico acíclico direcionado (DAG) em vez de simples diferenças de texto. Isso permite que eles acompanhem de forma transparente a origem e o histórico de um conjunto de alterações, o que pode ser bastante importante.

Fluxos de trabalho:

Larry Osterman (desenvolvedor da Microsoft que trabalha na equipe do Windows) tem uma excelente postagem no blog sobre o fluxo de trabalho que eles empregam na equipe do Windows. Mais notavelmente eles têm:

• Um tronco apenas de código limpo e de alta qualidade (repositório principal)
• Todo o desenvolvimento acontece nas ramificações dos recursos
• As equipes de recursos têm representantes de equipe
• Eles mesclam regularmente as alterações mais recentes do tronco na ramificação de recursos ( Integração Direta )
• Os recursos completos devem passar por vários portões de qualidade, por exemplo, revisão, cobertura de teste, perguntas e respostas (repo por conta própria)
• Se um recurso for concluído e tiver uma qualidade aceitável, ele será mesclado ao tronco ( Reverse Integrate )

Como você pode ver, tendo cada um desses repositórios funcionando por conta própria, você pode desacoplar equipes diferentes avançando em ritmos diferentes. Também a possibilidade de implementar um sistema flexível de portão de qualidade distingue o DVCS de um CVCS. Você também pode resolver seus problemas de permissão neste nível. Apenas um punhado de pessoas deve ter acesso ao repositório principal. Para cada nível da hierarquia, tenha um repositório separado com as políticas de acesso correspondentes. De fato, essa abordagem pode ser muito flexível no nível da equipe. Você deve deixar para cada equipe decidir se deseja compartilhar seu repo entre eles ou se deseja uma abordagem mais hierárquica em que apenas o líder da equipe possa se comprometer com o repo.

(A foto é roubada do hginit.com de Joel Spolsky .)

Ainda resta uma coisa a dizer neste momento: - embora o DVCS ofereça excelentes recursos de mesclagem, isso nunca substitui o uso da Integração Contínua. Mesmo nesse ponto, você tem muita flexibilidade: IC para o repositório de troncos, CI para repositórios de equipe, repositórios de perguntas e respostas, etc.

Git em um contexto corporativo:

Talvez o Git talvez não seja a solução ideal para um contexto empresarial, como você já apontou. Repetindo algumas de suas preocupações, acho que elas são:

• Ainda um pouco de suporte imaturo no Windows (corrija-me se isso mudou recentemente) Agora o windows tem cliente de github windows , tortoisegit , SourceTree da atlassian
• Falta de ferramentas GUI maduras, sem integração de ferramentas vdiff / mesclagem de cidadãos de primeira classe
• Interface inconsistente com um nível muito baixo de abstrações sobre o funcionamento interno
• Uma curva de aprendizado muito acentuada para usuários svn
• O Git é muito poderoso e facilita a modificação da história, muito perigoso se você não sabe o que está fazendo (e, às vezes, você mesmo que pensou que sabia).
• Nenhuma opção de suporte comercial disponível

Não quero iniciar uma guerra de git vs. hg aqui, você já fez o passo certo ao mudar para um DVCS. O Mercurial aborda alguns dos pontos acima e, portanto, acho que é mais adequado no contexto empresarial:

• Todas as plataformas que executam python são suportadas
• Ótimas ferramentas GUI em todas as principais plataformas (win / linux / OS X), integração de ferramentas de primeira classe de mesclagem / vdiff
• Interface muito consistente, transição fácil para usuários svn
• Pode fazer a maioria das coisas que o git também pode, mas fornece uma abstração mais limpa. Operações perigosas são sempre explícitas. Recursos avançados são fornecidos por meio de extensões que devem ser ativadas explicitamente.
• O suporte comercial está disponível na selenic.

Em resumo, ao usar o DVCS em uma empresa, acho importante escolher uma ferramenta que introduza menos atrito. Para que a transição seja bem-sucedida, é especialmente importante considerar a habilidade variável entre os desenvolvedores (em relação ao VCS).

Reduzindo o atrito:

Ok, desde que você parece estar realmente preso à situação, há duas opções restantes no IMHO. Não há ferramenta para tornar o git menos complicado; Git é complicado. Ou você confronta isso ou contorna o git: -

1. Obtenha um curso introdutório para toda a equipe. Isso deve incluir apenas o básico e alguns exercícios (importante!).
2. Converta o repositório principal em svn e deixe as "estrelas jovens" git-svn . Isso fornece à maioria dos desenvolvedores uma interface fácil de usar e pode compensar a falta de disciplina em sua equipe, enquanto as estrelas jovens podem continuar usando o git para seus próprios repositórios.

Para ser sincero, acho que você realmente tem um problema com as pessoas e não um problema com ferramentas. O que pode ser feito para melhorar essa situação?

• Você deve deixar claro que acha que seu processo atual terminará com uma base de código sustentável.
• Invista algum tempo em integração contínua. Como descrevi acima, independentemente do tipo de VCS que você usa, nunca há um substituto para o IC. Você declarou que há pessoas que enviam porcaria para o repositório principal: peça para que consertem a porcaria enquanto um alerta vermelho dispara e os culpe por interromper a construção (ou por não atender a uma métrica de qualidade ou qualquer outra coisa).

Sou o engenheiro de SCM de uma organização de desenvolvimento razoavelmente grande e nos convertemos para o git a partir do svn no último ano. Nós o usamos de maneira centralizada.

Usamos gitosis para hospedar os repositórios. Dividimos nossos repositórios monolíticos svn em muitos repositórios menores do git, pois a unidade de ramificação do git é basicamente o repositório. (Existem maneiras de contornar isso, mas são complicadas.) Se você deseja tipos de controle de acesso por ramo, o gitolite pode ser uma abordagem melhor. Há também uma versão dentro do firewall do GitHub se você quiser gastar o dinheiro. Para nossos propósitos, a gitosis é boa porque temos permissões bastante abertas em nossos repositórios. (Temos grupos de pessoas que têm acesso de gravação a grupos de repositórios e todos têm acesso de leitura a todos os repositórios.) Usamos o gitweb para uma interface da web.

Quanto a algumas de suas preocupações específicas:

• mescla: você pode usar uma ferramenta de mesclagem visual de sua escolha; existem instruções em vários lugares sobre como configurá-lo. O fato de você poder fazer a mesclagem e verificar sua validade totalmente no seu repositório local é, na minha opinião, uma grande vantagem para o git; você pode verificar a mesclagem antes de enviar qualquer coisa por push.
• GUIs: Temos algumas pessoas usando o TortoiseGit, mas eu realmente não recomendo; parece interagir de maneiras estranhas com a linha de comando. Eu tenho que concordar que esta é uma área que precisa ser aprimorada. (Dito isto, não sou fã de GUIs para controle de versão em geral.)
• ramificações de rastreamento de pequenos grupos: se você usar algo que fornece ACLs de granularidade mais fina, como o gitolite, é fácil fazer isso, mas você também pode criar uma ramificação compartilhada conectando repositórios locais de vários desenvolvedores - um repositório git pode ter vários controles remotos.

Mudamos para o git porque temos muitos desenvolvedores remotos e porque tivemos muitos problemas com o Subversion. Ainda estamos experimentando fluxos de trabalho, mas no momento basicamente o usamos da mesma maneira que usamos o Subversion. Outra coisa que gostamos é que ele abriu outros fluxos de trabalho possíveis, como o uso de repositórios temporários para revisão de código e compartilhamento de código entre pequenos grupos. Também é incentivado muitas pessoas a começar a rastrear seus scripts pessoais e assim por diante, porque é muito fácil criar um repositório.

Sim, eu sei, Linus nunca pretendeu isso.

Na verdade, Linus argumenta que sistemas centralizados simplesmente não podem funcionar.

E o que há de errado com o fluxo de trabalho dos ditadores e tenentes?

Lembre-se, o git é um sistema distribuído ; não tente usá-lo como central.

(Atualizada)

A maioria dos seus problemas desaparecerá se você não tentar usar o git como se fosse "svn on steroids" (porque não é).

Em vez de usar um repositório vazio como um servidor central onde todos podem enviar (e potencialmente estragar), configure alguns gerenciadores de integração que lidam com mesclagens, para que somente eles possam enviar para o repositório vazio.

Geralmente, essas pessoas devem ser as líderes da equipe: cada líder integra o trabalho de sua própria equipe e o envia ao repositório abençoado.

Melhor ainda, outra pessoa (ou seja, ditador) retira-se dos líderes da equipe e integra suas mudanças no repositório abençoado.

Não há nada de errado com esse fluxo de trabalho, mas somos uma startup sobrecarregada e precisamos de nossas ferramentas para substituir o tempo e a atenção humana; ninguém tem largura de banda para sequer revisar códigos, muito menos ser ditador benevolente.

Se os integradores não tiverem tempo para revisar o código, tudo bem, mas você ainda precisará de pessoas que integrem as mesclagens de todos.

Fazer git pull não leva muito tempo.

git pull A
git pull B
git pull C

git faz substituto para o tempo humano e atenção; por isso foi escrito em primeiro lugar.

• As ferramentas da GUI não são maduras

As ferramentas da GUI podem lidar muito bem com as coisas básicas.

Operações avançadas exigem uma mentalidade de codificador / nerd (por exemplo, estou confortável trabalhando na linha de comando). Demora um pouco de tempo para entender os conceitos, mas não é tão difícil.

• Usando as ferramentas de linha de comando, é muito fácil estragar uma mesclagem e eliminar as alterações de outra pessoa

Isso não será um problema, a menos que você tenha muitos desenvolvedores incompetentes com acesso total de gravação ao "repositório central".

Porém, se você configurar seu fluxo de trabalho para que apenas algumas pessoas (integradoras) gravem no repositório "abençoado", isso não será um problema.

O Git não facilita a estragar as mesclagens.

Quando houver conflitos de mesclagem, o git marcará claramente as linhas conflitantes para que você saiba quais mudanças são suas e quais não são.

Também é fácil eliminar o código de outras pessoas com svn ou qualquer outra ferramenta (não atribuída). Na verdade, é muito mais fácil com essas outras ferramentas, porque você tende a "ficar de olho nas mudanças" por um longo tempo e, em algum momento, as mesclagens podem ficar terrivelmente difíceis.

E como essas ferramentas não sabem como mesclar, você acaba sempre tendo que mesclar as coisas manualmente. Por exemplo, assim que alguém confirmar um arquivo que você está editando localmente, ele será marcado como um conflito que precisa ser resolvido manualmente; agora que é um pesadelo de manutenção.

Com o git, na maioria das vezes não haverá conflitos de mesclagem porque o git pode realmente se mesclar. No caso de um conflito ocorrer, o git marcará claramente as linhas para você, para que você saiba exatamente quais mudanças são suas e quais são de outras pessoas.

Se alguém eliminar as alterações de outras pessoas ao resolver um conflito de mesclagem, não será por engano: será porque era necessário para a resolução do conflito ou porque elas não sabem o que estão fazendo.

• Ele não oferece permissões de repositório por usuário além dos privilégios globais somente leitura ou leitura / gravação

• Se você tem permissão para QUALQUER parte de um repositório, pode fazer o mesmo com TODAS as partes do repositório, portanto não pode fazer algo como criar uma ramificação de rastreamento de pequenos grupos no servidor central que outras pessoas não podem mexer com.

• Fluxos de trabalho que não sejam "vale tudo" ou "ditador benevolente" são difíceis de incentivar, e muito menos impor

Esses problemas desaparecerão quando você parar de tentar usar o git como se fosse um sistema centralizado.

• Não está claro se é melhor usar um único repositório grande (que permite que todos mexam com tudo) ou muitos repositórios por componente (que causam dores de cabeça ao tentar sincronizar versões).

Chamada de julgamento.

Que tipo de projetos você tem?

Por exemplo: a versão xy do projeto A depende exatamente da versão wz do projeto B, de modo que sempre você verifica xy do projeto A, também é necessário fazer o checkout do wz do projeto B, caso contrário não será construído? Nesse caso, eu colocaria o projeto A e o projeto B no mesmo repositório, pois são obviamente duas partes de um único projeto.

A melhor prática aqui é usar seu cérebro

• Com vários repositórios, também não está claro como replicar todas as fontes que outra pessoa possui, retirando do repositório central, ou fazer algo como obter tudo a partir das 4:30 da tarde de ontem.

Não sei bem o que você quer dizer.

Eu recomendo http://code.google.com/p/gerrit/ para trabalhos corporativos. Oferece controle de acesso, além de um fluxo de trabalho baseado em revisão. Autentica em qualquer sistema LDAP. Você pode conectá-lo ao Hudson com http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Plugin , permitindo criar e testar alterações enquanto elas ainda estão sendo revisadas; é uma configuração realmente impressionante.

Se você decidir usar o gerrit, recomendo tentar manter uma história bastante linear, não uma história ramificada como alguns dos caras de código aberto. A Gerrit define isso como "permitir apenas alterações de avanço rápido". Em seguida, você pode usar a ramificação e a mesclagem da maneira que você está acostumado, para lançamentos e outros enfeites.

Estou respondendo a essa pergunta com base na minha experiência como gerente de desenvolvedores em uma grande empresa de telecomunicações, onde adotamos o Git em 2010

Você tem um conjunto de problemas bem diferente aqui:

• fluxos de trabalho
• ferramentas cliente
• controle de acesso ao servidor e integração

Fluxos de trabalho

Adotamos com sucesso um modo de repositório central: o que temos em nosso projeto corporativo (um grande portal para uma base de usuários de 5 milhões de usuários) é um repositório central de fato que produz as compilações oficiais e que são levados através do processo de entrega (que, em nossa caso, é composto por três níveis de teste e duas implantações). Todo desenvolvedor gerencia seu próprio repositório e trabalhamos com base em ramificação por recurso.

Ferramentas do cliente

Agora existem várias opções disponíveis, agora é uma área muito movimentada. Muitos desenvolvedores estão usando com sucesso o IntelliJ Idea e o Eclipse com o plug-in Git , sem outras coisas. Além disso, a maioria dos desenvolvedores do Linux está usando o cliente git CLI, sem nenhum problema. Alguns desenvolvedores de Mac estão usando o Tower Git com sucesso . Observe que nenhum desses clientes pode impedir o usuário de "bagunçar" o repositório central: é necessário um mecanismo de controle no servidor

Controle e integração de acesso ao servidor

Se você quiser evitar que os desenvolvedores "atrapalhem" seu repositório Git, você precisará escolher uma solução que:

• expõe uma interface de administrador da web decente para fazer todas as operações
• permite impor identidades de usuário (usar um repositório Git "simples" é extremamente fácil de confirmar em nome de outra pessoa)
• fornece segurança refinada (para que, por exemplo, você possa impedir o FORCE-PUSH e defina algumas ramificações como somente leitura para alguns desenvolvedores / grupos)
• integre-se ao seu sistema de autenticação corporativa (por exemplo, LDAP, Windows ActiveDirectory)
• fornece auditoria completa (a conformidade SOX às vezes é muito importante para grandes empresas)

Não há tantas soluções prontas para uso no lado do servidor que possam ajudar, sugiro que você verifique uma destas:

• Gitorious : ele pode fornecer segurança básica no nível de acesso, mas não possui controle de permissões granularmente pronto, portanto você provavelmente precisará codificar para lidar com cenários como permissões no nível da filial. Também não possui integração com mecanismos de autenticação corporativa existentes
• GitHub Enterprise: publicado recentemente pelo GitHub, ele apresenta o GitHub na sua empresa. Falta conformidade SOX e segurança refinada
• Gerrit : ele pode fornecer segurança e integração no nível de acesso direto aos sistemas de autenticação corporativa, mas não possui conformidade SOX e SSO. Além disso, algumas operações só podem ser feitas via SSH via CLI
• GitEnterprise : fornece permissões em nível de filial, conformidade com SSO, SOX, administração completa na Web. Recentemente, ele também foi integrado ao Gerrit, para fornecer uma instância completa do Gerrit

Espero que isto ajude!

Parece que seu problema é que você não decidiu ou instituiu um fluxo de trabalho. O Git é flexível o suficiente para usá-lo como svn ou qualquer outro VCS, mas é tão poderoso que se você não estabelecer regras que todo mundo deve seguir, você acabará bagunçado. Eu recomendaria o fluxo de trabalho ditador-tenente que alguém mencionou acima, mas combinado com o modelo de ramificação descrito por Vincent Driessen . Para mais informações, veja esses screencasts de David Bock e este de Mark Derricutt .

Nas ferramentas , os usuários do MacOS-X acham o GitX (http://gitx.frim.nl/) muito simples e eficaz. A desvantagem é que não suporta ganchos do Git Client (aqueles sob $ GIT_ROOT / .git / hooks).

No geral, eu faço fortemente para escolher uma ferramenta que suporte controle de acesso refinado em: - branches (para separar os branches de liberação estável com segurança estrita dos tópicos-branches que precisam de mais agilidade e flexibilidade) - reforço de identidade (autor / committer ) Esta é a CHAVE para SOX - restrições de comandos git - trilha de auditoria. Esta é a CHAVE para SOX

Os que eu usei com sucesso com esses recursos são:

1. Revisão do código Gerrit (http://code.google.com/p/gerrit/)
2. GitEnterprise (http://gitenterprise.com)
3. O CollabNet TeamForge (http://www.collab.net/gotgit) usa o Gerrit 2.1.8 nos bastidores

PS Não subestime a conformidade com SOX e CMMI : muitas vezes há um conjunto limitado de opções, que é ditado pelas políticas corporativas da empresa em segurança.

Espero que isto ajude.

Luca.

Recentemente, mudamos de svn para git. Como o git-daemon não funciona com o msysgit, optamos por uma abordagem de repositório central em um servidor Linux com gitosis.

Para eliminar a possibilidade de estragar o mestre, simplesmente o excluímos. Em vez disso, preparamos todas as liberações mesclando as ramificações selecionadas para teste e marcando a mesclagem. Se passar nos testes, o commit será marcado com uma versão e colocado em produção.

Para lidar com isso, temos um papel rotativo de gerenciador de lançamento. O gerente de versão é responsável por revisar cada filial antes de estar pronta para o teste. Então, quando o proprietário do produto decide que é hora de agrupar as ramificações aprovadas para uma nova versão de teste, o gerente de release realiza a mesclagem.

Também temos um papel rotativo de suporte técnico de 2º nível e, pelo menos para nós, a carga de trabalho é tal que é possível ter os dois papéis ao mesmo tempo.

Como benefício de não ter um mestre, não é possível adicionar nenhum código ao projeto sem passar pelo gerenciador de lançamento, portanto descobrimos diretamente quanto código foi adicionado silenciosamente ao projeto antes.

O processo de revisão começa com o proprietário da filial enviando o diff para o painel de revisão e colocando um post-it verde no quadro branco com o nome da filial (temos um fluxo de trabalho baseado no Kanban) em "para revisão" ou se faz parte de um usuário completo história, mova o cartão de história inteiro para "para revisão" e coloque o post nela. O gerente de relase é aquele que move os cartões e os post-its para "prontos para o teste" e, em seguida, o proprietário do produto pode selecionar quais deseja incluir no próximo release de teste.

Ao fazer a mesclagem, o gerenciador de release também garante que a consolidação de mesclagem tenha uma mensagem de consolidação sensata que possa ser usada no log de alterações do proprietário do produto.

Quando uma liberação é colocada em produção, a tag é usada como a nova base para ramificações e todas as ramificações existentes são mescladas a ela. Dessa forma, todas as ramificações têm um pai comum, o que facilita o processamento de mesclagens.

Também adicionarei uma postagem "você já considerou".

Uma das grandes coisas do Bazaar é a sua flexibilidade. É aqui que ele supera todos os outros sistemas distribuídos. Você pode operar o Bazaar no modo centralizado, no modo distribuído ou obtenha o seguinte: ambos (o que significa que os desenvolvedores podem escolher com qual modelo se sentem confortáveis ​​ou qual funciona melhor para o grupo de trabalho). Você também pode desconectar um repositório centralizado enquanto estiver em trânsito e reconectá-lo quando voltar.

Além disso, excelente documentação e algo que fará a sua empresa feliz: suporte comercial disponível.

• Instale uma interface da web decente, como o Github FI
• Atenha-se a um modelo relativamente centralizado (inicialmente) para manter as pessoas confortáveis.
• Execute uma construção de Integração Contínua para cada filial compartilhada.
• Compartilhe um bom conjunto de opções globais de configuração do git.
• Integre o git ao seu shell, com a conclusão do bash e um prompt com a ramificação atual.
• Experimente a Integração Git do IntelliJ como uma ferramenta de mesclagem.
• Certifique-se de que você gitignore conforme apropriado.

Em relação aos pontos 3 e 4 (permissões por usuário, por seção e por filial), consulte o gitolite (abordado no livro Pro Git: http://progit.org/book/ch4-8.html ).

Política ou não, o Git é uma escolha tão boa quanto uma DCVS. Como qualquer ferramenta poderosa, vale a pena gastar um pouco de tempo para entender como a ferramenta foi projetada para funcionar e, para esse fim, recomendo vivamente o livro do Pro Git. Algumas horas gastas com ele economizarão muita frustração a longo prazo.

GUI: No momento, o TortoiseGit v1.7.6 deve funcionar bem na maioria das operações diárias. Log, Commit, Push, Pull, Fetch, Diff, Merge, Branch, Cherry-pick, Rebase, Tag, Export, Stash, Add submodule, etc ... Também suporta x64 nativamente

Para usar o git de maneira eficiente em uma equipe de desenvolvimento com muitos desenvolvedores, é necessário um sistema de IC que construa e teste continuamente. Jenkins fornece esse veículo e eu recomendo isso. A parte da integração precisa ser feita, não importa o que aconteça, e é muito mais barato fazer isso mais cedo e com mais frequência.

Mais adequado para o desenvolvimento colabrativo do que a gitose ou a gitolita, mas o código aberto é Gitorious . É uma aplicação Ruby on Rails que gerencia o gerenciamento de repositórios e a fusão. Isso deve resolver muitos dos seus problemas.

O Git permite criar ramificações particulares. Isso incentiva os desenvolvedores a se comprometerem com frequência, de modo a dividir as modificações em pequenas confirmações. Quando o desenvolvedor está pronto para publicar suas alterações, ele envia para o servidor central. Ele pode usar scripts de pré-confirmação para verificar seu código, se necessário.

O NXP está gerenciando o Git e o Subversion com uma plataforma comum (em escala corporativa), integrando o desenvolvimento móvel Android com projetos de software tradicionais: http://www.youtube.com/watch?v=QX5wn0igv7Q