Controle de versão - Version control

Na engenharia de software , o controle de versão (também conhecido como controle de revisão , controle de origem ou gerenciamento de código-fonte ) é uma classe de sistemas responsável por gerenciar alterações em programas de computador , documentos, grandes sites ou outras coleções de informações. O controle de versão é um componente do gerenciamento de configuração de software .

As alterações são geralmente identificadas por um número ou código de letra, denominado "número de revisão", "nível de revisão" ou simplesmente "revisão". Por exemplo, um conjunto inicial de arquivos é a "revisão 1". Quando a primeira alteração é feita, o conjunto resultante é a "revisão 2" e assim por diante. Cada revisão está associada a um carimbo de data / hora e à pessoa que está fazendo a alteração. As revisões podem ser comparadas, restauradas e, com alguns tipos de arquivos, mescladas.

A necessidade de uma maneira lógica de organizar e controlar as revisões existe há quase tanto tempo quanto a escrita existe, mas o controle de revisão tornou-se muito mais importante e complicado quando a era da computação começou. A numeração das edições de livros e das revisões de especificações são exemplos que datam da era somente impressa. Hoje, os sistemas de controle de revisão mais capazes (bem como complexos) são aqueles usados ​​no desenvolvimento de software , onde uma equipe de pessoas pode fazer alterações simultaneamente nos mesmos arquivos.

Os sistemas de controle de versão ( VCS ) são mais comumente executados como aplicativos autônomos, mas o controle de revisão também está embutido em vários tipos de software, como processadores de texto e planilhas , documentos da web colaborativos e em vários sistemas de gerenciamento de conteúdo , por exemplo, o histórico da página da Wikipedia . O controle de revisão permite reverter um documento para uma revisão anterior, o que é crítico para permitir que os editores rastreiem as edições uns dos outros, corrijam erros e se defendam contra vandalismo e spam em wikis .

Visão geral

Na engenharia de software de computador , o controle de revisão é qualquer tipo de prática que rastreia e fornece controle sobre as alterações no código-fonte . Os desenvolvedores de software às vezes usam software de controle de revisão para manter os arquivos de documentação e configuração , bem como o código-fonte.

Conforme as equipes projetam, desenvolvem e implantam software, é comum que várias versões do mesmo software sejam implantadas em locais diferentes e que os desenvolvedores do software trabalhem simultaneamente nas atualizações. Bugs ou recursos do software geralmente estão presentes apenas em certas versões (devido à correção de alguns problemas e à introdução de outros à medida que o programa se desenvolve). Portanto, para fins de localização e correção de bugs, é de vital importância ser capaz de recuperar e executar diferentes versões do software para determinar em qual (is) versão (ões) o problema ocorre. Também pode ser necessário desenvolver duas versões do software simultaneamente: por exemplo, onde uma versão tem bugs corrigidos, mas sem novos recursos ( branch ), enquanto a outra versão é onde os novos recursos são trabalhados ( tronco ).

No nível mais simples, os desenvolvedores podem simplesmente reter várias cópias das diferentes versões do programa e rotulá-las de forma adequada. Essa abordagem simples foi usada em muitos grandes projetos de software. Embora esse método possa funcionar, ele é ineficiente, pois muitas cópias quase idênticas do programa precisam ser mantidas. Isso requer muita autodisciplina por parte dos desenvolvedores e geralmente leva a erros. Como a base de código é a mesma, também é necessário conceder permissão de leitura-gravação-execução a um conjunto de desenvolvedores, e isso aumenta a pressão de alguém que gerencia as permissões para que a base de código não seja comprometida, o que adiciona mais complexidade. Consequentemente, foram desenvolvidos sistemas para automatizar parte ou todo o processo de controle de revisão. Isso garante que a maioria das etapas de gerenciamento de controle de versão fique oculta nos bastidores.

