Para colaborar em um projeto usando um sistema de controle de versão, a primeira coisa que você precisa fazer é criar uma cópia local obtendo informações do repositório. O usuário pode então modificar a cópia. Existem dois esquemas básicos de funcionamento para que os usuários possam contribuir com suas modificações:

• - exclusivamente: neste esquema, para realizar uma alteração, é necessário comunicar ao repositório o elemento que se deseja modificar e o sistema será responsável por impedir que outro usuário modifique o referido elemento. Uma vez feita a modificação, ela é compartilhada com os demais colaboradores. Se você tiver terminado de modificar um elemento, esse elemento será liberado para que outros possam modificá-lo.

• - Colaborativamente: neste esquema cada usuário modifica a cópia local e quando o usuário decide compartilhar as alterações o sistema tenta automaticamente combinar as diversas modificações. O principal problema é o possível aparecimento de conflitos que devem ser resolvidos manualmente ou as possíveis inconsistências que surgem ao modificar o mesmo arquivo por várias pessoas descoordenadas. Além disso, esta semântica não é apropriada para arquivos binários.

O controle de versão do Team Foundation Server permite que você escolha uma das duas formas de colaboração.

Podemos clasificar los sistemas de control de versiones atendiendo a la arquitectura utilizada para el almacenamiento del código:.

• - Distribuidos: cada usuario tiene su propio repositorio. Los distintos repositorios pueden intercambiar y mezclar revisiones entre ellos. Es frecuente el uso de un repositorio, que está normalmente disponible, que sirve de punto de sincronización de los distintos repositorios locales. Ejemplos: Git y Mercurial.

• - Centralizados: existe un repositorio centralizado de todo el código, del cual es responsable un único usuario (o conjunto de ellos). Se facilitan las tareas administrativas a cambio de reducir flexibilidad, pues todas las decisiones fuertes (como crear una nueva rama) necesitan la aprobación del responsable. Algunos ejemplos son CVS, Subversion o Team Foundation Server.

Vantagens dos sistemas distribuídos

• - Você precisa estar conectado à rede menos vezes para realizar operações. Isso produz maior autonomia e maior velocidade.

• - Mesmo que o repositório remoto fique inativo, as pessoas poderão continuar trabalhando.

• - Ao fazer dos diferentes repositórios uma réplica local da informação dos repositórios remotos aos quais se conectam, a informação é altamente replicada e, portanto, o sistema tem menos problemas de recuperação se, por exemplo, a máquina que possui o repositório remoto queimar. Portanto, há menos necessidade de backups. Porém, backups ainda são necessários para resolver situações em que determinadas informações ainda não foram replicadas.

• - Permite manter repositórios centrais mais limpos no sentido de que um usuário pode decidir que certas alterações feitas por ele no repositório local não são relevantes para o resto dos usuários e, portanto, não permite que essa informação seja acessível publicamente, seja porque contém versões instáveis, em processo de codificação ou com rótulos personalizados e para uso exclusivo do usuário.

• - O servidor remoto requer menos recursos do que um servidor centralizado necessitaria, já que grande parte do trabalho é feito por repositórios locais.

• - Sendo os sistemas distribuídos mais recentes que os sistemas centralizados, e tendo mais flexibilidade por terem um repositório local e um ou mais repositórios remotos, estes sistemas foram concebidos para facilitar a utilização de ramificações (criação, evolução e fusão) e poder tirar o máximo partido do seu potencial. Por exemplo, ramificações podem ser criadas no repositório remoto para corrigir bugs ou criar novos recursos. Mas ramificações também podem ser criadas em repositórios locais para que os usuários possam testar e dependendo dos resultados, mesclá-las com o desenvolvimento principal ou não. As filiais proporcionam grande flexibilidade na forma como você trabalha.

Vantagens dos sistemas centralizados

• - Em sistemas distribuídos há menos controle quando se trabalha em equipe, pois não existe uma versão centralizada de tudo o que está sendo feito no projeto.

