Estratégia de controle de revisão de versão a ser sugerida

Estratégia de controle de revisão de versão a ser sugerida
Eu trabalho em um pequeno escritório dentro de uma universidade e sou responsável pelos documentos físicos para os alunos, como guias, questionário e assim por diante. Temos de 10 a 15 alunos por ano que trabalham conosco para conseguir algum dinheiro e para nos ajudar a preparar esses documentos, ajudar outros alunos, etc.
O diretor anterior do escritório era péssimo com qualquer coisa relacionada a computadores, então acabamos trabalhando no papel para cada mudança que tínhamos que fazer, acumulando toneladas de papel inútil e enlouquecendo quando tínhamos que encontrar a última versão de alguma coisa.
Além disso, ter um estagiário diferente todos os dias era literalmente impossível rastrear as mudanças em qualquer coisa.
Então, estou aqui agora procurando um meio-termo e estava pensando em algo como um fluxo de trabalho git para não-programadores.
Eu crio o documento base, digamos o guia do estudante 2015-16.doc, e diariamente o aluno que está trabalhando nele enviará uma solicitação pull que aceito total ou parcialmente e pode revisar e visualizar as versões anteriores.
Eu não posso usar o cygwin e pedir que as pessoas digitem comandos git em um shell (isso não é uma universidade de ciência da computação), portanto eu queria saber se há algo como um plugin para o Word trabalhando invisivelmente nos bastidores.
Se puder, tente mudar para o Google Docs. Ele lida com essa situação muito bem.
Ele é projetado em torno da colaboração em documentos; ele colore as edições ou marca-as com tachado para exclusões até a edição ser aprovada.
Você pode ver quem fez edições na página porque mostra uma tag de nome na margem direita das edições pendentes.
Recentemente, fiz algumas revisões em um documento no google docs. As edições que fiz foram coloridas em verde e marcadas na margem direita com um crachá mostrando meu nome até que o proprietário do documento as inspecionasse e aprovasse.
Aqui está o documento de ajuda do google sobre como fazer "edições sugeridas"
Existem ferramentas de colaboração e controle de revisão disponíveis no Word, mas como muitas coisas, o MS não segue um padrão, não é compatível com qualquer outra coisa e pode nem mesmo funcionar entre versões ou instalações do Word.
Se você deve usar o Word, eu sugiro usar as ferramentas de revisão internas, mas, em vez de git - que trata. docx como blob binário usando mercurial, (hg), com a extensão zipdoc. Eu recomendaria fazer a revisão antes de confirmar a alteração.
Você pode utilizar um gerenciador de documentos de código aberto para colaborar e rastrear versões. Eu começaria olhando alfresco, nuxeo e sensenet. (Divulgação: minha empresa é parceira da SenseNet.)
Usamos o SenseNet internamente para gerenciar nossos documentos para evitar a situação que você descreveu. Para implementar essa solução, você primeiro baixaria e instalaria um banco de dados; O MS SQL Server Express é gratuito e é suficiente para um grupo pequeno como o seu. Em seguida, baixe e instale a versão Community do SenseNet no Codeplex. SenseNet tem um fórum que pode fornecer ajuda se você tiver qualquer problema na instalação.
Uma vez instalado, navegue até a página Document Workspace e clique no link "New Document workspace" e preencha o diálogo. O "Gerente de Projeto" pode aprovar documentos, portanto, defina esse valor para o usuário apropriado. Se você quiser que a versão em todos os documentos defina a lista suspensa Histórico de versões como "Maior e menor" e "Aprovação de conteúdo" como Verdadeiro, clique no botão Salvar. Depois disso, você deve ver algo como a imagem abaixo.
Os membros do espaço de trabalho podem visualizar / editar / aprovar dependendo das permissões que você atribuiu a eles quando foram adicionados. A maioria das operações necessárias são mostradas no menu suspenso do documento (veja os itens destacados na segunda imagem):
Download (apenas obtém uma cópia) Checkout (bloqueia as alterações até o checkin) Publicar (Aprova o documento) Versões (visualizar versões anteriores e, opcionalmente, reverter) Definir notificação (notificar os usuários sobre alterações no documento)
Confira Rascunho. Você não pode usar documentos do Word com ele, mas acho que tem os aspectos de colaboração e aprovação que você está procurando.
Ele é projetado principalmente para texto simples e redução de marcações, por isso, esteja ciente disso. Ele permite a interação de estilo "solicitação de pull" solicitada por você:
No entanto, quando você compartilha seu documento usando Rascunho, qualquer alteração feita por seu colaborador é feita em sua própria cópia do documento e você pode aceitar ou ignorar cada alteração individual que fizer. Aqui está o que parece:
Você pode usar o Servidor Sharepoint ou um Serviço Sharepoint (que é gratuito).
Se estiver tudo bem para o seu caso de negócios, você pode verificar o Office 365. Essa revisão / aprovação já está integrada de alguma forma.
Um uso do git neste caso não é a melhor idéia, já que ele lida com o arquivo completo como um commit e não com as partes dentro do contêiner de palavras.
Se você realmente quer o controle de versão, o que você parece, desde que você menciona o git, e você quer que ele seja utilizável por pessoas não muito conhecedoras de tecnologia, então eu posso recomendar vivamente o PlasticSCM.
Eu tenho usado por alguns anos para o meu próprio código privado, em vários idiomas. Estou particularmente impressionado com suas capacidades de diff / merge e também com alguns dos doces para os olhos gráficos (para não mencionar a camiseta grátis para completar uma pesquisa, -)
O melhor de tudo para você, integra-se no MS Office, adicionando novos botões para a barra de ferramentas, e tem forte MS Office (Word e Excel) diff & amp; mesclar recursos.
Acabamos de lançar novas alterações na integração do Plastic SCM com várias ferramentas do Microsoft Office: Word, Excel e PowerPoint.
Agora você poderá diferenciar documentos do Word, planilhas do Excel e até presos do PowerPoint (restritos a versões antigas que tenham suporte para isso).
Agora você poderá mesclar arquivos do Microsoft Word também. sai da caixa! Quais são as novas alterações Quando várias pessoas estão atualizando e fazendo cópias dos mesmos arquivos, várias versões desabrocham facilmente fora de controle.
O SCM plástico agora pode comparar formatos de arquivos proprietários, incluindo arquivos do Microsoft Office.
Nós lançamos a integração com o Office no Windows para realizar diff e mesclar para documentos do Office.
Como dito acima, agora você pode usar o Plastic SCM (instalação padrão) para a mesclagem de documentos do Microsoft Word.
A nova versão também está adicionando recursos de otimização para:

Estratégia de controle de revisão de versão a ser sugerida
Percebi que, quando altero ou refazo uma estratégia e, em seguida, volto a ela alguns dias, não consigo lembrar quais foram essas alterações ou por que está corrompida.
Seria ótimo ter algum tipo de controle de versão para ver o histórico de mudanças de uma estratégia e talvez até comparar o desempenho de diferentes versões de uma única estratégia.
O material deste site é fornecido apenas para fins informativos e não constitui uma oferta de venda, uma solicitação de compra ou uma recomendação ou endosso para qualquer segurança ou estratégia, nem constitui uma oferta para fornecer serviços de consultoria de investimento pela Quantopian. Além disso, o material não oferece opinião com relação à adequação de qualquer investimento específico ou de segurança. Nenhuma informação aqui contida deve ser considerada como uma sugestão para se envolver ou se abster de qualquer ação relacionada ao investimento, já que nenhuma das empresas da Quantopian ou de suas afiliadas está prestando consultoria de investimento, atuando como consultora de qualquer plano ou entidade sujeita a o Employee Retirement Income Security Act de 1974, conforme alterado, conta de aposentadoria individual ou anuidade de aposentadoria individual, ou dar conselhos em uma capacidade fiduciária com relação aos materiais aqui apresentados. Se você for um investidor individual ou outro investidor, entre em contato com seu consultor financeiro ou outro fiduciário não relacionado com a Quantopian sobre se qualquer ideia, estratégia, produto ou serviço de investimento descrito aqui pode ser apropriado para suas circunstâncias. Todos os investimentos envolvem risco, incluindo perda de principal. A Quantopian não garante a exatidão ou integridade das opiniões expressas no site. As opiniões estão sujeitas a alterações e podem ter se tornado não confiáveis ​​por várias razões, incluindo mudanças nas condições de mercado ou circunstâncias econômicas.
Esta é realmente uma ótima idéia. Perderam a conta do número de vezes que eu quis retornar às versões de código anteriores de uma estratégia em que estou trabalhando porque atrapalhei algo ao longo do caminho.
Outro par de ideias que pensei que poderia ser legal:
1) poder adicionar meta tags a uma estratégia, como & quot; pares & quot; ou "reversão à média" e, em seguida, permitir que um usuário possa pesquisar sua biblioteca de estratégias usando essas tags.
2) relacionados: uma vez que um usuário tem muitas estratégias em seus "Meus algoritmos" pode ser bom poder usar uma tag & quot; classificar por & quot; drop down, onde você pode classificar por coisas como o Índice de Sharpe ou o Retorno Cumulativo das estratégias que estão lá.
Eu estive pensando sobre isso um pouco mais e uma boa solução pode ser ter um & quot; Commit & quot; botão ao lado do botão & quot; Salvar & quot; botão. Quando você clicar em & quot; Confirmar & quot ;, você deverá adicionar um comentário (git ou svn like) e essa versão será salva no histórico de versões. Ter a capacidade de ver diferenças de versão como o github também seria bom.
@Tim, gosto muito da sua segunda ideia, +1!
Olá Aidan e Tim, obrigado pelas sugestões!
Acabamos de lançar uma ferramenta de comparação que você pode usar para comparar duas execuções de backtest da mesma estratégia. Basta ir à sua lista de backtests de um algoritmo, selecionar dois backtests e clicar em "Comparar". Por enquanto, estamos usando uma execução completa do backtest como o gatilho para salvar uma versão, mas vejo um controle mais granular no futuro, como sugeriu Aidan com um comando "Commit". botão.
Deixe-nos saber o que vocês acham!
O material deste site é fornecido apenas para fins informativos e não constitui uma oferta de venda, uma solicitação de compra ou uma recomendação ou endosso para qualquer segurança ou estratégia, nem constitui uma oferta para fornecer serviços de consultoria de investimento pela Quantopian. Além disso, o material não oferece opinião com relação à adequação de qualquer investimento específico ou de segurança. Nenhuma informação aqui contida deve ser considerada como uma sugestão para se envolver ou se abster de qualquer ação relacionada ao investimento, já que nenhuma das empresas da Quantopian ou de suas afiliadas está prestando consultoria de investimento, atuando como consultora de qualquer plano ou entidade sujeita a o Employee Retirement Income Security Act de 1974, conforme alterado, conta de aposentadoria individual ou anuidade de aposentadoria individual, ou dar conselhos em uma capacidade fiduciária com relação aos materiais aqui apresentados. Se você for um investidor individual ou outro investidor, entre em contato com seu consultor financeiro ou outro fiduciário não relacionado com a Quantopian sobre se qualquer ideia, estratégia, produto ou serviço de investimento descrito aqui pode ser apropriado para suas circunstâncias. Todos os investimentos envolvem risco, incluindo perda de principal. A Quantopian não garante a exatidão ou integridade das opiniões expressas no site. As opiniões estão sujeitas a alterações e podem ter se tornado não confiáveis ​​por várias razões, incluindo mudanças nas condições de mercado ou circunstâncias econômicas.
Respondendo a essa solicitação, pois seria melhor do que ter que executar um backtest completo toda vez que você quiser & quot; commit & quot; uma revisão.
Desculpe, algo deu errado. Tente novamente ou entre em contato enviando feedback.
Você enviou com sucesso um ticket de suporte.
Nossa equipe de suporte entrará em contato em breve.
O material deste site é fornecido apenas para fins informativos e não constitui uma oferta de venda, uma solicitação de compra ou uma recomendação ou endosso para qualquer segurança ou estratégia, nem constitui uma oferta para fornecer serviços de consultoria de investimento pela Quantopian.
Além disso, o material não oferece opinião com relação à adequação de qualquer investimento específico ou de segurança. Nenhuma informação aqui contida deve ser considerada como uma sugestão para se envolver ou se abster de qualquer ação relacionada ao investimento, já que nenhuma das empresas da Quantopian ou de suas afiliadas está prestando consultoria de investimento, atuando como consultora de qualquer plano ou entidade sujeita a o Employee Retirement Income Security Act de 1974, conforme alterado, conta de aposentadoria individual ou anuidade de aposentadoria individual, ou dar conselhos em uma capacidade fiduciária com relação aos materiais aqui apresentados. Se você for um investidor individual ou outro investidor, entre em contato com seu consultor financeiro ou outro fiduciário não relacionado com a Quantopian sobre se qualquer ideia, estratégia, produto ou serviço de investimento descrito aqui pode ser apropriado para suas circunstâncias. Todos os investimentos envolvem risco, incluindo perda de principal. A Quantopian não garante a exatidão ou integridade das opiniões expressas no site. As opiniões estão sujeitas a alterações e podem ter se tornado não confiáveis ​​por várias razões, incluindo mudanças nas condições de mercado ou circunstâncias econômicas.
O material deste site é fornecido apenas para fins informativos e não constitui uma oferta de venda, uma solicitação de compra ou uma recomendação ou endosso para qualquer segurança ou estratégia, nem constitui uma oferta para fornecer serviços de consultoria de investimento pela Quantopian.
Além disso, o material não oferece opinião com relação à adequação de qualquer investimento específico ou de segurança. Nenhuma informação aqui contida deve ser considerada como uma sugestão para se envolver ou se abster de qualquer ação relacionada ao investimento, já que nenhuma das empresas da Quantopian ou de suas afiliadas está prestando consultoria de investimento, atuando como consultora de qualquer plano ou entidade sujeita a o Employee Retirement Income Security Act de 1974, conforme alterado, conta de aposentadoria individual ou anuidade de aposentadoria individual, ou dar conselhos em uma capacidade fiduciária com relação aos materiais aqui apresentados. Se você for um investidor individual ou outro investidor, entre em contato com seu consultor financeiro ou outro fiduciário não relacionado com a Quantopian sobre se qualquer ideia, estratégia, produto ou serviço de investimento descrito aqui pode ser apropriado para suas circunstâncias. Todos os investimentos envolvem risco, incluindo perda de principal. A Quantopian não garante a exatidão ou integridade das opiniões expressas no site. As opiniões estão sujeitas a alterações e podem ter se tornado não confiáveis ​​por várias razões, incluindo mudanças nas condições de mercado ou circunstâncias econômicas.