Além disso, no desenvolvimento de software, na prática jurídica e de negócios e em outros ambientes, tornou-se cada vez mais comum que um único documento ou fragmento de código seja editado por uma equipe, cujos membros podem estar geograficamente dispersos e podem exercer atividades diferentes e até contrárias interesses. O controle de revisão sofisticado que rastreia e contabiliza a propriedade de alterações em documentos e códigos pode ser extremamente útil ou mesmo indispensável em tais situações.

O controle de revisão também pode rastrear alterações nos arquivos de configuração , como aqueles normalmente armazenados em /etcou /usr/local/etcem sistemas Unix. Isso oferece aos administradores de sistema outra maneira de rastrear facilmente as alterações feitas e uma maneira de reverter para versões anteriores, se necessário.

História

A ferramenta de atualização de software OS / 360 IEBUPDTE da IBM data de 1962, indiscutivelmente um precursor das ferramentas VCS. Um sistema completo projetado para controle de código-fonte foi iniciado em 1972, SCCS para o mesmo sistema (OS / 360). A introdução do SCCS, publicada em 4 de dezembro de 1975, implicava historicamente que ele foi o primeiro sistema de controle de revisão deliberado. O RCS veio logo em seguida, com sua versão CVS em rede. A geração seguinte após o CVS foi dominada pelo Subversion , seguida pelo surgimento de ferramentas de controle de revisão distribuídas como o Git .

Estrutura

O controle de revisão gerencia as alterações em um conjunto de dados ao longo do tempo. Essas mudanças podem ser estruturadas de várias maneiras.

Freqüentemente, os dados são considerados uma coleção de muitos itens individuais, como arquivos ou documentos, e as alterações em arquivos individuais são rastreadas. Isso está de acordo com as intuições sobre arquivos separados, mas causa problemas quando a identidade muda, como durante a renomeação, divisão ou fusão de arquivos. Da mesma forma, alguns sistemas como o Git , em vez disso, consideram as mudanças nos dados como um todo, o que é menos intuitivo para mudanças simples, mas simplifica mudanças mais complexas.

Quando os dados que estão sob controle de revisão são modificados, após serem recuperados por check-out, isso não é em geral imediatamente refletido no sistema de controle de revisão (no repositório ), mas deve ser verificado ou confirmado. Uma cópia fora do controle de revisão é conhecida como "cópia de trabalho". Como um exemplo simples, ao editar um arquivo de computador, os dados armazenados na memória pelo programa de edição são a cópia de trabalho, que é confirmada ao salvar. Concretamente, pode-se imprimir um documento, editá-lo manualmente e só depois inserir manualmente as alterações em um computador e salvá-lo. Para controle do código-fonte, a cópia de trabalho é, em vez disso, uma cópia de todos os arquivos em uma revisão particular, geralmente armazenada localmente no computador do desenvolvedor; neste caso, salvar o arquivo apenas altera a cópia de trabalho e fazer o check-in no repositório é uma etapa separada.

Se várias pessoas estão trabalhando em um único conjunto de dados ou documento, elas estão implicitamente criando ramificações dos dados (em suas cópias de trabalho) e, portanto, surgem problemas de mesclagem, conforme discutido abaixo. Para a edição colaborativa simples de documentos, isso pode ser evitado usando o bloqueio de arquivo ou simplesmente evitando trabalhar no mesmo documento em que outra pessoa está trabalhando.

Os sistemas de controle de revisão costumam ser centralizados, com um único armazenamento de dados autorizado, o repositório e check-outs e check-ins feitos com referência a esse repositório central. Alternativamente, no controle de revisão distribuída , nenhum repositório único é autoritativo e os dados podem ser retirados e registrados em qualquer repositório. Ao fazer check-in em um repositório diferente, isso é interpretado como uma fusão ou patch.

Estrutura do gráfico

Exemplo de gráfico de histórico de um projeto controlado por revisão; o tronco está em verde, os galhos em amarelo e o gráfico não é uma árvore devido à presença de mesclagens (as setas vermelhas).