• - Em sistemas centralizados, as versões são identificadas por um número de versão. Porém, em sistemas distribuídos de controle de versão não há números de versão, pois cada repositório teria seus próprios números de revisão dependendo das alterações. Em vez disso, cada versão possui um identificador ao qual uma tag pode ser associada (tag).

El flujo de trabajo de un sistema de control de versiones indica cómo se relacionan los distintos usuarios para colaborar entre sí en la consecución de los objetivos del proyecto.

En los sistemas de control de versiones centralizados el diseño del sistema restringe la forma en que los distintos usuarios colaboran entre sí. Sin embargo en los sistemas de control de versiones distribuidos hay mucha más flexibilidad en la forma de colaborar ya que cada desarrollador puede tanto contribuir como recibir contribuciones. Hay distintos flujos de trabajo, donde cada uno se adapta mejor a cierto tipo de proyectos. Veamos algunos ejemplo habituales que también se pueden combinar para así adaptarse mejor al proyecto concreto (por ejemplo podría usarse en general un flujo centralizado, y usar un gestor de integraciones para ciertas partes críticas y de especial importancia).[3]​.

Fluxo de trabalho centralizado

No Fluxo de Trabalho Centralizado, cada desenvolvedor é um nó de trabalho. Por outro lado, existe um repositório remoto central que funciona como ponto de sincronização. Todos os nós de trabalho operam igualmente no repositório remoto central.

Se for um sistema de controle de versão distribuído, cada nó de trabalho consiste em um repositório local privado.

Uma desvantagem desta forma de trabalhar é que se dois usuários clonarem a partir de um ponto central, e ambos fizerem alterações; Somente a primeira pessoa a enviar suas alterações poderá fazê-lo de forma limpa. O segundo desenvolvedor deve primeiro mesclar seu trabalho com o do primeiro, antes de submetê-lo, para evitar sobrescrever as alterações do primeiro. Ou seja, é necessário realizar uma etapa anterior, pois não é possível fazer upload de alterações que não sejam de avanço rápido (mudanças que não sejam de avanço rápido).

Fluxo de trabalho com um gerenciador de integração

No fluxo de trabalho com um Integration-Manager Workflow (em inglês Integration-Manager Workflow) em que cada desenvolvedor tem acesso de gravação ao seu próprio repositório público e acesso de leitura aos repositórios públicos de todos os outros usuários. Por outro lado, existe um repositório canônico, o representante ‘oficial’ do projeto.

Para contribuir com esses projetos, cada desenvolvedor cria seu próprio clone público do repositório canônico e submete a ele suas alterações (feitas em um repositório privado). Para 'carregar' suas alterações no repositório canônico, cada desenvolvedor deve fazer uma solicitação à pessoa que o gerencia.

A principal vantagem desta forma de trabalhar é que você pode continuar trabalhando, e a pessoa que gerencia o repositório canônico poderá recuperar suas alterações a qualquer momento. Os colaboradores não precisam esperar que suas alterações sejam incorporadas ao projeto, cada um pode trabalhar no seu próprio ritmo.

Fluxo de trabalho com ditador e tenentes

O Fluxo de Trabalho de Ditadores e Tenentes é uma extensão do Fluxo de Trabalho do Gerenciador de Integração. É utilizado em projetos muito grandes, com centenas de colaboradores, como o kernel Linux.

Há uma série de gerenciadores de integração responsáveis ​​por partes específicas do repositório, que são chamados de tenentes. Todos os tenentes se reportam a um gerente de integração; conhecido como ditador. O ditador integra todas as contribuições dos tenentes publicando a obra em um repositório de referência do qual todos os colaboradores a recuperam.

Este sistema de trabalho permite ao líder do grupo (o ditador) delegar grande parte do trabalho aos tenentes, relegando o seu trabalho à recolha dos frutos de múltiplos pontos de trabalho.