Estratégia de controle de revisão de versão a ser sugerida
Na minha sugestão, descrevi como o versionamento do núcleo pode ser feito de maneira fácil: versionamento do núcleo desmistificado [^]
Eu também me referi ao seu artigo, espero que você não se importe!
Esses projetos têm o mesmo formato que o vcxproj e usam exatamente os mesmos arquivos de recursos *.rc que os projetos CPP.
No entanto, se eu fechá-lo e reabrir a GUI, tudo é desmarcado e preciso fazer "Mark All" novamente. Se eu clicar em "Criar solução com versões atualizadas", recebo uma caixa de diálogo dizendo "Nenhuma atualização de projeto ou nenhuma versão válida para atualização foi selecionada". Eu esperava reabrir a GUI para mostrar os mesmos valores que defini na última vez, e que "Build updated" faria a tarefa anterior novamente.
Não é isso que eu deveria esperar?
Preciso configurar algo para que isso aconteça?
Eu esperava que fosse apenas pegar a versão do meu arquivo. rc, mas não parece ser capaz de fazer isso, mostrando & lt; não encontrado & gt; na GUI. Por isso, não irá incrementá-lo.
Devo esperar que isso "apenas funcione"? ou seja, para pegar a versão existente automaticamente a partir do. rc? Ou preciso fazer algo para que ele leia a minha versão existente e aumente?
Eu tenho uma seção intitulada "1 VERSIONINFO", que contém FILEVERSION e PRODUCTVERSION.
Eu entendo isso significa que eles mudaram o nome do título em algum momento entre VC6 e VC2013?
Isso significa que se eu editar manualmente VERSIONINFO para VS_VERSION_INFO, ou adicionar um novo recurso usando o menu que não será capaz de compartilhar o arquivo entre as diferentes gerações do Visual Studio? Por enquanto eu preciso ser capaz de construir usando as duas gerações de ferramentas.
Observando também que o Visual Studio irá reescrever todo o arquivo RC para o formato atual sempre que precisar fazer uma alteração (se já não estiver).
Um pouco de pesquisa mostrou que VS_VERSION_INFO e VERSIONINFO são itens de sintaxe diferentes, portanto, podem ser usados ​​juntos. VS_VERSION_INFO é um símbolo cujo valor deve ser 1. Ele pode ser definido em resource. h usando #define. VERSIONINFO é o nome do tipo de recurso.
O cabeçalho do recurso de versão é, portanto, "VS_VERSION_INFO VERSIONINFO".
Tendo feito isso, agora posso construir no VS 2013 ou no VS6. Nada parece estar sendo perdido ao mudar entre as versões do VS - o que é necessário.
PS Há outro problema, em torno da persistência, mas vou começar um novo tópico para isso.
Como posso fazer isso com a linha de comando?
A razão é que eu quero atualizar a versão do assembly para a versão principal um certo tempo antes do lançamento e continuar a numerar as versões dos arquivos com números mais baixos até a versão final.
Fazendo isso, as versões de arquivo não tentam sincronizar com as versões de montagem.
Lockheed Martin Corporation.
Web04 | 2.8.180221.1 | Última atualização em 8 de dezembro de 2013.
Todo o resto Copyright & copy; CodeProject, 1999-2018.