Em termos de teoria dos grafos , as revisões são geralmente pensadas como uma linha de desenvolvimento (o tronco ) com galhos, formando uma árvore direcionada, visualizada como uma ou mais linhas paralelas de desenvolvimento (as "linhas principais" dos galhos) ramificando fora de um tronco. Na realidade, a estrutura é mais complicada, formando um grafo acíclico direcionado , mas para muitos propósitos "árvore com fusões" é uma aproximação adequada.

As revisões ocorrem em sequência ao longo do tempo e, portanto, podem ser organizadas em ordem, por número de revisão ou registro de data e hora. As revisões são baseadas em revisões anteriores, embora seja possível substituir em grande parte ou completamente uma revisão anterior, como "excluir todo o texto existente, inserir novo texto". No caso mais simples, sem ramificação ou desfazimento, cada revisão é baseada apenas em seu predecessor imediato, e elas formam uma linha simples, com uma única versão mais recente, a revisão ou dica "HEAD" . Em termos de teoria de grafos , desenhando cada revisão como um ponto e cada relação de "revisão derivada" como uma seta (apontando convencionalmente do mais antigo para o mais recente, na mesma direção do tempo), este é um gráfico linear . Se houver ramificação, então múltiplas revisões futuras são baseadas em uma revisão passada, ou desfazendo, então uma revisão pode depender de uma revisão mais antiga que sua predecessora imediata, então o gráfico resultante é ao invés uma árvore direcionada (cada nó pode ter mais de um filho), e tem várias dicas, correspondendo às revisões sem filhos ("última revisão em cada ramo"). Em princípio, a árvore resultante não precisa ter uma dica preferida (última revisão "principal") - apenas várias revisões diferentes - mas na prática uma dica é geralmente identificada como HEAD. Quando uma nova revisão é baseada no HEAD, ela é identificada como o novo HEAD ou considerada uma nova ramificação. A lista de revisões do início ao HEAD (em termos da teoria dos grafos, o caminho único na árvore, que forma um gráfico linear como antes) é o tronco ou linha principal. Por outro lado, quando uma revisão pode basear-se em mais do que uma revisão anterior (quando um nó pode ter mais do que um progenitor ), o processo resultante é chamada uma mala , e é um dos aspectos mais complexos de controle de revisão. Isso ocorre com mais frequência quando ocorrem alterações em vários ramos (na maioria das vezes dois, mas mais são possíveis), que são então mesclados em um único ramo que incorpora as duas mudanças. Se essas alterações se sobreporem, pode ser difícil ou impossível mesclar e exigir intervenção manual ou reescrita.

Na presença de mesclagens, o grafo resultante não é mais uma árvore, pois os nós podem ter vários pais, mas é um grafo acíclico direcionado (DAG) com raiz . O gráfico é acíclico porque os pais estão sempre atrasados ​​no tempo e enraizados porque há uma versão mais antiga. No entanto, supondo que haja um tronco, as mesclagens dos ramos podem ser consideradas como "externas" à árvore - as alterações no ramo são empacotadas como um patch, que é aplicado ao HEAD (do tronco), criando uma nova revisão sem qualquer referência explícita ao ramo e preservando a estrutura da árvore. Assim, embora as relações reais entre as versões formem um DAG, isso pode ser considerado uma árvore mais mesclagens, e o próprio tronco é uma linha.

No controle de revisão distribuída, na presença de vários repositórios, estes podem ser baseados em uma única versão original (uma raiz da árvore), mas não precisa haver uma raiz original e, portanto, apenas uma raiz separada (revisão mais antiga) para cada repositório , por exemplo, se duas pessoas começarem a trabalhar em um projeto separadamente. Da mesma forma, na presença de vários conjuntos de dados (vários projetos) que trocam dados ou se fundem, não há uma única raiz, embora, para simplificar, possamos pensar em um projeto como primário e o outro como secundário, fundidos no primeiro com ou sem seu próprio histórico de revisão.