Las ramas, en un sistema de control de versiones, constituyen una potente herramienta que flexibiliza la forma en la que los colaboradores cooperan en el proyecto (en inglés Branching Workflows). Las ramas son solo una herramienta que es posible utilizar de distintas formas para conseguir distintos objetivos. Veamos algunas posibilidades.[3]​[4]​.

filiais de longo curso

Em alguns projetos existem diversas ramificações sempre abertas, o que indica graus variados de estabilidade de conteúdo. Por exemplo, no branch 'master' é comum manter apenas o que é completamente estável. Depois, há outros ramos que revelam diferentes graus de estabilidade. Por exemplo, poderíamos ter um branch 'beta' (versão beta) e outro branch 'alpha' (versão alfa), no qual estamos trabalhando. Quando se atinge um certo grau de estabilidade maior que o ramo em que está presente, realiza-se uma fusão com um ramo de maior estabilidade.

Ramos específicos

Ramos específicos, também chamados de ramos de suporte, são ramos criados ocasionalmente para executar uma funcionalidade muito específica. Por exemplo, adicionar um novo recurso (eles são chamados de novas ramificações de funcionalidade ou diretamente pelo nome em inglês topic branch ou feature branch) ou corrigir um bug específico (eles são chamados de bug fix branch ou diretamente pelo nome em inglês hotfix branch).

Estes tipos de ramos permitem-nos trabalhar focando exclusivamente no desenvolvimento de uma funcionalidade específica e quando concluído é fundido com um dos ramos de longo prazo (normalmente com aquele com menor nível de estabilidade, para que possa ser testado naquele ambiente). A mesclagem só é feita quando você tem 'certeza' de que o recurso está implementado corretamente, em vez de mesclar na ordem em que as coisas são desenvolvidas. Isto permite, por um lado, ter um histórico das diferentes versões que existiram até que a funcionalidade fosse alcançada. Por outro lado, permitem que o histórico das filiais de longo prazo não fique 'sujo' com diversas modificações relacionadas a uma funcionalidade específica.

A utilização deste tipo de ramificações permite maior flexibilidade no teste de possíveis soluções. Ele só se funde com ramificações de longa duração quando temos certeza de que escolhemos a melhor solução.

Um tipo de branch deste tipo que possui uma função especial são os chamados version branch ou release branch* (em inglês release branch). Estes tipos de ramificações são criados para apoiar a preparação de uma nova versão de produção. Eles permitem que você tenha o conteúdo da versão sob controle e possa realizar algumas manutenções nela (adicionar pequenas melhorias e corrigir erros).

É comum e uma boa prática usar um prefixo no nome da filial que indique o tipo de filial. Por exemplo, você pode usar 'feature-' para novas ramificações de recursos, 'hotfix-' para ramificações de correção de bugs e 'release-' para ramificações de lançamento.

• - Programas de controle de versão.

• - Gerenciamento de configuração de software.

• - Software.

• -CVS.

• - Git.

• - GitHub.

Contenido

La terminología empleada puede variar de sistema a sistema, pero a continuación se describen algunos términos de uso común.[1]​[2]​.

Repositório

O repositório é onde os dados atualizados e históricos de alterações são armazenados, geralmente em um servidor. Às vezes é chamado de depósito ou depósito. Pode ser um sistema de arquivos em um disco rígido, um banco de dados, etc.

Módulo

Conjunto de diretórios e/ou arquivos dentro do repositório que pertencem a um projeto comum.

Revisão ("versão")

Uma revisão é uma versão específica da informação que está sendo gerenciada. Existem sistemas que identificam revisões com um contador (por exemplo, subversion). Existem outros sistemas que identificam revisões usando um código de detecção de modificação (por exemplo, Git usa SHA1). A versão mais recente geralmente é identificada de forma especial com o nome HEAD. rótulos ou tags são usados ​​para marcar uma revisão específica.

Rótulo ou Rótulo ("tag")