Um modelo de ramificação do Git bem-sucedido.
na terça-feira, 05 de janeiro de 2010.
Neste post, apresento o modelo de desenvolvimento que introduzi em alguns dos meus projetos (tanto no trabalho quanto no privado) há cerca de um ano e que acabou sendo muito bem-sucedido. Eu tenho pensado em escrever sobre isso por um tempo agora, mas eu nunca encontrei tempo para fazê-lo completamente até agora. Não falarei sobre detalhes de nenhum dos projetos, apenas sobre a estratégia de ramificação e o gerenciamento de lançamentos.
Para uma discussão aprofundada sobre os prós e contras do Git em comparação com sistemas de controle de código fonte centralizados, consulte a web. Há muitas guerras de chamas acontecendo lá. Como desenvolvedor, prefiro o Git acima de todas as outras ferramentas atualmente. O Git realmente mudou a forma como os desenvolvedores pensam em mesclar e ramificar. Do mundo clássico do CVS / Subversion de onde eu vim, mesclar / ramificar sempre foi considerado um pouco assustador (“cuidado com conflitos de mesclagem, eles te mordem!”) E algo que você faz de vez em quando.
Mas com o Git, essas ações são extremamente baratas e simples, e são consideradas uma das principais partes de seu fluxo de trabalho diário, na verdade. Por exemplo, em livros do CVS / Subversion, a ramificação e a mesclagem são discutidas primeiro nos capítulos posteriores (para usuários avançados), enquanto em todos os livros do Git, elas já são abordadas no capítulo 3 (noções básicas).
Como conseqüência de sua simplicidade e natureza repetitiva, a ramificação e a fusão não são mais algo para se ter medo. Ferramentas de controle de versão devem auxiliar na ramificação / fusão mais do que qualquer outra coisa.
Chega de ferramentas, vamos ao modelo de desenvolvimento. O modelo que vou apresentar aqui é essencialmente nada mais que um conjunto de procedimentos que cada membro da equipe tem que seguir para chegar a um processo de desenvolvimento de software gerenciado.
Descentralizado, mas centralizado ¶
A configuração do repositório que usamos e que funciona bem com esse modelo de ramificação é com um repositório central de “verdade”. Note-se que este repo é apenas considerado o central (uma vez que o Git é um DVCS, não existe um repo central a nível técnico). Vamos nos referir a este repositório como origem, já que esse nome é familiar a todos os usuários do Git.
Cada desenvolvedor puxa e empurra para a origem. Mas além dos relacionamentos push-pull centralizados, cada desenvolvedor também pode extrair alterações de outros pares para formar subequipes. Por exemplo, isso pode ser útil para trabalhar em conjunto com dois ou mais desenvolvedores em um novo recurso grande, antes de levar o trabalho em andamento à origem prematuramente. Na figura acima, há subequipes de Alice e Bob, Alice e David, e Clair e David.
Tecnicamente, isso significa nada mais do que Alice ter definido um controle remoto do Git, chamado bob, apontando para o repositório de Bob e vice-versa.
Os ramos principais ¶
No núcleo, o modelo de desenvolvimento é muito inspirado pelos modelos existentes por aí. O repositório central possui dois ramos principais com vida útil infinita:
O branch master na origem deve ser familiar para todos os usuários do Git. Paralelamente ao branch master, existe outro branch chamado develop.
Consideramos origem / mestre como a ramificação principal em que o código-fonte de HEAD sempre reflete um estado pronto para produção.
Consideramos origem / desenvolvimento como a ramificação principal em que o código-fonte de HEAD sempre reflete um estado com as últimas alterações de desenvolvimento entregues para a próxima versão. Alguns chamariam isso de “ramo de integração”. É aqui que todas as construções automáticas noturnas são construídas.
Quando o código-fonte na ramificação de desenvolvimento atinge um ponto estável e está pronto para ser liberado, todas as alterações devem ser mescladas de volta ao mestre de alguma forma e, em seguida, marcadas com um número de release. Como isso é feito em detalhes será discutido mais adiante.
Portanto, cada vez que as alterações são mescladas de volta ao mestre, essa é uma nova liberação de produção por definição. Nós tendemos a ser muito rigorosos nisso, para que, teoricamente, pudéssemos usar um script Git hook para construir e implementar automaticamente nosso software para nossos servidores de produção toda vez que houvesse um commit no master.
Ramos de apoio ¶
Ao lado das principais ramificações mestre e desenvolver, nosso modelo de desenvolvimento usa uma variedade de ramos de apoio para auxiliar o desenvolvimento paralelo entre os membros da equipe, facilidade de rastreamento de recursos, preparação para lançamentos de produção e para ajudar a corrigir rapidamente problemas de produção ao vivo. Ao contrário dos principais ramos, estes ramos têm sempre um tempo de vida limitado, uma vez que serão removidos eventualmente.
Os diferentes tipos de ramos que podemos usar são:
Cada uma dessas ramificações tem uma finalidade específica e está vinculada a regras estritas sobre quais ramificações podem ser sua ramificação de origem e quais ramificações devem ser suas metas de mesclagem. Nós os percorremos em um minuto.
De modo algum esses ramos são “especiais” de uma perspectiva técnica. Os tipos de ramificação são categorizados pela forma como os usamos. Eles são, é claro, simples e velhos ramos do Git.
Ramos de recurso ¶
Pode ramificar a partir de: desenvolver Deve-se mesclar novamente em: desenvolver Convenção de nomenclatura de ramificação: qualquer coisa exceto mestre, desenvolver, release - * ou hotfix - *
As ramificações de recurso (ou às vezes chamadas de ramificações de tópicos) são usadas para desenvolver novos recursos para a futura versão futura ou futura. Ao iniciar o desenvolvimento de um recurso, a liberação de destino na qual esse recurso será incorporado pode ser desconhecida nesse momento. A essência de uma ramificação de recurso é que ela existe enquanto o recurso estiver em desenvolvimento, mas acabará sendo mesclada novamente em desenvolvimento (para adicionar definitivamente o novo recurso à próxima versão) ou descartada (no caso de um experimento decepcionante).
Os ramos de recursos normalmente existem apenas em repositórios de desenvolvedores, não em origem.
Criando uma ramificação de recurso ¶
Ao iniciar o trabalho em um novo recurso, ramifique-se do ramo de desenvolvimento.
Incorporando um recurso finalizado no desenvolvimento ¶
Os recursos finalizados podem ser mesclados no ramo de desenvolvimento para adicioná-los definitivamente à próxima versão:
O sinalizador --no-ff faz com que a mesclagem sempre crie um novo objeto de confirmação, mesmo que a mesclagem possa ser executada com um avanço rápido. Isso evita a perda de informações sobre a existência histórica de uma ramificação de recurso e agrupa todos os commits que juntos adicionam o recurso. Comparar:
No último caso, é impossível ver a partir do histórico do Git quais dos objetos commit juntos implementaram um recurso - você teria que ler manualmente todas as mensagens de log. Reverter um recurso inteiro (isto é, um grupo de commits) é uma verdadeira dor de cabeça na última situação, ao passo que é facilmente feito se o flag --no-ff for usado.
Sim, ele criará mais alguns objetos de confirmação (vazios), mas o ganho é muito maior que o custo.
Liberar ramificações ¶
As ramificações de lançamento suportam a preparação de uma nova versão de produção. Eles permitem pontilhamento de última hora de i e cruzamento t '. Além disso, eles permitem pequenas correções de erros e preparam metadados para uma versão (número de versão, datas de compilação, etc.). Ao fazer todo esse trabalho em uma ramificação de lançamento, a ramificação de desenvolvimento é liberada para receber recursos para a próxima grande liberação.
O momento chave para ramificar uma nova ramificação de desenvolvimento do desenvolvimento é quando o desenvolvimento (quase) reflete o estado desejado da nova versão. Pelo menos todos os recursos que são direcionados para o release a ser construído devem ser mesclados para serem desenvolvidos neste momento. Todos os recursos destinados a versões futuras podem não esperar - eles devem esperar até que o ramo de lançamento seja ramificado.
É exatamente no início de uma ramificação de lançamento que o próximo lançamento recebe um número de versão - não antes. Até aquele momento, o ramo de desenvolvimento refletia as mudanças para o “próximo lançamento”, mas não está claro se esse “próximo lançamento” acabará se tornando 0.3 ou 1.0, até que o ramo de lançamento seja iniciado. Essa decisão é tomada no início da ramificação de lançamento e é realizada pelas regras do projeto sobre o número da versão.
Criando uma ramificação de release¶
Os ramos de liberação são criados a partir do ramo de desenvolvimento. Por exemplo, digamos que a versão 1.1.5 é a versão de produção atual e temos um grande lançamento chegando. O estado de desenvolvimento está pronto para o "próximo lançamento" e decidimos que isso se tornará a versão 1.2 (em vez de 1.1.6 ou 2.0). Então, nós nos ramificamos e damos ao branch release um nome que reflete o novo número da versão:
Depois de criar uma nova ramificação e mudar para ela, aumentamos o número da versão. Aqui, o bump-version. sh é um script de shell fictício que altera alguns arquivos na cópia de trabalho para refletir a nova versão. (Isso pode ser uma mudança manual - o ponto é que alguns arquivos mudam.) Então, o número da versão afetada é confirmado.
Este novo ramo pode existir lá por um tempo, até que o lançamento possa ser implementado definitivamente. Durante esse tempo, correções de bugs podem ser aplicadas neste ramo (em vez de no ramo de desenvolvimento). Adicionar novos recursos grandes aqui é estritamente proibido. Eles devem ser fundidos em desenvolvimento e, portanto, aguardar o próximo grande lançamento.
Terminando um ramo de lançamento ¶
Quando o estado do ramo de lançamento está pronto para se tornar um lançamento real, algumas ações precisam ser realizadas. Primeiro, o branch release é mesclado no master (já que todo commit no master é um novo release por definição, lembre-se). Em seguida, esse commit no master deve ser marcado para facilitar futuras referências a esta versão histórica. Por fim, as alterações feitas no ramo de lançamento precisam ser mescladas de volta ao desenvolvimento, para que versões futuras também contenham essas correções de bugs.
Os dois primeiros passos no Git:
A liberação está pronta e marcada para referência futura.
Edit: Você também pode querer usar o - s ou - u & lt; key & gt; sinalizadores para assinar sua tag criptograficamente.
Para manter as alterações feitas no ramo de lançamento, precisamos mesclá-las de volta ao desenvolvimento. Em Git:
Essa etapa pode levar a um conflito de mesclagem (provavelmente até, já que alteramos o número da versão). Se sim, conserte-o e confirme.
Agora estamos realmente prontos e a ramificação do lançamento pode ser removida, já que não precisamos mais dela:
Ramificações de Hotfix ¶
Pode se ramificar de: mestre Deve ser mesclado de volta em: desenvolver e dominar a convenção de nomenclatura de Ramificação: hotfix - *
Os ramos de correcções são muito semelhantes aos ramos de lançamento, uma vez que também se destinam a preparar uma nova versão de produção, embora não seja planeada. Eles surgem da necessidade de agir imediatamente sobre um estado indesejado de uma versão de produção ao vivo. Quando um bug crítico em uma versão de produção deve ser resolvido imediatamente, um branch de hotfix pode ser ramificado da tag correspondente na ramificação principal que marca a versão de produção.
A essência é que o trabalho dos membros da equipe (no ramo de desenvolvimento) pode continuar, enquanto outra pessoa está preparando uma correção rápida de produção.
Criando o ramo de hotfix ¶
Os ramos de correcções são criados a partir do ramo principal. Por exemplo, digamos que a versão 1.2 é a versão de produção atual em execução e causando problemas devido a um bug grave. Mas as mudanças no desenvolvimento ainda são instáveis. Podemos então ramificar uma ramificação de hotfix e começar a corrigir o problema:
Não se esqueça de aumentar o número da versão depois da ramificação!
Em seguida, corrija o bug e confirme a correção em um ou mais commits separados.
Terminando um ramo de hotfix.
Quando terminar, o bugfix precisa ser mesclado de volta ao master, mas também precisa ser mesclado de volta para desenvolver, a fim de salvaguardar que o bugfix também seja incluído no próximo release. Isso é completamente semelhante a como os ramos de liberação são concluídos.
Primeiro, atualize o mestre e marque o lançamento.
Edit: Você também pode querer usar o - s ou - u & lt; key & gt; sinalizadores para assinar sua tag criptograficamente.
Em seguida, inclua o bugfix no desenvolvimento também:
A única exceção à regra aqui é que, quando uma ramificação de release existe atualmente, as alterações de hotfix precisam ser mescladas nessa ramificação de release, em vez de desenvolver. Voltar a mesclar o bugfix na ramificação do release acabará resultando no bugfix sendo mesclado no desenvolvimento também, quando o branch release terminar. (Se o trabalho em desenvolvimento exigir imediatamente este bugfix e não puder esperar pelo término da ramificação do release, você poderá mesclar com segurança o bugfix em desenvolver agora também.)
Finalmente, remova o ramo temporário:
Embora não haja nada de realmente chocante neste modelo de ramificação, a figura “grande figura” com a qual este post começou se mostrou extremamente útil em nossos projetos. Forma um modelo mental elegante que é fácil de compreender e permite que os membros da equipe desenvolvam uma compreensão compartilhada dos processos de ramificação e liberação.
Uma versão em PDF de alta qualidade da figura é fornecida aqui. Vá em frente e pendure-o na parede para referência rápida a qualquer momento.
Atualização: para quem solicitou: veja o gitflow-model. src. key da imagem do diagrama principal (Apple Keynote).
Se você quiser entrar em contato, eu sou @nvie no Twitter.
Vincent Driessen é um engenheiro de software e consultor independente de Python da Holanda. Você pode contratá-lo.