Estratégias especializadas

Controle de revisão de engenharia desenvolvido a partir de processos formalizados com base no rastreamento de revisões de projetos iniciais ou linhas azuis . Este sistema de controle implicitamente permitiu o retorno a um estado anterior do projeto, para os casos em que um beco sem saída da engenharia foi alcançado no desenvolvimento do projeto. Uma tabela de revisão foi usada para acompanhar as alterações feitas. Além disso, as áreas modificadas do desenho foram destacadas usando nuvens de revisão.

O controle de versão é amplamente difundido em negócios e direito. Na verdade, "linha negra de contrato" e "linha negra legal" são algumas das primeiras formas de controle de revisão e ainda são empregadas em negócios e direito com vários graus de sofisticação. As técnicas mais sofisticadas estão começando a ser usadas para o rastreamento eletrônico de alterações em arquivos CAD (ver gerenciamento de dados de produtos ), suplantando a implementação eletrônica "manual" do controle de revisão tradicional.

Modelos de gerenciamento de fontes

Os sistemas de controle de revisão tradicionais usam um modelo centralizado onde todas as funções de controle de revisão ocorrem em um servidor compartilhado . Se dois desenvolvedores tentarem alterar o mesmo arquivo ao mesmo tempo, sem algum método de gerenciamento de acesso, os desenvolvedores podem acabar substituindo o trabalho um do outro. Os sistemas de controle de revisão centralizados resolvem esse problema em um dos dois "modelos de gerenciamento de origem" diferentes: bloqueio de arquivo e mesclagem de versão.

Operações atômicas

Uma operação é atômica se o sistema for deixado em um estado consistente, mesmo se a operação for interrompida. A operação de confirmação é geralmente a mais crítica neste sentido. Os commits dizem ao sistema de controle de revisão para fazer um grupo de alterações final e disponível para todos os usuários. Nem todos os sistemas de controle de revisão têm commits atômicos; notavelmente, o CVS não possui esse recurso.

Bloqueio de arquivo

O método mais simples de evitar problemas de " acesso simultâneo " envolve o bloqueio de arquivos para que apenas um desenvolvedor de cada vez tenha acesso de gravação às cópias do "repositório" central desses arquivos. Depois que um desenvolvedor "faz check-out" de um arquivo, outros podem lê-lo, mas ninguém mais pode alterá-lo até que o desenvolvedor "faça check-in" da versão atualizada (ou cancele o check-out).

O bloqueio de arquivos tem vantagens e desvantagens. Ele pode fornecer alguma proteção contra conflitos de mesclagem difíceis quando um usuário está fazendo alterações radicais em muitas seções de um arquivo grande (ou grupo de arquivos). No entanto, se os arquivos forem deixados exclusivamente bloqueados por muito tempo, outros desenvolvedores podem ser tentados a ignorar o software de controle de revisão e alterar os arquivos localmente, forçando uma mesclagem manual difícil quando as outras alterações forem finalmente registradas. Em uma grande organização, os arquivos podem ser deixados "retirados" e bloqueados e esquecidos conforme os desenvolvedores se movem entre os projetos - essas ferramentas podem ou não tornar mais fácil ver quem tem um arquivo retirado.

Mesclagem de versões

A maioria dos sistemas de controle de versão permite que vários desenvolvedores editem o mesmo arquivo ao mesmo tempo. O primeiro desenvolvedor a "registrar" as alterações no repositório central sempre é bem-sucedido. O sistema pode fornecer recursos para mesclar outras alterações no repositório central e preservar as alterações do primeiro desenvolvedor quando outros desenvolvedores fizerem check-in.