Dê a alguma versão de cada um dos arquivos no módulo em desenvolvimento em um momento específico um nome comum ("tag" ou "rótulo") para garantir que esse estado de desenvolvimento possa ser encontrado posteriormente com esse nome. Na prática, todos os arquivos são rotulados em um determinado momento. Para isso, o módulo “congela” durante a rotulagem para impor uma versão coerente. Mas sob certas circunstâncias pode ser necessário utilizar versões de alguns arquivos que não coincidem temporariamente com as dos outros arquivos do módulo.

Linha de base

Uma revisão aprovada de um documento ou arquivo de origem, a partir da qual alterações subsequentes podem ser feitas.

Filial aberta ("filial") ou filial

Um módulo pode ser ramificado ou bifurcado em um instante de tempo para que, a partir desse momento, existam duas cópias (ramificações) que evoluem de forma independente seguindo sua própria linha de desenvolvimento. O módulo então possui 2 (ou mais) "ramos". A vantagem é que pode ser feita uma “mesclagem” das modificações de ambas as ramificações, possibilitando a criação de “ramos de teste” que contenham código para avaliação. Caso seja decidido que as modificações feitas no “ramo de teste” sejam preservadas, é feito um “merge” com o ramo principal. Motivos comuns para a criação de ramificações são a criação de novos recursos ou correções de bugs.

Implantar ("Check-out", "checkout", "co")

Uma implantação cria uma cópia de trabalho local do repositório. Você pode especificar uma revisão específica, e a mais recente geralmente é retornada por padrão.

Consolidar, publicar ou enviar ("commit", "check-in", "ci", "install", "submit")

Um commit acontece quando uma cópia das alterações feitas em uma cópia local é escrita ou integrada ao repositório.

Conflito

Um conflito ocorre quando o sistema não consegue lidar adequadamente com as alterações feitas por dois ou mais usuários no mesmo arquivo. Por exemplo, se esta sequência de circunstâncias ocorrer:

1. • Os usuários X e Y implantam versões do arquivo A nas quais as linhas n1 a n2 são comuns.

2. • O usuário X envia alterações entre as linhas n1 e n2 para o arquivo A.

3. • O usuário Y não atualiza o arquivo A após o usuário X enviá-lo.

4. • O usuário Y faz alterações entre as linhas n1 e n2.

5. • O usuário Y subsequentemente tenta enviar essas alterações para o arquivo A.

O sistema não consegue mesclar as alterações. O usuário Y deve resolver o conflito mesclando as alterações ou escolhendo uma delas para descartar a outra.

Resolver

O ato de intervenção do usuário para resolver um conflito entre diferentes alterações no mesmo arquivo.

Alterar ("alterar", "diff", "delta")

Uma alteração representa uma modificação específica em um arquivo sob controle de versão. A granularidade da modificação considerada uma mudança varia entre diferentes sistemas de controle de versão.

Lista de alterações ("changelist", "conjunto de alterações", "patch")

Em muitos sistemas de controle de versão com commits atômicos de múltiplas alterações, uma lista de alterações identifica o conjunto de alterações feitas em um único commit. Isso também pode representar uma visão sequencial do código-fonte, permitindo que a fonte seja examinada a partir de qualquer identificador de lista de alterações específico.

Exportar

Uma exportação é semelhante a um check-out, exceto que cria uma árvore de diretórios limpa sem metadados de controle de versão presentes na cópia de trabalho. Muitas vezes é usado antes da publicação de conteúdo.

Importar

Uma importação é a ação de copiar uma árvore de diretórios local (que atualmente não é uma cópia de trabalho) para o repositório pela primeira vez.

Integração ou fusão (“mesclagem”)

Uma integração ou mesclagem une dois conjuntos de alterações em um arquivo ou conjunto de arquivos em uma revisão unificada do referido arquivo ou arquivos.

Integração reversa

O processo de fusão de filiais de diferentes equipes no tronco principal do sistema de lançamento.