Estratégia de controle de revisão de versão a ser sugerida
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 com problemas.
Fora da caixa, o git parece não funcionar bem para o desenvolvimento centralizado em uma grande organização (com mais de 20 desenvolvedores), com desenvolvedores de diferentes capacidades e níveis de sofisticação - especialmente em comparação com outros sistemas de controle de origem como Perforce ou Subversion, que são destinados a esse tipo de ambiente. (Sim, eu sei, Linus nunca pretendeu isso.)
Mas - por razões políticas - estamos presos ao idiota, mesmo que seja uma droga para o que estamos tentando fazer com isso.
Aqui estão algumas das coisas que estamos vendo:
As ferramentas GUI não são maduras Usando as ferramentas de linha de comando, é muito fácil desmembrar uma mesclagem e apagar as alterações de outra pessoa Não oferece permissões de repositório por usuário além dos privilégios globais de somente leitura ou leitura / gravação Se você tiver uma permissão para QUALQUER parte de um repositório, você pode fazer a mesma coisa em TODAS as partes do repositório, então você não pode fazer algo como fazer uma ramificação de rastreamento de grupo pequeno no servidor central que outras pessoas não podem mexer. Fluxos de trabalho diferentes de "vale tudo" ou "ditador benevolente" são difíceis de encorajar, quanto mais reforçar Não está claro se é melhor usar um único repositório grande (que deixa todo mundo bagunçar tudo) ou muitos repositórios por componente (que fazem para dores de cabeça tentando sincronizar versões). Com vários repositórios, também não está claro como replicar todas as fontes que alguém tem, 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ê está nessa situação - ou se você geralmente tem ferramentas, dicas e truques para tornar mais fácil e produtivo usar o git em uma grande organização onde algumas pessoas não são fãs de linha de comando - eu adoraria ouvir o que você tem sugerir.
BTW, eu já pedi uma versão desta questão no LinkedIn, e não tenho respostas reais, mas um monte de "poxa, eu adoraria saber disso também!"
ATUALIZAÇÃO: Deixe-me esclarecer.
Onde eu trabalho, não podemos usar nada além de git. Não é uma opção. Estamos presos a isso. Não podemos usar o mercurial, svn, bitkeeper, Visual Source Safe, ClearCase, PVCS, SCCS, RCS, bazar, Darcs, monotone, Perforce, Fossil, AccuRev, CVS ou mesmo o bom e velho projetor da Apple que usei em 1987. Então, enquanto você é bem-vindo para discutir outras opções, você não vai receber a recompensa se você não discutir sobre o git.
Além disso, estou procurando dicas práticas sobre como usar o git na empresa. Eu coloquei uma lista completa de problemas que estamos tendo no topo desta questão. Novamente, as pessoas são bem-vindas para discutir a teoria, mas se você quiser ganhar a recompensa, me dê soluções.
16 respostas.
Contra a opinião comum, acho que usar um DVCS é uma escolha ideal em um ambiente corporativo, pois permite fluxos de trabalho muito flexíveis. Vou falar sobre o uso de um DVCS versus CVCS primeiro, melhores práticas e, em seguida, sobre git em particular.
DVCS vs. CVCS em um contexto corporativo:
Eu não vou falar sobre os prós / contras gerais aqui, mas sim focar no seu contexto. É a concepção comum, que usando um DVCS requer uma equipe mais disciplinada do que usando um sistema centralizado. Isso ocorre porque um sistema centralizado oferece a você uma maneira fácil de impor seu fluxo de trabalho. O uso de um sistema descentralizado requer mais comunicação e disciplina para manter as convenções estabelecidas. Embora isso possa parecer que induz a sobrecarga, vejo benefício no aumento da comunicação necessária para torná-lo um bom processo. Sua equipe precisará se comunicar sobre código, sobre mudanças e sobre o 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 bliki de Martin Fowler em Version Control Tools, ele encontrou uma descrição muito concisa para este fenômeno.
O DVCS incentiva a ramificação rápida para experimentação. Você pode fazer ramificações no Subversion, mas o fato de que elas são visíveis para todos desencoraja as pessoas a abrir um branch para trabalhos experimentais. Da mesma forma, um DVCS encoraja a verificação de apontar o trabalho: cometer alterações incompletas, que podem nem mesmo compilar ou passar testes, para o seu repositório local. Novamente, você poderia fazer isso em uma ramificação de desenvolvedor no Subversion, mas o fato de essas ramificações estarem 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 rastreiem de forma transparente a origem e o histórico de um conjunto de alterações, o que pode ser muito importante.
Larry Osterman (um desenvolvedor da Microsoft que trabalha na equipe do Windows) tem uma ótima postagem no blog sobre o fluxo de trabalho que eles empregam na equipe do Windows. Mais notavelmente eles têm:
Um tronco somente de código limpo e de alta qualidade (master repo) Todo o desenvolvimento acontece em filiais de recursos As equipes de recursos têm repos de equipe Eles mesclam regularmente as últimas trocas de tronco em seu ramo de recursos (Integração avançada) revisão, cobertura de teste, Q & A (repos por conta própria) Se um recurso for concluído e tiver qualidade aceitável, ele será mesclado no tronco (Reverse Integrate)
Como você pode ver, cada um desses repositórios vive por conta própria e você pode separar equipes diferentes avançando em ritmos diferentes. Além disso, a possibilidade de implementar um sistema flexível de gate de qualidade distingue o DVCS de um CVCS. Você também pode resolver seus problemas de permissão nesse nível. Apenas um punhado de pessoas deve ter acesso ao master repo. 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 de equipe. Você deve deixar para cada equipe decidir se quer compartilhar o repo entre eles ou se eles querem uma abordagem mais hierárquica, onde apenas o líder da equipe pode se comprometer com o repo da equipe.
(A foto é roubada do hginit de Joel Spolsky.)
No entanto, uma coisa permanece a ser dita: - embora o DVCS forneça excelentes recursos de mesclagem, isso nunca substitui o uso da Integração Contínua. Mesmo nesse ponto, você tem muita flexibilidade: CI para o repositório de troncos, CI para repos de equipe, Q & A repos etc.
Git em um contexto corporativo:
O Git talvez não seja a solução ideal para um contexto corporativo, como você já apontou. Repetindo algumas de suas preocupações, eu acho que são mais notáveis:
Ainda suporte um pouco imaturo no Windows (por favor corrija-me se isso mudou recentemente) Agora o windows tem github windows client, tortoisegit, SourceTree de atlassian Falta de ferramentas GUI maduras, sem integração de ferramenta de mesclagem vdiff / merge cidadão de primeira classe Interface inconsistente com um nível muito baixo abstrações no topo de seu funcionamento interno Uma curva de aprendizado muito íngreme 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ê acha que sabia ) Nenhuma opção de suporte comercial disponível.
I don't want to start a git vs. hg flamewar here, you have already done the right step by switching to a DVCS. Mercurial addresses some of the points above and I think it is therefore better suited in an enterprise context:
All plattforms that run python are supported Great GUI tools on all major plattforms (win/linux/OS X), first class merge/vdiff tool integration Very consistent interface, easy transition for svn users Can do most of the things git can do too, but provides a cleaner abstraction. Dangerous operations are are always explicit. Advanced features are provided via extensions that must explicitly be enabled. Commercial support is available from selenic.
In short, when using DVCS in an enterprise I think it's important to choose a tool that introduces the least friction. For the transition to be successful it's especially important to consider the varying skill between developers (in regards to VCS).
Ok, since you appear to be really stuck with the situation, there are two options left IMHO. There is no tool to make git less complicated; git is complicated. Either you confront this or work around git:-
Get a git introductory course for the whole team. This should include the basics only and some exercises (important!). Convert the master repo to svn and let the "young-stars" git-svn. This gives most of the developers an easy to use interface and may compensate for the lacking discipline in your team, while the young-stars can continue to use git for their own repos.
To be honest, I think you really have a people problem rather than a tool problem. What can be done to improve upon this situation?
You should make it clear that you think your current process will end up with a maintainable codebase. Invest some time into Continous Integration. As I outlined above, regardless which kind of VCS you use, there's never a replacement for CI. You stated that there are people who push crap into the master repo: Have them fix their crap while a red alert goes off and blames them for breaking the build (or not meeting a quality metric or whatever).
I'm the SCM engineer for a reasonably large development organization, and we converted to git from svn over the last year or so. We use it in a centralized fashion.
We use gitosis to host the repositories. We broke our monolithic svn repositories up into many smaller git repositories as git's branching unit is basically the repository. (There are ways around that, but they're awkward.) If you want per-branch kinds of access controls, gitolite might be a better approach. There's also an inside-the-firewall version of GitHub if you care to spend the money. For our purposes, gitosis is fine because we have pretty open permissions on our repositories. (We have groups of people who have write access to groups of repositories, and everyone has read access to all repositories.) We use gitweb for a web interface.
As for some of your specific concerns:
merges: You can use a visual merge tool of your choice; there are instructions in various places on how to set it up. The fact that you can do the merge and check its validity totally on your local repo is, in my opinion, a major plus for git; you can verify the merge before you push anything. GUIs: We have a few people using TortoiseGit but I don't really recommend it; it seems to interact in odd ways with the command line. I have to agree that this is an area that needs improvement. (That said, I am not a fan of GUIs for version control in general.) small-group tracking branches: If you use something that provides finer-grained ACLs like gitolite, it's easy enough to do this, but you can also create a shared branch by connecting various developers' local repositories — a git repo can have multiple remotes.
We switched to git because we have lots of remote developers, and because we had many issues with Subversion. We're still experimenting with workflows, but at the moment we basically use it the same way as we used to use Subversion. Another thing we liked about it was that it opened up other possible workflows, like the use of staging repositories for code review and sharing of code among small groups. It's also encouraged a lot of people to start tracking their personal scripts and so forth because it's so easy to create a repository.
Yes, I know, Linus never intended it for that.
Actually, Linus argues that centralized systems just can't work.
Remember, git is a distributed system; don't try to use it like a central one.
Most of your problems will go away if you don't try to use git as if it was "svn on steroids" (because it's not).
Instead of using a bare repository as a central server where everyone can push to (and potentially screw up), setup a few integration managers that handle merges, so that only they can push to the bare repository.
Usually these people should be the team leads: each leader integrates his own team's work and pushes it to the blessed repository.
Even better, someone else (i. e. dictator) pulls from the team leaders and integrates their changes into the blessed repository.
There's nothing wrong with that workflow, but we're an overworked startup and need our tools to substitute for human time and attention; nobody has bandwidth to even do code reviews, let alone be benevolent dictator.
If the integrators don't have time to review code, that's fine, but you still need to have people that integrate the merges from everybody.
Doing git pulls doesn't take all that much time.
git does substitute for human time and attention; that's why it was written in the first place.
The gui tools can handle the basic stuff pretty well.
Advanced operations require a coder/nerdy mindset (e. g. I'm comfortable working from the command line). It takes a bit of time to grasp the concepts, but it's not that hard.
Using the command line tools, it's far to easy to screw up a merge and obliterate someone else's changes.
This won't be a problem unless you have many incompetent developers with full write access to the "central repository".
But, if you set up your workflow so that only a few people (integrators) write to the "blessed" repository, that won't be a problem.
Git doesn't make it easy to screw up merges.
When there are merge conflicts, git will clearly mark the conflicting lines so you know which changes are yours and which are not.
It's also easy to obliterate other people's code with svn or any other (non-dsitributed) tool. In fact, it's way easier with these other tools because you tend to "sit on changes" for a long time and at some point the merges can get horribly difficult.
And because these tools don't know how to merge, you end up always having to merge things manually. For example, as soon as someone makes a commit to a file you're editing locally, it will be marked as a conflict that needs to be manually resolved; now that is a maintenance nightmare.
With git, most of the time there won't be any merge conflicts because git can actually merge. In the case where a conflict does occur, git will clearly mark the lines for you so you know exactly which changes are yours and which changes are from other people.
If someone obliterates other people's changes while resolving a merge conflict, it won't be by mistake: it will either be because it was necessary for the conflict resolution, or because they don't know what they're doing.
It doesn't offer per-user repository permissions beyond global read-only or read-write privileges.
If you have a permission to ANY part of a repository, you can do that same thing to EVERY part of the repository, so you can't do something like make a small-group tracking branch on the central server that other people can't mess with.
These problems will go away when you stop trying to use git as if it was a centralized system.
It's not clear whether it's better to use a single big repository (which lets everybody mess with everything) or lots of per-component repositories (which make for headaches trying to synchronize versions).
What kind of projects do you have?
For example: does version x. y of project A depend on exactly version w. z of project B such that every time you check x. y of project A you also have to checkout w. z of project B, otherwise it won't build? If so I'd put both project A and project B in the same repository, since they're obviously two parts of a single project.
The best practice here is to use your brain.
With multiple repositories, it's also not clear how to replicate all the sources someone else has by pulling from the central repository, or to do something like get everything as of 4:30 yesterday afternoon.
I'm not sure what you mean.
I highly recommend code. google/p/gerrit/ for enterprise work. It gives you access control plus a built-in review based workflow. It authenticates against any LDAP system. You can hook it up to Hudson with wiki. hudson-ci/display/HUDSON/Gerrit+Plugin, letting you build and test changes while they're still under review; it's a really impressive setup.
If you decide to use gerrit, I recommend trying to keep a pretty linear history, not a branchy history like some of the open source guys like. Gerrit phrases this as "allow fast-forward changes only." Then you can use branching and merging in more the the way you're used to, for releases and whatnot.
I am answering this question based on my experience as developer manager in a large telco, where we adopted Git in 2010.
You have quite different set of problems here:
workflows client tools server access control and integration.
We successfully adopted a central repository mode: what we have in our enterprise project (a large portal for a 5 million user base) is a de-facto central repository that produces the official builds then are taken trough the delivery process (which, in our case, is composed of three level of testing and two deployments). Every developer manages his own repo, and we work on a branch-per-feature basis.
There are now several options available, this is now a very crowded area. Many developers are successfully using IntelliJ Idea and Eclipse with the Git plugin, without any other stuff. Also most of the Linux developers are using CLI git client, without any problem. Some Mac developers are successfully using Tower Git. Please note that none of these clients can prevent the user to "mess up" with the central repository: a server side control mechamism is needed.
Server access control and integration.
If you want to avoid developers "messing up" you Git repository, you reall need to choose a solution that:
exposes a decent web admin interface to do every operation allows you to enforce user identities (using a "bare" Git repository is extremely easy to commit in behalf of someone else) provides you fine grained security (so that for example you can prevent FORCE-PUSH and set some branches to read only for some developers / groups) integrate with your corporate authentication system (i. e. LDAP, Windows ActiveDirectory) provides you full audit (SOX compliance is sometimes very important for large corporates)
There are not so many ready-to-use server side solutions that can help this, I suggest you check out one of these:
Gitorious: it can provide basic access level security, but it lacks fine grained permissions control out of the box, so you will probably have to do some coding to handle scenarios such as branch level permissions. It also lacks integration with existing corporate authentication mechanisms GitHub Enterprise: recently published by GitHub, it features GitHub in your corporate. It lacks SOX complianance and fine grained security Gerrit: it can provide fine graind access level security and integration with corporate authentication systems but it lacks SOX compliance and SSO. Also some operations can only be done via SSH via CLI GitEnterprise: it provides branch level permissions, SSO, SOX compliance, full web based administration. It was recently also integrated with Gerrit, so that it also provides you a full Gerrit instance.
Espero que isto ajude!
On the tools , MacOS-X users find GitX (gitx. frim. nl/) very simple and effective. Drawback is that doesn't support Git Client hooks (the ones under $GIT_ROOT/.git/hooks).
Overall I do strongly to chose a tool that supports fine-grained access control on: - branches (in order to segregate the stable release branches with strict security from the topic-branches that needs more agility and flexibility) - identity enforcement (author / committer). This is KEY for SOX - git commands restrictions - audit-trail. This is KEY for SOX.
The ones I've successfully used with those features are:
Gerrit Code Review (code. google/p/gerrit/) GitEnterprise (gitenterprise) CollabNet TeamForge (collab/gotgit), uses Gerrit 2.1.8 behind the scenes.
P. S. Do not underestimate SOX and CMMI compliance : many times there is limited set of choice you have that is dictated by your Company Enterprise Policies on Security.
Espero que isto ajude.
We recently switched from svn to git. Because git-daemon doesn't work with msysgit we opted for a central repository approach on a Linux server with gitosis.
To eliminate the possibility to screw up master we simply delted it. Instead we prepare all releases by merging the branches that are selected for testing and tag the merge. If it passes tests the commit is tagged with a version and put in production.
To handle this we have a rotating role of release manager. The release manager is responsible for reviewing each branch before it is ready for test. Then when the product ownder decides it is time to bundle the approved branches together for a new test release the release manager perform the merge.
We also have a rotating role of 2'nd level help desk and at least for us the workload is such that it is possible to have both roles at the same time.
As a benefit of not having a master it is not possible to add any code to the project without going through the release manager so we discovered directly how much code that was silently added to the project before.
The review process starts with the branch owner submiting the diff to reviewboard and putting up a green post-it on the whiteboard with the branch name (we have a Kanban based workflow) under "for review", or if it's part of a completed user story, move the entire story card to "for review" and put the postit on that. The relase manager is the one who moves cards and post-its to "ready for test" and then the product owner can select which ones to incled in the next test release.
When doing the merge the release manager also makes sure that the merge commit has a sensible commit message which can be used in the changelog for the product owner.
When a release has been put in production the tag is used as the new base for branches and all existing branches are merged with it. This way all branches has a common parent which makes it easier to handle merges.
It sounds like your problem is that you haven't decided on or instituted a workflow. Git is flexible enough to use it like svn or any other VCS, but it's so powerful that if you don't establish rules that everybody must follow then you're just gonna end up with a mess. I would recommend the dictator-lieutenant workflow that somebody mentioned above, but combined with the branching model described by Vincent Driessen. For more info see these screencasts by David Bock, and this one by Mark Derricutt.
I'll add in a "have you considered" post too.
One of the great things about Bazaar is its flexibility. This is where it beats all the other distributed systems. You can operate Bazaar in centralized mode, distributed mode, or get this: both (meaning developers can choose which model they're comfortable with or which works best for their workgroup). You can also disconnect a centralized repository while you're on the road and reconnect it when you get back.
On top of that, excellent documentation and something which will make your enterprise happy: commercial support available.
Install a decent web interface, like Github FI Stick to a relatively centralized model (initially) to keep people comfortable. Run a Continuous Integration build for every shared branch. Share a good set of global git config options. Integrate git into your shell, with bash completion, and a prompt with the current branch. Try IntelliJ's Git Integration as a merge tool. Make sure you. gitignore as appropriate.
Regarding points 3 & 4 (per-user, per-section, per-branch permissions), have a look at gitolite (covered in the Pro Git book: progit/book/ch4-8.html).
Politics or not, Git is as good a choice of a DCVS as any. Like any powerful tool, it is worth spending a little bit of time up front in understanding how the tool is designed to work, and, to this end, I highly recommend the Pro Git book. A couple of hours spent with it will save lots of frustration in the long run.
GUI: At the moment, TortoiseGit v1.7.6 should be fine for most daily operations. Log, Commit, Push, Pull, Fetch, Diff, Merge, Branch, Cherry-pick, Rebase, Tag, Export, Stash, Add submodule, etc. Supports x64 natively too.
In order to use git efficiently in a development team with lots of developers, a CI system that builds and tests continuously is required. Jenkins provides such a vehicle and I highly recommend that. The integration piece has to be done no matter what and it's a lot cheaper doing that earlier and more often.
More suited for collabrative development than gitosis or gitolite but open-source is Gitorious. It's a Ruby on Rails application which handles management of repositories and merging. It should solve many of your problems.
Git allows to create private branches. This encourage developers to commit often so as to break down modifications into small commits. When the developer is ready to publish his changes, he pushes to central server. He can make use of pre-commit scripts to verify his code if needed.

Version Your App.
Your app must be versioned Set the version in the app's Gradle build files How you version your apps affects how users upgrade Determine your versioning strategy early in the development process, including considerations for future releases.
In this document.
Versioning is a critical component of your app upgrade and maintenance strategy. Versioning is important because:
Users need to have specific information about the app version that is installed on their devices and the upgrade versions available for installation. Other apps — including other apps that you publish as a suite — need to query the system for your app's version, to determine compatibility and identify dependencies. Services through which you will publish your app(s) may also need to query your app for its version, so that they can display the version to users. A publishing service may also need to check the app version to determine compatibility and establish upgrade/downgrade relationships.
The Android system uses your app's version information to protect against downgrades. The system does not use app version information to enforce restrictions on upgrades or compatibility of third-party apps. Your app must enforce any version restrictions and should tell users about them.
The Android system does enforce system version compatibility as expressed by the minSdkVersion setting in the build files. This setting allows an app to specify the minimum system API with which it is compatible. For more information see Specifying Minimum System API Version.
Set Application Version Information.
To define the version information for your app, set values for the version settings in the Gradle build files. These values are then merged into your app's manifest file during the build process.
Note: If your app defines the app version directly in the <manifest> element, the version values in the Gradle build file will override the settings in the manifest. Additionally, defining these settings in the Gradle build files allows you to specify different values for different versions of your app. For greater flexibility and to avoid potential overwriting when the manifest is merged, you should remove these attributes from the <manifest> element and define your version settings in the Gradle build files instead.
Two settings are available, and you should always define values for both of them:
versionCode — An integer used as an internal version number. This number is used only to determine whether one version is more recent than another, with higher numbers indicating more recent versions. This is not the version number shown to users; that number is set by the versionName setting, below. The Android system uses the versionCode value to protect against downgrades by preventing users from installing an APK with a lower versionCode than the version currently installed on their device.
The value is an integer so that other apps can programmatically evaluate it, for example to check an upgrade or downgrade relationship. You can set the value to any integer you want, however you should make sure that each successive release of your app uses a greater value. You cannot upload an APK to the Play Store with a versionCode you have already used for a previous version.
Note: In some specific situations, you might wish to upload a version of your app with a lower versionCode than the most recent version. For example, if you are publishing multiple APKs, you might have pre-set versionCode ranges for specific APKs. For more about assigning versionCode values for multiple APKs, see Multiple APK Support.
Typically, you would release the first version of your app with versionCode set to 1, then monotonically increase the value with each release, regardless of whether the release constitutes a major or minor release. This means that the versionCode value does not necessarily have a strong resemblance to the app release version that is visible to the user (see versionName , below). Apps and publishing services should not display this version value to users.
Warning: The greatest value Google Play allows for versionCode is 2100000000.
The value is a string so that you can describe the app version as a <major>.<minor>.<point> string, or as any other type of absolute or relative version identifier. The versionName has no purpose other than to be displayed to users.
You can define default values for these settings by including them in the defaultConfig <> block, nested inside the android <> block of your module's build. gradle file. You can then override these default values for different versions of your app by defining separate values for individual build types or product flavors. The following build. gradle file shows the versionCode and versionName settings in the defaultConfig <> block, as well as the productFlavors <> block.
In the defaultConfig <> block of this example, the versionCode value indicates that the current APK contains the second release of the app, and the versionName string specifies that it will appear to users as version 1.1. This build. gradle file also defines two product flavors, "demo" and "full." Since the "demo" product flavor defines versionName as "1.1-demo", the "demo" build uses this versionName instead of the default value. The "full" product flavor block does not define versionName , so it uses the default value of "1.1".
The Android framework provides an API to let you query the system for version information about your app. To obtain version information, use the getPackageInfo(java. lang. String, int) method of PackageManager .
Note: When you use Instant Run, Android Studio automatically sets the versionCode to MAXINT and the versionName to "INSTANTRUN" .
Specify API Level Requirements.
If your app requires a specific minimum version of the Android platform, you can specify that version requirement as API level settings in the app's build. gradle file. During the build process, these settings are merged into your app's manifest file. Specifying API level requirements ensures that your app can only be installed on devices that are running a compatible version of the Android platform.
Note: If you specify API level requirements directly in your app's manifest file, the corresponding settings in the build files will override the settings in the manifest file. Additionally, defining these settings in the Gradle build files allows you to specify different values for different versions of your app. For greater flexibility and to avoid potential overwriting when the manifest is merged, you should remove these attributes from the <uses-sdk> element and define your API level settings in the Gradle build files instead.
There are two API level settings available:
minSdkVersion — The minimum version of the Android platform on which the app will run, specified by the platform's API level identifier. targetSdkVersion — Specifies the API level on which the app is designed to run. In some cases, this allows the app to use manifest elements or behaviors defined in the target API level, rather than being restricted to using only those defined for the minimum API level.
To specify default API level requirements in a build. gradle file, add one or more of the settings above to the defaultConfig <> block, nested inside the android <> block. You can also override these default values for different versions of your app by adding the settings to build types or product flavors. The following build. gradle file specifies default minSdkVersion and targetSdkVersion settings in the defaultConfig <> block and overrides minSdkVersion for one product flavor.
When preparing to install your app, the system checks the value of these settings and compares them to the system version. If the minSdkVersion value is greater than the system version, the system prevents the installation of the app.
If you do not specify these settings, the system assumes that your app is compatible with all platform versions.
For more information, see the <uses-sdk> manifest element documentation and the API Levels document. For Gradle build settings, see Configure Build Variants.
Except as noted, this content is licensed under Creative Commons Attribution 2.5. For details and restrictions, see the Content License.
Get the latest Android developer news and tips that will help you find success on Google Play.
You have successfully signed up for the latest Android developer news and tips.
Следите за новостями от Google Developers в WeChat.
Browse this site in ?
You requested a page in , but your language preference for this site is .
Would you like to change your language preference and browse this site in ? If you want to change your language preference later, use the language menu at the bottom of each page.
This class requires API level or higher.
This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.
For more information about specifying the API level your app requires, read Supporting Different Platform Versions.