A fusão de dois arquivos pode ser uma operação muito delicada e, geralmente, possível apenas se a estrutura de dados for simples, como em arquivos de texto . O resultado da fusão de dois arquivos de imagem pode não resultar em um arquivo de imagem. O segundo desenvolvedor verificando o código precisará tomar cuidado com a mesclagem, para ter certeza de que as alterações são compatíveis e que a operação de mesclagem não introduz seus próprios erros lógicos nos arquivos. Esses problemas limitam a disponibilidade de operações de mesclagem automáticas ou semiautomáticas principalmente para documentos simples baseados em texto, a menos que um plug - in de mesclagem específico esteja disponível para os tipos de arquivo.

O conceito de uma edição reservada pode fornecer um meio opcional de bloquear explicitamente um arquivo para acesso de gravação exclusivo, mesmo quando existe um recurso de mesclagem.

Linhas de base, rótulos e tags

A maioria das ferramentas de controle de revisão usará apenas um desses termos semelhantes (linha de base, rótulo, tag) para se referir à ação de identificar um instantâneo ("rotular o projeto") ou o registro do instantâneo ("tentar com a linha de base X ") . Normalmente, apenas um dos termos linha de base , rótulo ou tag é usado na documentação ou discussão; eles podem ser considerados sinônimos.

Na maioria dos projetos, alguns instantâneos são mais significativos do que outros, como aqueles usados ​​para indicar lançamentos publicados, ramos ou marcos.

Quando tanto o termo linha de base quanto rótulo ou tag são usados ​​juntos no mesmo contexto, rótulo e tag geralmente se referem ao mecanismo dentro da ferramenta de identificação ou registro do instantâneo, e a linha de base indica o aumento da significância de qualquer rótulo dado ou tag.

A discussão mais formal do gerenciamento de configuração usa o termo linha de base .

Controle de revisão distribuída

Os sistemas de controle de revisão distribuída (DRCS) adotam uma abordagem ponto a ponto, em oposição à abordagem cliente-servidor de sistemas centralizados. Em vez de um único repositório central no qual os clientes são sincronizados, a cópia de trabalho de cada par da base de código é um repositório de boa-fé . O controle de revisão distribuída conduz a sincronização trocando patches (conjuntos de alterações) ponto a ponto. Isso resulta em algumas diferenças importantes de um sistema centralizado:

  • Nenhuma cópia canônica de referência da base de código existe por padrão; apenas cópias de trabalho.
  • As operações comuns (como commits, visualização do histórico e reversão de alterações) são rápidas, porque não há necessidade de se comunicar com um servidor central.

Em vez disso, a comunicação só é necessária ao empurrar ou puxar mudanças para ou de outros pares.

  • Cada cópia de trabalho funciona efetivamente como um backup remoto da base de código e de seu histórico de alterações, fornecendo proteção inerente contra perda de dados.

Integração

Algumas das ferramentas de controle de revisão mais avançadas oferecem muitos outros recursos, permitindo uma integração mais profunda com outras ferramentas e processos de engenharia de software. Os plug-ins geralmente estão disponíveis para IDEs como Oracle JDeveloper , IntelliJ IDEA , Eclipse e Visual Studio . Delphi , NetBeans IDE , Xcode e GNU Emacs (via vc.el). Protótipos de pesquisa avançada geram mensagens de commit apropriadas, mas só funcionam em projetos com um grande histórico, porque as mensagens de commit são muito dependentes das convenções e idiossincrasias do projeto.

Terminologia comum

A terminologia pode variar de sistema para sistema, mas alguns termos de uso comum incluem:

Linha de base
Uma revisão aprovada de um documento ou arquivo de origem para o qual alterações subsequentes podem ser feitas. Veja linhas de base, rótulos e tags .
Culpa
Uma pesquisa pelo autor e a revisão que modificou pela última vez uma linha específica.
Filial
Um conjunto de arquivos sob controle de versão pode ser ramificado ou bifurcado em um determinado momento, de modo que, daquele momento em diante, duas cópias desses arquivos possam ser desenvolvidas em velocidades diferentes ou de maneiras diferentes, independentemente uma da outra.
Mudar
Uma mudança (ou diff ou delta ) representa uma modificação específica em um documento sob controle de versão. A granularidade da modificação considerada uma mudança varia entre os sistemas de controle de versão.
Lista de mudanças
Em muitos sistemas de controle de versão com commits de várias alterações atômicas , uma lista de alterações (ou CL ), conjunto de alterações , atualização ou patch 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 o exame da origem de qualquer ID de lista de alterações em particular.
Confira
Fazer check-out (ou co ) é criar uma cópia de trabalho local do repositório. Um usuário pode especificar uma revisão específica ou obter a mais recente. O termo 'checkout' também pode ser usado como um substantivo para descrever a cópia de trabalho. Quando um arquivo foi retirado de um servidor de arquivos compartilhado, ele não pode ser editado por outros usuários. Pense nisso como um hotel: ao fazer o check-out, você não terá mais acesso às suas comodidades.
Clone
Clonar significa criar um repositório contendo as revisões de outro repositório. Isso é equivalente a empurrar ou puxar para um repositório vazio (recém-inicializado). Como substantivo, dois repositórios podem ser considerados clones se forem mantidos sincronizados e contiverem as mesmas revisões.
Commit (substantivo)
Um 'commit' ou 'revisão' (SVN) é uma modificação que é aplicada ao repositório.
Confirmar (verbo)
Fazer commit ( check in , ci ou, mais raramente, install , submit ou record ) é escrever ou mesclar as mudanças feitas na cópia de trabalho de volta para o repositório. Um commit contém metadados, normalmente as informações do autor e uma mensagem de commit que descreve a mudança.
Conflito
Um conflito ocorre quando partes diferentes fazem alterações no mesmo documento e o sistema não consegue reconciliar as alterações. Um usuário deve resolver o conflito combinando as alterações ou selecionando uma alteração em favor da outra.
Compressão delta
A maioria dos softwares de controle de revisão usa compactação delta , que retém apenas as diferenças entre as versões sucessivas dos arquivos. Isso permite um armazenamento mais eficiente de muitas versões diferentes de arquivos.
Stream dinâmico
Um fluxo no qual algumas ou todas as versões do arquivo são espelhos das versões do fluxo pai.
Exportar
exportar é o ato de obter os arquivos do repositório. É semelhante ao check-out, exceto que cria uma árvore de diretório limpa sem os metadados de controle de versão usados ​​em uma cópia de trabalho. Isso geralmente é usado antes da publicação do conteúdo, por exemplo.
Buscar
Veja puxar .
Integração direta
O processo de mesclar as alterações feitas no tronco principal em um branch de desenvolvimento (recurso ou equipe).
Cabeça
Às vezes também chamado de tip , refere-se ao commit mais recente, seja para o tronco ou para um branch. O tronco e cada ramo têm sua própria cabeça, embora HEAD às vezes seja vagamente usado para se referir ao tronco.
Importar
importar é o ato de copiar uma árvore de diretório local (que atualmente não é uma cópia de trabalho) para o repositório pela primeira vez.
Inicializar
para criar um novo repositório vazio.
Deltas intercalados
alguns softwares de controle de revisão usam deltas intercalados , um método que permite armazenar o histórico de arquivos baseados em texto de uma forma mais eficiente do que usando compactação Delta .
Rótulo
Veja tag .
Trancando
Quando um desenvolvedor bloqueia um arquivo, ninguém mais pode atualizá-lo até que seja desbloqueado. O bloqueio pode ser suportado pelo sistema de controle de versão ou por meio de comunicações informais entre os desenvolvedores (também conhecido como bloqueio social ).
Linha principal
Semelhante ao tronco , mas pode haver uma linha principal para cada ramo.
Unir
Uma fusão ou integração é uma operação na qual dois conjuntos de alterações são aplicados a um arquivo ou conjunto de arquivos. Alguns exemplos de cenários são os seguintes:
  • Um usuário, trabalhando em um conjunto de arquivos, atualiza ou sincroniza sua cópia de trabalho com as alterações feitas e registradas no repositório por outros usuários.
  • Um usuário tenta fazer check-in de arquivos que foram atualizados por outras pessoas desde que os arquivos foram retirados , e o software de controle de revisão mescla automaticamente os arquivos (normalmente, após perguntar ao usuário se deve prosseguir com a mesclagem automática e, em alguns casos, apenas fazê-lo se a fusão puder ser resolvida de forma clara e razoável).
  • Uma ramificação é criada, o código nos arquivos é editado independentemente e a ramificação atualizada é posteriormente incorporada em um único tronco unificado .
  • Um conjunto de arquivos é ramificado , um problema que existia antes da ramificação é corrigido em uma ramificação e a correção é então mesclada na outra ramificação. (Esse tipo de mesclagem seletiva às vezes é conhecido como uma escolha certa para distingui-la da mesclagem completa no caso anterior.)