Atualizar ("sincronizar" ou "atualizar")

Uma atualização integra alterações que foram feitas no repositório (por exemplo, por outras pessoas) na cópia de trabalho local.

Cópia de trabalho ("espaço de trabalho")

A cópia de trabalho é a cópia local dos arquivos em um repositório, em um momento específico ou revisão. Todo o trabalho realizado nos arquivos de um repositório é inicialmente realizado em uma cópia de trabalho, daí seu nome. Conceitualmente, é uma sandbox ou sandbox.

Congelar

Significa permitir que as últimas alterações (commits) para corrigir bugs sejam resolvidas em um lançamento (release) e suspender quaisquer outras alterações antes de um lançamento, a fim de obter uma versão consistente. Se o repositório não estiver congelado, um desenvolvedor poderá começar a resolver um bug cuja resolução não esteja planejada e cuja resolução resulte em efeitos colaterais imprevistos.

Para colaborar em um projeto usando um sistema de controle de versão, a primeira coisa que você precisa fazer é criar uma cópia local obtendo informações do repositório. O usuário pode então modificar a cópia. Existem dois esquemas básicos de funcionamento para que os usuários possam contribuir com suas modificações:

• - exclusivamente: neste esquema, para realizar uma alteração, é necessário comunicar ao repositório o elemento que se deseja modificar e o sistema será responsável por impedir que outro usuário modifique o referido elemento. Uma vez feita a modificação, ela é compartilhada com os demais colaboradores. Se você tiver terminado de modificar um elemento, esse elemento será liberado para que outros possam modificá-lo.

• - Colaborativamente: neste esquema cada usuário modifica a cópia local e quando o usuário decide compartilhar as alterações o sistema tenta automaticamente combinar as diversas modificações. O principal problema é o possível aparecimento de conflitos que devem ser resolvidos manualmente ou as possíveis inconsistências que surgem ao modificar o mesmo arquivo por várias pessoas descoordenadas. Além disso, esta semântica não é apropriada para arquivos binários.

O controle de versão do Team Foundation Server permite que você escolha uma das duas formas de colaboração.

Podemos clasificar los sistemas de control de versiones atendiendo a la arquitectura utilizada para el almacenamiento del código:.

• - Distribuidos: cada usuario tiene su propio repositorio. Los distintos repositorios pueden intercambiar y mezclar revisiones entre ellos. Es frecuente el uso de un repositorio, que está normalmente disponible, que sirve de punto de sincronización de los distintos repositorios locales. Ejemplos: Git y Mercurial.

• - Centralizados: existe un repositorio centralizado de todo el código, del cual es responsable un único usuario (o conjunto de ellos). Se facilitan las tareas administrativas a cambio de reducir flexibilidad, pues todas las decisiones fuertes (como crear una nueva rama) necesitan la aprobación del responsable. Algunos ejemplos son CVS, Subversion o Team Foundation Server.

Vantagens dos sistemas distribuídos

• - Você precisa estar conectado à rede menos vezes para realizar operações. Isso produz maior autonomia e maior velocidade.

• - Mesmo que o repositório remoto fique inativo, as pessoas poderão continuar trabalhando.

• - Ao fazer dos diferentes repositórios uma réplica local da informação dos repositórios remotos aos quais se conectam, a informação é altamente replicada e, portanto, o sistema tem menos problemas de recuperação se, por exemplo, a máquina que possui o repositório remoto queimar. Portanto, há menos necessidade de backups. Porém, backups ainda são necessários para resolver situações em que determinadas informações ainda não foram replicadas.

• - Permite manter repositórios centrais mais limpos no sentido de que um usuário pode decidir que certas alterações feitas por ele no repositório local não são relevantes para o resto dos usuários e, portanto, não permite que essa informação seja acessível publicamente, seja porque contém versões instáveis, em processo de codificação ou com rótulos personalizados e para uso exclusivo do usuário.

