estratégia de versão do Git
O Git é um sistema de controle de versão distribuído livre e de código aberto projetado para lidar com tudo, desde projetos pequenos a muito grandes com velocidade e eficiência.
Aprenda Git no seu navegador gratuitamente com Try Git.
As vantagens do Git em comparação com outros sistemas de controle de origem.
Documentação.
Páginas de referência do comando, conteúdo do livro Pro Git, vídeos e outros materiais.
Clientes GUI e lançamentos binários para todas as principais plataformas.
Envolver-se! Relatórios de erros, lista de discussão, bate-papo, desenvolvimento e muito mais.
Um modelo de ramificação bem sucedido Git.
na terça-feira, 05 de janeiro de 2010.
Nesta publicação, apresento o modelo de desenvolvimento que introduzi para alguns dos meus projetos (tanto no trabalho quanto no privado) há cerca de um ano e que resultou ser muito bem sucedido. Eu tenho significado escrever sobre isso por um tempo agora, mas nunca encontrei o tempo para fazê-lo tão bem, até agora. Não falo sobre nenhum dos detalhes dos projetos, apenas sobre a estratégia de ramificação e gerenciamento de lançamento.
Para uma discussão aprofundada sobre os prós e os contras do Git em comparação com os sistemas centralizados de controle de código fonte, consulte a web. Há muitas guerras de chama lá. Como desenvolvedor, prefiro o Git acima de todas as outras ferramentas em torno de hoje. Git realmente mudou a maneira como os desenvolvedores pensam em fusão e ramificação. Do mundo clássico CVS / Subversion de onde venho, a fusão / ramificação sempre foi considerada um pouco assustadora ("cuidado com os conflitos de fusão, 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 elas são consideradas uma das principais partes do seu fluxo de trabalho diário. Por exemplo, nos livros CVS / Subversion, a ramificação e a fusão são discutidas pela primeira vez nos capítulos posteriores (para usuários avançados), enquanto em todo livro Git já está coberto no capítulo 3 (noções básicas).
Como conseqüência de sua simplicidade e natureza repetitiva, ramificação e fusão já não são algo para ter medo. As ferramentas de controle de versão devem ajudar na ramificação / fusão mais do que qualquer outra coisa.
Basta sobre as ferramentas, vamos ao modelo de desenvolvimento. O modelo que vou apresentar aqui é essencialmente não mais do que um conjunto de procedimentos que cada membro da equipe deve 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 este modelo de ramificação, é a de um "repo" central "verdadeiro". Note-se que este repo é considerado apenas o central (uma vez que o Git é um DVCS, não há como um repo central a nível técnico). Referiremos este repo como origem, já que este nome é familiar para todos os usuários do Git.
Cada desenvolvedor puxa e empurra para origem. Mas, além dos relacionamentos centralizados push-pull, cada desenvolvedor também pode extrair as mudanças de outros pares para formar sub-equipes. Por exemplo, isso pode ser útil para trabalhar em conjunto com dois ou mais desenvolvedores em um novo recurso novo, antes de empurrar o trabalho em andamento para origem prematura. Na figura acima, existem subequipas de Alice e Bob, Alice e David, e Clair e David.
Tecnicamente, isso não significa nada além de que Alice definiu um controle remoto Git, chamado bob, apontando para o repositório de Bob e vice-versa.
Os principais ramos ¶
No núcleo, o modelo de desenvolvimento é muito inspirado por modelos existentes por aí. O repo central possui dois ramos principais com uma vida infinita:
O ramo mestre na origem deve ser familiar para cada usuário Git. Paralelamente ao ramo mestre, outro ramo existe chamado desenvolvimento.
Consideramos a origem / mestre como o ramo principal onde o código fonte da HEAD sempre reflete um estado pronto para produção.
Nós consideramos a origem / desenvolvimento ser o ramo principal onde o código fonte de HEAD sempre reflete um estado com as últimas mudanças de desenvolvimento entregues para a próxima versão. Alguns chamariam isso de "ramo de integração". É aí que são construídas todas as construções noturnas automáticas.
Quando o código-fonte no ramo de desenvolvimento atinge um ponto estável e está pronto para ser lançado, todas as mudanças devem ser mescladas de volta ao mestre de alguma forma e depois marcadas com um número de lançamento. Como isso é feito em detalhes, será discutido mais adiante.
Portanto, cada vez que as alterações são incorporadas de volta ao mestre, esta é uma nova versão de produção por definição. Nós tendemos a ser muito rigorosos nisso, de modo que, teoricamente, poderíamos usar um script de gancho Git para criar e implementar automaticamente nosso software em nossos servidores de produção toda vez que houve um commit no master.
Ramal de apoio ¶
Ao lado dos principais ramos, mestre e desenvolve, nosso modelo de desenvolvimento usa uma variedade de ramos de apoio para auxiliar o desenvolvimento paralelo entre os membros da equipe, facilitar o rastreamento de recursos, se preparar para lançamentos de produção e ajudar a resolver rapidamente problemas de produção ao vivo. Ao contrário dos ramos principais, esses ramos sempre têm um tempo de vida limitado, já que serão removidos eventualmente.
Os diferentes tipos de ramos que podemos usar são:
Cada um desses ramos tem um propósito específico e está vinculado a regras rígidas sobre quais ramos podem ser seu ramo de origem e quais ramos devem ser seus alvos de fusão. Vamos passar por eles 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 utilizamos. Eles são, naturalmente, antigos galhos Git.
Ramal de recursos ¶
Pode se ramificar de: desenvolver Devem juntar-se novamente para: desenvolver convenção de nomenclatura de ramo: qualquer coisa, exceto master, develop, release - * ou hotfix - *
Os ramos de recursos (ou às vezes chamados de ramos de tópicos) são usados para desenvolver novos recursos para a próxima ou futura versão futura. Ao iniciar o desenvolvimento de um recurso, a versão alvo em que esse recurso será incorporado pode muito bem ser desconhecida nesse ponto. A essência de um ramo de recursos é que ele existe enquanto o recurso estiver em desenvolvimento, mas eventualmente será incorporado de novo ao desenvolvimento (para adicionar definitivamente o novo recurso ao próximo lançamento) ou descartado (no caso de uma experiência decepcionante).
Os ramos de recursos geralmente existem apenas em repos de desenvolvedor, não de origem.
Criando um ramo de recursos ¶
Ao iniciar o trabalho em um novo recurso, saia do ramo de desenvolvimento.
Incorporando um recurso finalizado no desenvolvimento ¶
Os recursos finais podem ser incorporados no ramo de desenvolvimento para adicioná-los definitivamente ao próximo lançamento:
A bandeira --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 perder informações sobre a existência histórica de um ramo de recursos e agrupa todos os compromissos que juntos adicionaram o recurso. Comparar:
No último caso, é impossível ver a partir do histórico do Git quais dos objetos de compromisso juntos implementaram um recurso; você teria que ler manualmente todas as mensagens de log. Reverter um recurso inteiro (ou seja, um grupo de compromissos), é uma verdadeira dor de cabeça na última situação, enquanto que é facilmente feito se a bandeira --no-ff foi usada.
Sim, criará mais alguns objetos de confirmação (vazios), mas o ganho é muito maior do que o custo.
Divulgar ramos ¶
As filiais de lançamento suportam a preparação de uma nova versão de produção. Eles permitem o pontapé de última hora de i's e cross t's. Além disso, eles permitem pequenas correções de bugs e preparando meta-dados para uma versão (número de versão, datas de compilação, etc.). Ao fazer todo esse trabalho em um ramo de lançamento, o ramo de desenvolvimento é removido para receber recursos para a próxima grande versão.
O momento-chave para se ramificar de um novo ramo de lançamento 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 lançamento a ser construído devem ser incorporados para se desenvolver neste momento. Todos os recursos visados em lançamentos futuros não podem - eles devem esperar até que o ramo de lançamento seja derivado.
É exatamente no início de um ramo de lançamento que o próximo lançamento recebe um número de versão - não anteriormente. Até esse momento, o ramo de desenvolvimento refletiu alterações para a "próxima versão", mas não está claro se essa "próxima versão" acabará por ser 0.3 ou 1.0, até que o ramo de lançamento seja iniciado. Essa decisão é tomada no início do ramo de lançamento e é realizada pelas regras do projeto sobre o golpe de número da versão.
Criando um ramo de liberação ¶
Os ramos de lançamento são criados a partir do ramo de desenvolvimento. Por exemplo, digamos que a versão 1.1.5 é a versão atual da produção e temos uma grande versão. 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, nos ramificamos e damos ao ramo de lançamento um nome que reflete o novo número de versão:
Depois de criar um novo ramo e mudar para ele, superamos o número da versão. Aqui, bump-version. sh é um script de shell de ficção que altera alguns arquivos na cópia de trabalho para refletir a nova versão. (Naturalmente, isso pode ser uma mudança manual - o ponto é que alguns arquivos mudam.) Então, o número da versão atingida é cometido.
Este novo ramo pode existir lá por um tempo, até que a liberação possa ser lançada definitivamente. Durante esse período, correções de erros podem ser aplicadas neste ramo (em vez de no ramo de desenvolvimento). A adição de novos recursos novos aqui é estritamente proibida. Eles devem ser fundidos em desenvolver e, portanto, aguardar o próximo grande lançamento.
Finalizando um ramo de liberação ¶
Quando o estado do ramo de lançamento está pronto para se tornar uma versão real, algumas ações precisam ser realizadas. Primeiro, o ramo de lançamento é mesclado em mestre (uma vez que cada commit no master é uma nova versão por definição, lembre-se). Em seguida, esse commit no master deve ser marcado para facilitar a referência futura a esta versão histórica. Finalmente, as mudanças feitas no ramo de lançamento precisam ser incorporadas de volta ao desenvolvimento, de modo que os lançamentos futuros também contenham essas correções de bugs.
As duas primeiras etapas no Git:
A versão agora está concluída e marcada para futuras referências.
Editar: Você também pode querer usar a tecla - s ou - u & lt; key & gt; bandeiras para assinar sua marca criptograficamente.
Para manter as mudanças feitas no ramo de lançamento, precisamos juntar esses de volta ao desenvolvimento. Em Git:
Este passo pode levar a um conflito de mesclagem (provavelmente mesmo, uma vez que mudamos o número da versão). Se sim, conserte e cometer.
Agora, estamos realmente finalizados e o ramo de lançamento pode ser removido, já que não precisamos mais disso:
Filiais de Hotfix ¶
Pode se ramificar de: master Deve juntar-se novamente para: desenvolver e dominar a convenção de nomenclatura de ramo: hotfix - *
Os ramos do Hotfix são muito parecidos com os ramos de lançamento, pois eles também devem se preparar para uma nova versão de produção, embora não planejada. Eles surgem da necessidade de agir imediatamente após um estado indesejado de uma versão de produção ao vivo. Quando um erro crítico em uma versão de produção deve ser resolvido imediatamente, um ramo de hotfix pode ser derivado da tag correspondente na ramificação mestre 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 rápida solução de produção.
Criando o ramo do hotfix ¶
Os ramos de Hotfix 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 erro grave. Mas as mudanças no desenvolvimento ainda são instáveis. Podemos então ramo de um ramo de hotfix e começar a solucionar o problema:
Não esqueça de colidir o número da versão após a ramificação!
Em seguida, corrija o erro e cometer a correção em um ou mais compromissos separados.
Finalizando um ramo de hotfix.
Quando terminar, o bugfix precisa ser mesclado novamente no mestre, mas também precisa ser incorporado novamente para desenvolver, a fim de garantir que o bugfix também esteja incluído na próxima versão. Isso é completamente semelhante ao modo como os ramos de liberação são finalizados.
Primeiro, atualize o mestre e marque o lançamento.
Editar: Você também pode querer usar a tecla - s ou - u & lt; key & gt; bandeiras para assinar sua marca criptograficamente.
Em seguida, inclua o bugfix em develop, também:
A única exceção à regra aqui é que, quando um ramo de lançamento atualmente existe, as alterações de hotfix precisam ser incorporadas nesse ramo de liberação, em vez de se desenvolverem. A fusão posterior do bugfix no ramo de lançamento acabará resultando em que o bugfix seja incorporado ao desenvolvimento também, quando o ramo de lançamento estiver concluído. (Se o trabalho em desenvolver imediatamente requer esse bugfix e não aguarde até que o ramo de liberação seja concluído, você pode combinar com segurança o bugfix para desenvolver agora também.)
Finalmente, remova o ramo temporário:
Embora não haja nada de realmente chocante para este modelo de ramificação, a figura "grande imagem" que esta publicação começou com revelou ser tremendamente útil em nossos projetos. Forma um modelo mental elegante que é fácil de compreender e permite aos membros da equipe desenvolver 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 coloque-o na parede para obter uma referência rápida a qualquer momento.
Atualização: e para quem o solicitou: aqui está o gitflow-model. src. key da imagem do diagrama principal (Apple Keynote).
Se você quiser entrar em contato, sou o Twitter no Twitter.
Vincent Driessen é um engenheiro independente de software Python e consultor da Holanda. Você pode contratá-lo.
estratégia de versão do Git
Obter através da App Store Leia esta publicação em nosso aplicativo!
Controle de versão e estratégia Git? [fechadas]
Eu uso o git para manter algum tipo de controle de versão e sincronizar meu trabalho em várias máquinas, pois eu costumo trabalhar em várias máquinas. Eu sou a única pessoa a trabalhar no meu código.
Eu posso fazer a maioria dos princípios básicos com git, e. git checkout um arquivo para retornar um arquivo individual para um estado anterior, e usar git reverter (eu dread usando git reverter, já que ainda não entendi algumas das suas complexidades completas) para retornar todo o projeto para um estado anterior. Eu tambem às vezes uso git branch para adivinhar o código em uma direção diferente, especialmente se eu não tiver certeza da direção.
O meu conhecimento do git no entanto é um pouco tênue e ainda tendem a manter o arquivo de origem progressivamente enquanto eu trabalho mais adiante. por exemplo. Talvez eu esteja trabalhando no projeto18.c no momento em que terminei, tendo passado por 1. 18 enquanto trabalho pelo código. Isto é, além de fazer git com frequência, enquanto trabalha no arquivo, de modo efetivo, eu tenho duas maneiras de "marcar de volta" meu trabalho no projeto. Esta numeração de arquivos incremental no entanto, não funciona bem com o código espalhado em vários arquivos, pois manter um registro de um recurso implementado em vários arquivos fica muito louco. Eu suspeito que, trabalhando com mais força na criação de funções autônomas que encapsulam e ocultando a implementação interna das funções circundantes, é uma solução mais elegante para alguns dos meus problemas.
Muitas vezes, as pessoas sugerem que executem um compromisso de git para cada novo recurso ou peça de código importante, no entanto, quando falho em realizar compromissos de git freqüentes, muitas vezes gasto uma quantidade excessiva de tempo manualmente "fazendo o backup de" um código de buggy, se eu Estou abandonando essa maneira particular de implementar o código. Eu suspeito que um melhor planejamento // design do código com antecedência às vezes pode ajudar, mas muitas vezes é difícil antecipar completamente o que acabará por ser um ponto morto ou um código de buggy.
Procuro uma estratégia prática para o controle de versões, que auxilia especialmente quando as coisas não estão indo bem, e que ajuda a depurar as partes do problema.
fechado como não construtivo por Holger Just, Aleks G, Florent, mosquito, Toto 16 de outubro '12 às 8:10.
Como está atualmente, esta questão não é uma boa opção para o nosso formato Q & amp; A. Esperamos que as respostas sejam apoiadas por fatos, referências ou conhecimentos, mas esta questão provavelmente solicitará debate, argumentos, votação ou discussão prolongada. Se você acha que esta questão pode ser melhorada e possivelmente reaberta, visite o centro de ajuda para orientação. Se esta questão pode ser reformulada para ajustar as regras no centro de ajuda, edite a questão.
Se você é sério sobre seus hábitos de trabalho (como se você quisesse escrever código para viver ou contribuir com algum projeto de software livre), é melhor se acostumar a cometer frequentemente. Os compromissos ainda devem ter alguma lógica neles, é um faux pas para ter um commit separado para cada dez linhas de código que você escreve. Small & amp; Os compromissos lógicos são bons de rever ou bisecar, se você encontrar uma regressão.
Se você precisa ter muitos pontos de controle, você pode ter um compromisso para o conjunto de teste para o recurso em que está trabalhando e um compromisso para cada parte que passa do conjunto de teste. Ou algo assim, dependendo do seu estilo de trabalho. (Com o Git, você sempre pode limpar o histórico ao publicar as alterações, se necessário). Se você achar que não é suficiente, você está fazendo algo errado.
A solução para o seu problema vem em duas partes diferentes:
O que é o controle de versão.
Os sistemas de controle de versão são uma categoria de ferramentas de software que ajudam uma equipe de software a gerenciar as alterações ao código-fonte ao longo do tempo. O software de controle de versão acompanha todas as modificações no código em um tipo especial de banco de dados. Se um erro for feito, os desenvolvedores podem voltar o relógio e comparar versões anteriores do código para ajudar a corrigir o erro, minimizando a interrupção de todos os membros da equipe.
Para quase todos os projetos de software, o código fonte é como as jóias da coroa - um recurso precioso cujo valor deve ser protegido. Para a maioria das equipes de software, o código-fonte é um repositório do inestimável conhecimento e compreensão sobre o domínio do problema que os desenvolvedores coletaram e refinaram através de um esforço cuidadoso. O controle de versão protege o código fonte da catástrofe e a degradação casual do erro humano e conseqüências não desejadas.
Os desenvolvedores de software que trabalham em equipes estão escrevendo continuamente novos códigos-fonte e alterando o código-fonte existente. O código para um projeto, aplicativo ou componente de software normalmente é organizado em uma estrutura de pastas ou "árvore de arquivos". Um desenvolvedor da equipe pode estar trabalhando em um novo recurso, enquanto outro desenvolve um erro não relacionado alterando o código, cada desenvolvedor pode fazer suas alterações em várias partes da árvore de arquivos.
O controle de versão ajuda as equipes a resolver esses tipos de problemas, rastreando todas as mudanças individuais por cada colaborador e ajudando a evitar que o trabalho concorrente seja conflitante. As mudanças feitas em uma parte do software podem ser incompatíveis com as feitas por outro desenvolvedor trabalhando ao mesmo tempo. Este problema deve ser descoberto e resolvido de forma ordenada sem bloquear o trabalho do resto do time. Além disso, em todo o desenvolvimento de software, qualquer alteração pode introduzir novos erros por conta própria e o novo software não pode ser confiável até que seja testado. Então o teste eo desenvolvimento continuam juntos até que uma nova versão esteja pronta.
Um bom software de controle de versão suporta o fluxo de trabalho preferido de um desenvolvedor sem impor uma maneira particular de trabalhar. Idealmente, ele também funciona em qualquer plataforma, em vez de ditar o que o sistema operacional ou os desenvolvedores da cadeia de ferramentas devem usar. Os grandes sistemas de controle de versões facilitam o fluxo contínuo e contínuo de mudanças no código e não o mecanismo frustrante e desajeitado de bloqueio de arquivos - dando a luz verde a um desenvolvedor à custa de bloquear o progresso de outros.
As equipes de software que não usam qualquer tipo de controle de versão freqüentemente se deparam com problemas, como não saber quais as mudanças que foram feitas, estão disponíveis para os usuários ou a criação de mudanças incompatíveis entre dois trabalhos não relacionados, que devem ser minuciosamente desenrolados e retrabalhados. Se você é um desenvolvedor que nunca usou o controle de versão, você pode ter adicionado versões aos seus arquivos, talvez com sufixos como "final" ou "mais recente" e depois teve que lidar com uma nova versão final. Talvez você tenha comentado blocos de código porque deseja desativar determinadas funcionalidades sem excluir o código, temendo que possa haver um uso para isso mais tarde. O controle de versão é uma saída desses problemas.
O software de controle de versão é uma parte essencial do dia a dia das práticas profissionais da equipe de software moderno. Os desenvolvedores de software individuais que estão acostumados a trabalhar com um sistema de controle de versão capaz em suas equipes geralmente reconhecem o incrível controle de versão de valor também os dá mesmo em pequenos projetos individuais. Uma vez acostumados aos poderosos benefícios dos sistemas de controle de versão, muitos desenvolvedores não considerariam trabalhar sem ele mesmo para projetos que não sejam de software.
Benefícios dos sistemas de controle de versão.
Desenvolver o software sem usar controle de versão é arriscado, como não ter backups. O controle de versão também pode permitir que os desenvolvedores se movam mais rápido e permite que as equipes de software preservem a eficiência e a agilidade à medida que a equipe escala para incluir mais desenvolvedores.
Sistemas de controle de versão (VCS) viram grandes melhorias nas últimas décadas e algumas são melhores do que outras. O VCS às vezes é conhecido como ferramentas SCM (Gerenciamento de código-fonte) ou RCS (Revision Control System). Uma das ferramentas VCS mais populares em uso hoje é chamada Git. Git é um Distributed VCS, uma categoria conhecida como DVCS, mais sobre isso mais tarde. Como muitos dos sistemas VCS mais populares disponíveis hoje, o Git é gratuito e de código aberto. Independentemente do que eles chamam, ou qual sistema é usado, os principais benefícios que você deve esperar do controle de versão são os seguintes.
Um histórico completo de mudanças de longo prazo de cada arquivo. Isso significa todas as mudanças feitas por muitos indivíduos ao longo dos anos. As mudanças incluem a criação e exclusão de arquivos, bem como as edições em seus conteúdos. Diferentes ferramentas de VCS diferem em quanto bem eles manipulam o renomeamento e o movimento de arquivos. Esta história também deve incluir o autor, a data e as notas escritas sobre a finalidade de cada alteração. Ter o histórico completo permite voltar às versões anteriores para ajudar na análise de causa raiz para erros e é crucial quando é necessário corrigir problemas em versões anteriores de software. Se o software estiver trabalhando ativamente, quase tudo pode ser considerado uma "versão antiga" do software.
Ramificação e fusão. Fazer com que os membros da equipe trabalhem simultaneamente é um insensivel, mas mesmo os indivíduos que trabalham por conta própria podem se beneficiar da capacidade de trabalhar em fluxos independentes de mudanças. Criando um & quot; branch & quot; nas ferramentas do VCS, as múltiplas correntes de trabalho são independentes umas das outras, ao mesmo tempo que fornecem facilidades para fundir o trabalho de volta, permitindo que os desenvolvedores verifiquem que as mudanças em cada ramo não conflitam. Muitas equipes de software adotam uma prática de ramificação para cada recurso ou talvez ramificação para cada lançamento, ou ambos. Existem muitos fluxos de trabalho diferentes que as equipes podem escolher quando decidem como fazer uso de instalações de ramificação e fusão no VCS.
Rastreabilidade. Ser capaz de rastrear cada mudança feita ao software e conectá-lo ao gerenciamento de projetos e ao software de rastreamento de erros, como Jira, e poder anotar cada alteração com uma mensagem descrevendo o propósito e a intenção da mudança podem ajudar não só com a análise de causa raiz e outros forenses. Ter o histórico anotado do código ao alcance de sua mão quando você está lendo o código, tentando entender o que está fazendo e por que ele é tão projetado pode permitir que os desenvolvedores façam mudanças corretas e harmoniosas que estejam de acordo com o design previsto a longo prazo do sistema. Isso pode ser especialmente importante para trabalhar efetivamente com o código legado e é crucial para permitir que os desenvolvedores estimem o trabalho futuro com qualquer precisão.
Embora seja possível desenvolver software sem usar qualquer controle de versão, o assunto é sujeito o projeto a um enorme risco de que nenhuma equipe profissional seja aconselhada a aceitar. Portanto, a questão não é se usar o controle de versão, mas qual o sistema de controle de versão a ser usado.
Há muitas escolhas, mas aqui vamos nos concentrar em apenas um, o Git.
estratégia de versão do Git
O mecanismo de mesclagem (git misge e git pull commands) permite que as "estratégias de mesclagem" do backend sejam escolhidas com a opção - s. Algumas estratégias também podem tomar suas próprias opções, que podem ser aprovadas ao dar - X & lt; option & gt; argumentos para combinar e / ou git pull.
Isso só pode resolver duas cabeças (ou seja, o ramo atual e outro ramo que você retirou) usando um algoritmo de mesclagem de 3 vias. Ele tenta detectar cuidadosamente as ambiguidades de mesclagem cruzada e é considerado geralmente seguro e rápido.
Isso só pode resolver duas cabeças usando um algoritmo de mesclagem de 3 vias. Quando há mais de um antepassado comum que pode ser usado para a mesclagem de 3 vias, ele cria uma árvore mesclada dos antepassados comuns e usa isso como a árvore de referência para a mesclagem de 3 vias. Isso foi relatado como resultado de menos conflitos de fusão sem causar mismerges por testes feitos em compromissos de fusão reais tirados do histórico de desenvolvimento do kernel do Linux 2.6. Além disso, isso pode detectar e manipular fusões envolvendo renomeações. Esta é a estratégia de mesclagem padrão ao puxar ou mesclar um ramo.
A estratégia "recursiva" pode ter as seguintes opções:
Esta opção força os tipos de conflitos a serem automaticamente resolvidos, favorecendo a "nossa" versão. As mudanças da outra árvore que não estão em conflito com o nosso lado são refletidas no resultado de mesclagem. Para um arquivo binário, todo o conteúdo é retirado do nosso lado.
Isso não deve ser confundido com a estratégia de "nossa", que nem sequer olha o que a outra árvore contém. Ele descarta tudo o que a outra árvore fez, declarando que "nossa" história contém tudo o que aconteceu nele.
Este é o oposto do "nosso"; note que, ao contrário do "nosso", não há "deles" mescla a estratégia para confundir esta opção de fusão.
Com esta opção, "merge-recursive" gasta um pouco de tempo extra para evitar mismerges que às vezes ocorrem devido a linhas de correspondência sem importância (por exemplo, chaves de funções distintas). Use isso quando os ramos a serem fundidos divergiram de forma selvagem. Veja também git-diff [1] - paciência.
Diz a "fusão-recursiva" para usar um algoritmo de diferença diferente, o que pode ajudar a evitar mismerges que ocorrem devido a linhas de correspondência sem importância (como aparelhos de diferentes funções). Veja também git-diff [1] --diff-algorithm.
ignore-space-change ignore-all-space ignore-space-at-eol ignore-cr-at-eol.
Trata as linhas com o tipo de mudança de espaço indicado como inalterada por causa de uma fusão de três vias. As mudanças de espaço em branco misturadas com outras alterações em uma linha não são ignoradas. Veja também git-diff [1] - b, - w, --ignore-space-at-eol e --ignore-cr-at-eol.
Se a "sua" versão apenas introduzir mudanças de espaço em branco para uma linha, a "nossa" versão é usada;
Se a nossa versão introduzir mudanças no espaço em branco, a versão '' deles '' inclui uma alteração substancial, a 'sua' versão é usada;
Caso contrário, a fusão prossegue da maneira usual.
Isso executa um check-out virtual e check-in de todos os três estágios de um arquivo ao resolver uma mesclagem de três vias. Esta opção destina-se a ser usada quando mesclar ramos com diferentes filtros limpos ou regras de normalização de fim de linha. Consulte "Mesclando ramos com diferentes atributos check-in / checkout" em gitattributes [5] para detalhes.
Desativa a opção renormalize. Isso substitui a variável de configuração fusionar.
Desative a detecção de renomeação. Veja também git-diff [1] --no-renomeação.
Ativar a detecção de renomeação, opcionalmente, definir o limite de similaridade. Este é o padrão. Veja também git-diff [1] --find-renames.
Sinônimo desaprovado para find-renames = & lt; n & gt; .
Esta opção é uma forma mais avançada de estratégia "subárvore", onde a estratégia adivinha a forma como duas árvores devem ser deslocadas para combinar uma com a outra quando se fundem. Em vez disso, o caminho especificado é prefixado (ou despojado desde o início) para tornar a forma de duas árvores coincidir.
Isso resolve casos com mais de duas cabeças, mas se recusa a fazer uma fusão complexa que precisa de resolução manual. É principalmente destinado a ser usado para agrupar as cabeças de tópicos. Essa é a estratégia de mesclagem padrão ao puxar ou juntar mais de uma ramificação.
Isso resolve qualquer número de cabeças, mas a árvore resultante da mesclagem é sempre a da cabeça atual do ramo, ignorando efetivamente todas as mudanças de todos os outros ramos. É destinado a substituir o antigo histórico de desenvolvimento de filiais laterais. Observe que isso é diferente da opção - Xours para a estratégia de intercalação "recursiva".
Esta é uma estratégia recursiva modificada. Ao mesclar as árvores A e B, se B corresponde a uma subárvore de A, B é primeiro ajustado para coincidir com a estrutura em árvore de A, em vez de ler as árvores no mesmo nível. Este ajuste também é feito para a árvore-antepassada comum.
Com as estratégias que utilizam a fusão de 3 vias (incluindo o padrão, 'recursivo'), se uma alteração for feita em ambos os ramos, mas mais tarde será revertida em um dos ramos, essa mudança estará presente no resultado mesclado; Algumas pessoas acham esse comportamento confuso. Ocorre porque apenas as cabeças e a base de mesclagem são consideradas ao realizar uma mesclagem, e não o indivíduo comete. O algoritmo de mesclagem considera, portanto, a alteração revertida como nenhuma alteração, e substitui a versão alterada.
Creative Bloq.
Design da Web Escolha a estratégia de ramificação Git direita.
Usar o Git para controle de origem agora é um padrão da indústria, mas como você sabe qual fluxo de trabalho é o melhor? Lorna Mitchell explora as opções.
Git é uma ferramenta fantástica. As ferramentas de controle de origem fornecem vários recursos vitais: um lugar para manter o código, um histórico de mudanças e informações sobre quem fez o que e quando. Se você e sua equipe estiverem bem com mensagens de confirmação, você pode até obter informações extras sobre por que uma alteração foi feita. As ferramentas distribuídas, como a Git e a Mercurial, também oferecem muitas possibilidades de colaboração entre vários depósitos, além de proporcionar maneiras eficazes de trabalhar com agências.
Então, o que exatamente é um ramo no Git? Dê uma olhada na Figura 1. Um ramo no Git é simplesmente um ponteiro para um commit. Se você olhar para como um ramo é representado no diretório '.git', você encontrará um arquivo de texto com o mesmo nome que o ramo, simplesmente contendo o identificador de confirmação da "dica" atual ou a confirmação mais recente sobre esse ramo . O ramo em si é criado pelo rastreamento da ascendência desse único commit, uma vez que cada commit sabe o que cometeu depois.
Como treinador, uma coisa sobre a qual eu sempre pergunto é qual é a estratégia de ramificação "direita" de Git. Meu conselho varia bastante dependendo da equipe e da situação, mas existem alguns padrões comuns que aparecem repetidas vezes. Esta publicação descreve esses padrões e explica as situações em que eles podem ser mais úteis.
Comece simples com o fluxo GitHub.
Realizado por uma postagem no blog de Scott Chacon, o GitHub Flow é minha estratégia de ramificação favorita. Por quê? Principalmente porque é simples enquanto ainda cobre todas as bases essenciais. O GitHub Flow simplesmente afirma que, ao trabalhar em qualquer recurso ou correção de bugs, você deve criar um ramo.
Quando terminar, ele é mesclado de volta para o mestre com um commit de mesclagem. É uma maneira muito fácil para equipes e indivíduos criar e colaborar em recursos separados de forma segura e poder entregá-los quando estiverem concluídos. Ele cria um gráfico que parece algo como o da Figura 2.
Esses ramos "tópicos" podem ser bastante duradouros, mas esteja ciente de que quanto mais um ramo diverge do mestre, mais provável é que os conflitos sejam experimentados quando o recurso aterrar. A regra é que o ramo principal é sempre implantável, então os recursos devem ser finalizados e testados completamente antes de serem incorporados. Depois que um novo recurso foi mesclado ao mestre, é normal implantar imediatamente a nova base de código. Para isso, você pode estabelecer uma verdadeira abordagem de implantação contínua, ou simplesmente configurar um processo de implantação automatizado fácil para que o código possa ser implantado com freqüência.
Há um ótimo artigo no blog da Laura Thomson que descreve isso como "implantação potencialmente contínua". Não é considerado incomum implementar código em plataformas ao vivo várias vezes por dia.
Uma vez que este modelo defende a ramificação para até um "hotfix" e ndash; uma troca rápida e simples de confirmação & ndash; ele cria um padrão de gráfico próprio. A Figura 3 representa um exemplo em que há apenas um desvio de compromisso único na direção do desenvolvimento.
Por que alguém criaria um único commit em um ramo e depois o faria com um commit de mesclagem, em vez de apenas aplicar a mudança diretamente ao mestre? Existem algumas razões filosóficas sobre a separação, mas para mim existem duas vantagens principais.
Em primeiro lugar, criar um ramo dá a oportunidade de abrir uma solicitação de puxar e obter algum comentário / feedback / QA na mudança antes de se mesclar. Em segundo lugar, se quiser soltar a mudança ou aplicar a mesma alteração em outro lugar, ambas as coisas são mais fáceis com um ramo do que com uma confirmação direta.
Ramificações do meio ambiente.
Isto é o que eu gosto de chamar o modelo 'Branch per Platform'. Além de um ramo mestre, existem filiais que rastreiam a plataforma ao vivo, além de outras plataformas que você usa em seu fluxo de trabalho (como testes, estadiamento e integração). Para fazer isso, o mestre permanece no limite sangrento do seu projeto, mas, à medida que os recursos são completos, você mescla as outras plataformas em conformidade (veja a Figura 4).
A vantagem disso é que você sempre possui um ramo que rastreie uma plataforma específica, o que torna muito fácil solucionar um problema se, por exemplo, é detectado ao vivo. Ao usar o ramo ao vivo como base de sua correção, você pode facilmente implantar a base de código existente, além de uma única alteração. Uma vez que a plataforma ao vivo é resolvida, você pode aplicar a correção ao mestre e a qualquer outro ramo de ambiente. Isso significa que você evita uma situação em que você está querendo adivinhar o que está na plataforma ao vivo, ou fazer uma estranha correção direta ao vivo!
Marcação com etiquetas.
Uma alternativa muito similar é usar tags para marcar seus lançamentos quando você os faz. Desta forma, você pode olhar para o histórico das versões que estiveram ao vivo. De fato, o GitHub ainda possui uma página dedicada para isso. Esta técnica é usada especialmente para marcar as liberações da biblioteca.
Outras ferramentas, como Composer para PHP, usarão as tags para pegar e disponibilizar a versão recém-lançada, por isso é importante que as tags sejam usadas corretamente. As tags também podem ser úteis em seus próprios projetos, talvez configurando suas ferramentas de compilação ou implantação para responder apenas a tags especificamente especificadas ao invés de cada commit em uma filial ou mesmo um repositório inteiro.
Combinar cometer ou não?
Usar o Git nos dá a capacidade de mesclar mudanças em qualquer ordem, independentemente de como esses recursos foram realmente criados e combinados. Ele também nos permite reescrever a história, levando a debates infinitos sobre os benefícios de um gráfico limpo e bastante comprometido, em comparação com um que reflete o que realmente aconteceu.
Um pouco como o argumento entre abas e espaços, esse argumento pode e será executado por algum tempo. Dito isto, ambos os lados da discussão têm mérito e é uma consideração importante quando você padroniza a forma como sua equipe irá funcionar.
Para que qualquer um faça sentido, primeiro precisamos conversar sobre compromissos de fusão no Git. Todos os compromissos do Git têm identificadores de compromisso e ndash; aquelas cordas hexagonais longas e ndash; e eles são únicos. Eles são feitos a partir de informações sobre o conjunto de alterações, a mensagem de confirmação, o autor, o carimbo de data / hora e o compromisso principal que eles foram aplicados.
Isso significa que se o mesmo commit for aplicado a um pai diferente, mesmo que o código resultante seja idêntico, o novo commit terá um identificador de confirmação diferente. Os compromissos de fusão não têm um, mas dois pais.
No log, eles se parecem com isto:
Observe a linha extra na mensagem de confirmação que começa a mesclar:. Os dois números são as referências de compromisso dos dois pais para este commit & ndash; um de cada um dos ramos sendo fundido em conjunto.
Fast-forward se funde.
As fusões nem sempre se parecem com isso, no entanto. Se houver mudanças em um ramo, mas não, por exemplo, no ramo mestre, uma "fusão rápida" ocorrerá. Começamos com esta situação: mudanças em um ramo de recursos, mas não no mestre (como mostrado na Figura 5). Se apenas pedimos a Git que funcione nesse ramo, ele irá "avançar rapidamente".
Quando a fusão acontece, não há nenhuma fusão realmente necessária. Os compromissos no ramo de recursos continuam a partir do mais novo commit no ramo principal, fazendo um histórico linear. Git, portanto, avança rapidamente, movendo o rótulo mestre para a ponta do ramo de recursos para que possamos continuar a partir daí (Figura 6). Se você está apontando para um padrão de mesclagem mais tradicional, você pode forçar isso usando a opção --no-ff. Isso cria um histórico que se parece com a Figura 7.
O parâmetro --no-ff diz a Git que não avança rapidamente, mas sim para criar o commit de mesclagem. Muitas estratégias de ramificação exigem que esta técnica seja usada quando as filiais se fundem. A maior parte do tempo, precisamos de uma confissão de mesclagem de qualquer maneira, pois haverá mudanças no ramo de recursos e no ramo em que estamos juntando. In some situations – for me that's usually when creating a hotfix branch – it can be useful to force the merge commit to make the history clear on exactly which branch has been merged to where.
Branching strategies.
Perhaps the most well-known branching strategy is Git Flow, which is a very comprehensive strategy. So comprehensive, in fact, it needs a whole set of scripts in order to use it properly! In my experience, Git Flow is too much for all but very large and technically advanced teams that are solving problems across multiple releases at one time.
However, every branching strategy I've ever implemented has drawn ideas from this approach, and I've tried to break these down in this article.
A branching strategy itself is a process; a document. It's the place where, as a team, you capture your approach and attitude to the way that you produce, track and ship code. Everyone understands how each of the moving parts in the process works (at least on the code level – social and political issues are a topic for another article), and how to collaborate to achieve the goal that you're all aiming for. A branching strategy can be a simple as a page on the company wiki – something that gives structure to the way that you work. It may also be a great place to put the Git cheatsheet for how to do the various steps.
I find that having a branching strategy in place greatly improves both the quality of the work and the confidence and communication of the team. Take a little time to agree and record your strategy, and then go forth and be even more awesome than you were before.
Lorna Mitchell is an author, trainer and developer specialising in PHP, APIs and Git. You can get more help from her by reading her Git Workbook, which contains practical exercises to level up your skills. This article was originally published in issue 267 of net magazine.
Artigos relacionados.
Recomendado.
5 must-read books for design students.
How to design for startups.
Get Weekly Tips and Inspiration.
Sign up below to get the latest from Creative Bloq, plus exclusive special offers, direct to your inbox!
Sem spam, nós prometemos. Você pode se desinscrever a qualquer momento e nunca compartilharemos seus detalhes sem sua permissão.
The best computer for graphic design 2018.
18 top CSS animation examples.
10 essential tablet accessories.
63 best free fonts for designers.
32 brilliant design portfolios to inspire you.
How to draw movement: 16 top tips.
Russia's new tourist identity inspired by avant-garde art.
The best computer for graphic design 2018.
How to use images more effectively in web design.
The best keyboards for designers.
Creative Bloq is part of Future plc, an international media group and leading digital publisher. Visite nosso site corporativo.
&cópia de; Future Publishing Limited Quay House, The Ambury, Bath BA1 1UA. Todos os direitos reservados. Número de registro da empresa na Inglaterra e País de Gales 2008885.
Obter através da App Store Leia esta publicação em nosso aplicativo!
Controle de versão e estratégia Git? [fechadas]
Eu uso o git para manter algum tipo de controle de versão e sincronizar meu trabalho em várias máquinas, pois eu costumo trabalhar em várias máquinas. Eu sou a única pessoa a trabalhar no meu código.
Eu posso fazer a maioria dos princípios básicos com git, e. git checkout um arquivo para retornar um arquivo individual para um estado anterior, e usar git reverter (eu dread usando git reverter, já que ainda não entendi algumas das suas complexidades completas) para retornar todo o projeto para um estado anterior. Eu tambem às vezes uso git branch para adivinhar o código em uma direção diferente, especialmente se eu não tiver certeza da direção.
O meu conhecimento do git no entanto é um pouco tênue e ainda tendem a manter o arquivo de origem progressivamente enquanto eu trabalho mais adiante. por exemplo. Talvez eu esteja trabalhando no projeto18.c no momento em que terminei, tendo passado por 1. 18 enquanto trabalho pelo código. Isto é, além de fazer git com frequência, enquanto trabalha no arquivo, de modo efetivo, eu tenho duas maneiras de "marcar de volta" meu trabalho no projeto. Esta numeração de arquivos incremental no entanto, não funciona bem com o código espalhado em vários arquivos, pois manter um registro de um recurso implementado em vários arquivos fica muito louco. Eu suspeito que, trabalhando com mais força na criação de funções autônomas que encapsulam e ocultando a implementação interna das funções circundantes, é uma solução mais elegante para alguns dos meus problemas.
Muitas vezes, as pessoas sugerem que executem um compromisso de git para cada novo recurso ou peça de código importante, no entanto, quando falho em realizar compromissos de git freqüentes, muitas vezes gasto uma quantidade excessiva de tempo manualmente "fazendo o backup de" um código de buggy, se eu Estou abandonando essa maneira particular de implementar o código. Eu suspeito que um melhor planejamento // design do código com antecedência às vezes pode ajudar, mas muitas vezes é difícil antecipar completamente o que acabará por ser um ponto morto ou um código de buggy.
Procuro uma estratégia prática para o controle de versões, que auxilia especialmente quando as coisas não estão indo bem, e que ajuda a depurar as partes do problema.
fechado como não construtivo por Holger Just, Aleks G, Florent, mosquito, Toto 16 de outubro '12 às 8:10.
Como está atualmente, esta questão não é uma boa opção para o nosso formato Q & amp; A. Esperamos que as respostas sejam apoiadas por fatos, referências ou conhecimentos, mas esta questão provavelmente solicitará debate, argumentos, votação ou discussão prolongada. Se você acha que esta questão pode ser melhorada e possivelmente reaberta, visite o centro de ajuda para orientação. Se esta questão pode ser reformulada para ajustar as regras no centro de ajuda, edite a questão.
Se você é sério sobre seus hábitos de trabalho (como se você quisesse escrever código para viver ou contribuir com algum projeto de software livre), é melhor se acostumar a cometer frequentemente. Os compromissos ainda devem ter alguma lógica neles, é um faux pas para ter um commit separado para cada dez linhas de código que você escreve. Small & amp; Os compromissos lógicos são bons de rever ou bisecar, se você encontrar uma regressão.
Se você precisa ter muitos pontos de controle, você pode ter um compromisso para o conjunto de teste para o recurso em que está trabalhando e um compromisso para cada parte que passa do conjunto de teste. Ou algo assim, dependendo do seu estilo de trabalho. (Com o Git, você sempre pode limpar o histórico ao publicar as alterações, se necessário). Se você achar que não é suficiente, você está fazendo algo errado.
A solução para o seu problema vem em duas partes diferentes:
O que é o controle de versão.
Os sistemas de controle de versão são uma categoria de ferramentas de software que ajudam uma equipe de software a gerenciar as alterações ao código-fonte ao longo do tempo. O software de controle de versão acompanha todas as modificações no código em um tipo especial de banco de dados. Se um erro for feito, os desenvolvedores podem voltar o relógio e comparar versões anteriores do código para ajudar a corrigir o erro, minimizando a interrupção de todos os membros da equipe.
Para quase todos os projetos de software, o código fonte é como as jóias da coroa - um recurso precioso cujo valor deve ser protegido. Para a maioria das equipes de software, o código-fonte é um repositório do inestimável conhecimento e compreensão sobre o domínio do problema que os desenvolvedores coletaram e refinaram através de um esforço cuidadoso. O controle de versão protege o código fonte da catástrofe e a degradação casual do erro humano e conseqüências não desejadas.
Os desenvolvedores de software que trabalham em equipes estão escrevendo continuamente novos códigos-fonte e alterando o código-fonte existente. O código para um projeto, aplicativo ou componente de software normalmente é organizado em uma estrutura de pastas ou "árvore de arquivos". Um desenvolvedor da equipe pode estar trabalhando em um novo recurso, enquanto outro desenvolve um erro não relacionado alterando o código, cada desenvolvedor pode fazer suas alterações em várias partes da árvore de arquivos.
O controle de versão ajuda as equipes a resolver esses tipos de problemas, rastreando todas as mudanças individuais por cada colaborador e ajudando a evitar que o trabalho concorrente seja conflitante. As mudanças feitas em uma parte do software podem ser incompatíveis com as feitas por outro desenvolvedor trabalhando ao mesmo tempo. Este problema deve ser descoberto e resolvido de forma ordenada sem bloquear o trabalho do resto do time. Além disso, em todo o desenvolvimento de software, qualquer alteração pode introduzir novos erros por conta própria e o novo software não pode ser confiável até que seja testado. Então o teste eo desenvolvimento continuam juntos até que uma nova versão esteja pronta.
Um bom software de controle de versão suporta o fluxo de trabalho preferido de um desenvolvedor sem impor uma maneira particular de trabalhar. Idealmente, ele também funciona em qualquer plataforma, em vez de ditar o que o sistema operacional ou os desenvolvedores da cadeia de ferramentas devem usar. Os grandes sistemas de controle de versões facilitam o fluxo contínuo e contínuo de mudanças no código e não o mecanismo frustrante e desajeitado de bloqueio de arquivos - dando a luz verde a um desenvolvedor à custa de bloquear o progresso de outros.
As equipes de software que não usam qualquer tipo de controle de versão freqüentemente se deparam com problemas, como não saber quais as mudanças que foram feitas, estão disponíveis para os usuários ou a criação de mudanças incompatíveis entre dois trabalhos não relacionados, que devem ser minuciosamente desenrolados e retrabalhados. Se você é um desenvolvedor que nunca usou o controle de versão, você pode ter adicionado versões aos seus arquivos, talvez com sufixos como "final" ou "mais recente" e depois teve que lidar com uma nova versão final. Talvez você tenha comentado blocos de código porque deseja desativar determinadas funcionalidades sem excluir o código, temendo que possa haver um uso para isso mais tarde. O controle de versão é uma saída desses problemas.
O software de controle de versão é uma parte essencial do dia a dia das práticas profissionais da equipe de software moderno. Os desenvolvedores de software individuais que estão acostumados a trabalhar com um sistema de controle de versão capaz em suas equipes geralmente reconhecem o incrível controle de versão de valor também os dá mesmo em pequenos projetos individuais. Uma vez acostumados aos poderosos benefícios dos sistemas de controle de versão, muitos desenvolvedores não considerariam trabalhar sem ele mesmo para projetos que não sejam de software.
Benefícios dos sistemas de controle de versão.
Desenvolver o software sem usar controle de versão é arriscado, como não ter backups. O controle de versão também pode permitir que os desenvolvedores se movam mais rápido e permite que as equipes de software preservem a eficiência e a agilidade à medida que a equipe escala para incluir mais desenvolvedores.
Sistemas de controle de versão (VCS) viram grandes melhorias nas últimas décadas e algumas são melhores do que outras. O VCS às vezes é conhecido como ferramentas SCM (Gerenciamento de código-fonte) ou RCS (Revision Control System). Uma das ferramentas VCS mais populares em uso hoje é chamada Git. Git é um Distributed VCS, uma categoria conhecida como DVCS, mais sobre isso mais tarde. Como muitos dos sistemas VCS mais populares disponíveis hoje, o Git é gratuito e de código aberto. Independentemente do que eles chamam, ou qual sistema é usado, os principais benefícios que você deve esperar do controle de versão são os seguintes.
Um histórico completo de mudanças de longo prazo de cada arquivo. Isso significa todas as mudanças feitas por muitos indivíduos ao longo dos anos. As mudanças incluem a criação e exclusão de arquivos, bem como as edições em seus conteúdos. Diferentes ferramentas de VCS diferem em quanto bem eles manipulam o renomeamento e o movimento de arquivos. Esta história também deve incluir o autor, a data e as notas escritas sobre a finalidade de cada alteração. Ter o histórico completo permite voltar às versões anteriores para ajudar na análise de causa raiz para erros e é crucial quando é necessário corrigir problemas em versões anteriores de software. Se o software estiver trabalhando ativamente, quase tudo pode ser considerado uma "versão antiga" do software.
Ramificação e fusão. Fazer com que os membros da equipe trabalhem simultaneamente é um insensivel, mas mesmo os indivíduos que trabalham por conta própria podem se beneficiar da capacidade de trabalhar em fluxos independentes de mudanças. Criando um & quot; branch & quot; nas ferramentas do VCS, as múltiplas correntes de trabalho são independentes umas das outras, ao mesmo tempo que fornecem facilidades para fundir o trabalho de volta, permitindo que os desenvolvedores verifiquem que as mudanças em cada ramo não conflitam. Muitas equipes de software adotam uma prática de ramificação para cada recurso ou talvez ramificação para cada lançamento, ou ambos. Existem muitos fluxos de trabalho diferentes que as equipes podem escolher quando decidem como fazer uso de instalações de ramificação e fusão no VCS.
Rastreabilidade. Ser capaz de rastrear cada mudança feita ao software e conectá-lo ao gerenciamento de projetos e ao software de rastreamento de erros, como Jira, e poder anotar cada alteração com uma mensagem descrevendo o propósito e a intenção da mudança podem ajudar não só com a análise de causa raiz e outros forenses. Ter o histórico anotado do código ao alcance de sua mão quando você está lendo o código, tentando entender o que está fazendo e por que ele é tão projetado pode permitir que os desenvolvedores façam mudanças corretas e harmoniosas que estejam de acordo com o design previsto a longo prazo do sistema. Isso pode ser especialmente importante para trabalhar efetivamente com o código legado e é crucial para permitir que os desenvolvedores estimem o trabalho futuro com qualquer precisão.
Embora seja possível desenvolver software sem usar qualquer controle de versão, o assunto é sujeito o projeto a um enorme risco de que nenhuma equipe profissional seja aconselhada a aceitar. Portanto, a questão não é se usar o controle de versão, mas qual o sistema de controle de versão a ser usado.
Há muitas escolhas, mas aqui vamos nos concentrar em apenas um, o Git.
Комментариев нет:
Отправить комментарий