Promover
O ato de copiar o conteúdo do arquivo de um local menos controlado para um local mais controlado. Por exemplo, da área de trabalho de um usuário para um repositório ou de um fluxo para seu pai.
Puxe empurre
Copie as revisões de um repositório para outro. O pull é iniciado pelo repositório de recebimento, enquanto o push é iniciado pela fonte. Fetch às vezes é usado como sinônimo de pull ou para significar pull seguido por atualização .
Solicitação de pull
Um desenvolvedor pedindo a outros para mesclar suas alterações "enviadas".
Repositório
O repositório (ou "repo") é onde os dados atuais e históricos dos arquivos são armazenados, geralmente em um servidor. Às vezes também chamado de depósito .
Resolver
O ato de intervenção do usuário para resolver um conflito entre diferentes alterações no mesmo documento.
Integração reversa
O processo de mesclar diferentes ramos da equipe no tronco principal do sistema de controle de versão.
Revisão
Também versão : uma versão é qualquer mudança na forma. No SVK, uma revisão é o estado em um determinado momento de toda a árvore no repositório.
Compartilhado
O ato de disponibilizar um arquivo ou pasta em vários ramos ao mesmo tempo. Quando um arquivo compartilhado é alterado em uma ramificação, ele é alterado em outras ramificações.
Stream
Um contêiner para arquivos ramificados que tem um relacionamento conhecido com outros contêineres. Streams formam uma hierarquia; cada fluxo pode herdar várias propriedades (como versões, namespace, regras de fluxo de trabalho, assinantes, etc.) de seu fluxo pai.
Marcação
Uma tag ou rótulo se refere a um instantâneo importante no tempo, consistente em muitos arquivos. Nesse ponto, esses arquivos podem ser marcados com um nome ou número de revisão amigável e significativo. Veja linhas de base, rótulos e tags .
Tronco
A linha única de desenvolvimento que não é um branch (às vezes também chamada de Baseline, Mainline ou Master)
Atualizar
Uma atualização (ou sincronização , mas sincronização também pode significar um push e pull combinados ) mescla as alterações feitas no repositório (por outras pessoas, por exemplo) na cópia de trabalho local . Atualizar também é o termo usado por algumas ferramentas CM (CM +, PLS, SMS) para o conceito de pacote de mudanças (consulte a lista de mudanças ). Sinônimo de check - out em sistemas de controle de revisão que exigem que cada repositório tenha exatamente uma cópia de trabalho (comum em sistemas distribuídos)
Desbloqueando
liberando uma fechadura.
Cópia de trabalho
A cópia de trabalho é a cópia local dos arquivos de um repositório, em um momento ou revisão específica. Todo o trabalho feito para os arquivos em um repositório é inicialmente feito em uma cópia de trabalho, daí o nome. Conceitualmente, é uma caixa de areia .

Veja também

Notas

Referências

links externos

  • "Guia visual para controle de versão", melhor explicado.
  • Sink, Eric, "Source Control", SCM (como fazer). O básico do controle de versão.