• - O servidor remoto requer menos recursos do que um servidor centralizado necessitaria, já que grande parte do trabalho é feito por repositórios locais.

• - Sendo os sistemas distribuídos mais recentes que os sistemas centralizados, e tendo mais flexibilidade por terem um repositório local e um ou mais repositórios remotos, estes sistemas foram concebidos para facilitar a utilização de ramificações (criação, evolução e fusão) e poder tirar o máximo partido do seu potencial. Por exemplo, ramificações podem ser criadas no repositório remoto para corrigir bugs ou criar novos recursos. Mas ramificações também podem ser criadas em repositórios locais para que os usuários possam testar e dependendo dos resultados, mesclá-las com o desenvolvimento principal ou não. As filiais proporcionam grande flexibilidade na forma como você trabalha.

Vantagens dos sistemas centralizados

• - Em sistemas distribuídos há menos controle quando se trabalha em equipe, pois não existe uma versão centralizada de tudo o que está sendo feito no projeto.

• - Em sistemas centralizados, as versões são identificadas por um número de versão. Porém, em sistemas distribuídos de controle de versão não há números de versão, pois cada repositório teria seus próprios números de revisão dependendo das alterações. Em vez disso, cada versão possui um identificador ao qual uma tag pode ser associada (tag).

El flujo de trabajo de un sistema de control de versiones indica cómo se relacionan los distintos usuarios para colaborar entre sí en la consecución de los objetivos del proyecto.

En los sistemas de control de versiones centralizados el diseño del sistema restringe la forma en que los distintos usuarios colaboran entre sí. Sin embargo en los sistemas de control de versiones distribuidos hay mucha más flexibilidad en la forma de colaborar ya que cada desarrollador puede tanto contribuir como recibir contribuciones. Hay distintos flujos de trabajo, donde cada uno se adapta mejor a cierto tipo de proyectos. Veamos algunos ejemplo habituales que también se pueden combinar para así adaptarse mejor al proyecto concreto (por ejemplo podría usarse en general un flujo centralizado, y usar un gestor de integraciones para ciertas partes críticas y de especial importancia).[3]​.

Fluxo de trabalho centralizado

No Fluxo de Trabalho Centralizado, cada desenvolvedor é um nó de trabalho. Por outro lado, existe um repositório remoto central que funciona como ponto de sincronização. Todos os nós de trabalho operam igualmente no repositório remoto central.

Se for um sistema de controle de versão distribuído, cada nó de trabalho consiste em um repositório local privado.

Uma desvantagem desta forma de trabalhar é que se dois usuários clonarem a partir de um ponto central, e ambos fizerem alterações; Somente a primeira pessoa a enviar suas alterações poderá fazê-lo de forma limpa. O segundo desenvolvedor deve primeiro mesclar seu trabalho com o do primeiro, antes de submetê-lo, para evitar sobrescrever as alterações do primeiro. Ou seja, é necessário realizar uma etapa anterior, pois não é possível fazer upload de alterações que não sejam de avanço rápido (mudanças que não sejam de avanço rápido).

Fluxo de trabalho com um gerenciador de integração

No fluxo de trabalho com um Integration-Manager Workflow (em inglês Integration-Manager Workflow) em que cada desenvolvedor tem acesso de gravação ao seu próprio repositório público e acesso de leitura aos repositórios públicos de todos os outros usuários. Por outro lado, existe um repositório canônico, o representante ‘oficial’ do projeto.

Para contribuir com esses projetos, cada desenvolvedor cria seu próprio clone público do repositório canônico e submete a ele suas alterações (feitas em um repositório privado). Para 'carregar' suas alterações no repositório canônico, cada desenvolvedor deve fazer uma solicitação à pessoa que o gerencia.

A principal vantagem desta forma de trabalhar é que você pode continuar trabalhando, e a pessoa que gerencia o repositório canônico poderá recuperar suas alterações a qualquer momento. Os colaboradores não precisam esperar que suas alterações sejam incorporadas ao projeto, cada um pode trabalhar no seu próprio ritmo.

Fluxo de trabalho com ditador e tenentes

O Fluxo de Trabalho de Ditadores e Tenentes é uma extensão do Fluxo de Trabalho do Gerenciador de Integração. É utilizado em projetos muito grandes, com centenas de colaboradores, como o kernel Linux.

Há uma série de gerenciadores de integração responsáveis ​​por partes específicas do repositório, que são chamados de tenentes. Todos os tenentes se reportam a um gerente de integração; conhecido como ditador. O ditador integra todas as contribuições dos tenentes publicando a obra em um repositório de referência do qual todos os colaboradores a recuperam.

Este sistema de trabalho permite ao líder do grupo (o ditador) delegar grande parte do trabalho aos tenentes, relegando o seu trabalho à recolha dos frutos de múltiplos pontos de trabalho.

Las ramas, en un sistema de control de versiones, constituyen una potente herramienta que flexibiliza la forma en la que los colaboradores cooperan en el proyecto (en inglés Branching Workflows). Las ramas son solo una herramienta que es posible utilizar de distintas formas para conseguir distintos objetivos. Veamos algunas posibilidades.[3]​[4]​.

filiais de longo curso

Em alguns projetos existem diversas ramificações sempre abertas, o que indica graus variados de estabilidade de conteúdo. Por exemplo, no branch 'master' é comum manter apenas o que é completamente estável. Depois, há outros ramos que revelam diferentes graus de estabilidade. Por exemplo, poderíamos ter um branch 'beta' (versão beta) e outro branch 'alpha' (versão alfa), no qual estamos trabalhando. Quando se atinge um certo grau de estabilidade maior que o ramo em que está presente, realiza-se uma fusão com um ramo de maior estabilidade.

Ramos específicos

Ramos específicos, também chamados de ramos de suporte, são ramos criados ocasionalmente para executar uma funcionalidade muito específica. Por exemplo, adicionar um novo recurso (eles são chamados de novas ramificações de funcionalidade ou diretamente pelo nome em inglês topic branch ou feature branch) ou corrigir um bug específico (eles são chamados de bug fix branch ou diretamente pelo nome em inglês hotfix branch).

Estes tipos de ramos permitem-nos trabalhar focando exclusivamente no desenvolvimento de uma funcionalidade específica e quando concluído é fundido com um dos ramos de longo prazo (normalmente com aquele com menor nível de estabilidade, para que possa ser testado naquele ambiente). A mesclagem só é feita quando você tem 'certeza' de que o recurso está implementado corretamente, em vez de mesclar na ordem em que as coisas são desenvolvidas. Isto permite, por um lado, ter um histórico das diferentes versões que existiram até que a funcionalidade fosse alcançada. Por outro lado, permitem que o histórico das filiais de longo prazo não fique 'sujo' com diversas modificações relacionadas a uma funcionalidade específica.

A utilização deste tipo de ramificações permite maior flexibilidade no teste de possíveis soluções. Ele só se funde com ramificações de longa duração quando temos certeza de que escolhemos a melhor solução.

Um tipo de branch deste tipo que possui uma função especial são os chamados version branch ou release branch* (em inglês release branch). Estes tipos de ramificações são criados para apoiar a preparação de uma nova versão de produção. Eles permitem que você tenha o conteúdo da versão sob controle e possa realizar algumas manutenções nela (adicionar pequenas melhorias e corrigir erros).

É comum e uma boa prática usar um prefixo no nome da filial que indique o tipo de filial. Por exemplo, você pode usar 'feature-' para novas ramificações de recursos, 'hotfix-' para ramificações de correção de bugs e 'release-' para ramificações de lançamento.

• - Programas de controle de versão.

• - Gerenciamento de configuração de software.

• - Software.

• -CVS.

• - Git.

• - GitHub.