> For the complete documentation index, see [llms.txt](https://cumbucadev.gitbook.io/github-essentials/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cumbucadev.gitbook.io/github-essentials/dia-2/introducao-a-sistemas-de-controle-de-versao/sistemas-de-controle-de-versao-centralizados.md). # Sistemas de controle de versão centralizados ## A importância de entender os sistemas centralizados O Git, sistema de controle de versão que vamos estudar neste livro, é um sistema **distribuído**. Mas, antes de irmos direto para esse modelo mais moderno, é importante entender como os sistemas centralizados funcionavam — e por que eles motivaram a criação de algo novo. Mesmo que você não vá usar um sistema centralizado na prática, entender como ele funciona ajuda a compreender melhor o Git. Muitas decisões do Git fazem mais sentido quando conhecemos os problemas que ele veio resolver. Em algum momento, você provavelmente vai se perguntar: “*Mas por que o Git faz isso desse jeito tão complicado?*”**.** Com esse contexto, o que parece esquisito no começo passa a fazer sentido — e você percebe que existe uma lógica por trás de tudo. No mais, não se preocupe em entender especificidades dos sistemas centralizados. O foco deste livro é o modelo distribuído — e é nele que vamos mergulhar de verdade ao longo dos próximos capítulos. ## **Como funcionam** Imagine que você e outras pessoas estão colaborando em um projeto. Para manter tudo organizado, vocês combinam de guardar os arquivos em um lugar compartilhado. Criam, então, uma **pasta** especial que reúne todos os arquivos do projeto **e** registra o histórico completo de alterações: o que foi mudado, por quem, quando e por quê. É como ter uma linha do tempo detalhada de tudo que já aconteceu no projeto.

Grande pasta que contém os arquivos e suas versões

Mas como várias pessoas poderiam colaborar ao mesmo tempo? Essa pasta poderia ficar em outro computador — um **servidor** — que funcionaria como o ponto central do projeto. Assim, todo mundo poderia acessar e contribuir, sem precisar estar no mesmo lugar ou usar o mesmo computador. IMAGEM

Servidor: onde a "Grande Pasta" fica localizada

Cada pessoa que quisesse colaborar com o projeto poderia **baixar** para o seu computador a versão mais recente de cada arquivo. IMAGEM

Usuário 2 fazendo a cópia atualizada do Repositório Central do Servidor

Depois, faria as alterações necessárias localmente e, em seguida, **enviaria** de volta apenas o que tivesse mudado — os arquivos modificados, adicionados ou removidos. Os arquivos que permanecessem iguais não precisariam ser reenviados. Parece que funcionaria bem! Mas... e se mais de uma pessoa quiser editar o mesmo arquivo ao mesmo tempo? Aí a coisa complica, né? Para lidar com isso, vocês poderiam adotar uma estratégia de **bloqueio**. Quando alguém começa a editar um arquivo, avisa que ele está bloqueado, impedindo que outras pessoas façam alterações até que o bloqueio seja liberado. Esta estratégia era utilizada em um controle de versão chamado [Microsoft Visual SourceSafe](https://pt.wikipedia.org/wiki/Microsoft_Visual_SourceSafe), que, aliás, tinha muitos problemas exatamente por este mecanismo. Outra possibilidade seria permitir que todo mundo edite livremente. Depois, quando as alterações fossem reunidas novamente na pasta compartilhada, alguém precisaria comparar o que mudou e tentar **mesclar** os conteúdos. Se duas pessoas tivessem mexido na mesma parte de um arquivo, isso poderia gerar **conflitos** — e aí alguém teria que resolvê-los manualmente. Esse é exatamente o funcionamento de um sistema de controle de versão centralizado. Agora que a ideia geral está clara, vamos ver como isso tudo é chamado na prática — os nomes e termos usados pra descrever essas partes e ações no jeito como o sistema foi pensado. ## Conceitos básicos de controle de versão centralizado Agora que já vimos como funciona, de forma geral, um sistema de controle de versão centralizado, vamos conhecer alguns dos termos mais usados nesse modelo. Logo depois dessa explicação, vamos ver um exemplo prático de uso, que vai ajudar a entender melhor como tudo isso acontece na prática. ### **Repositório remoto central** É uma pasta onde ficam guardados todos os arquivos do projeto e o histórico completo das versões. E é chamado de **remoto** porque geralmente essa pasta não está no seu computador, mas sim em outro — um servidor — acessado pela internet. E é chamado de **central** porque é o ponto principal de encontro: todas as pessoas colaboradoras acessam essa mesma pasta para enviar e receber alterações. ### **Checkout** É o processo de obter uma cópia de trabalho do projeto a partir do repositório central. Essa cópia traz apenas os arquivos mais atuais — ou seja, a versão mais recente de cada um. O histórico completo **não** fica salvo localmente: ele continua no servidor. Por isso, qualquer consulta ao passado ou envio de mudanças depende de uma conexão com o repositório central. ### **Pull** É o processo de atualizar a cópia local do projeto com as alterações mais recentes que foram enviadas ao repositório central. É uma forma de manter o ambiente de trabalho sincronizado com o que outras pessoas já modificaram. ### **Push** É o processo de enviar as mudanças feitas localmente — arquivos adicionados, modificados ou removidos — de volta para o repositório central. Isso permite que outras pessoas também tenham acesso a essas alterações. ### **Lock** É uma estratégia usada para evitar conflitos: ao editar um arquivo, a pessoa sinaliza que ele está “travado” para alterações por outras pessoas. O sistema, então, garante que apenas uma pessoa faça mudanças naquele arquivo por vez, reduzindo o risco de sobrescrever o trabalho de alguém. ### Merge É o processo de combinar ("mesclar") alterações feitas por pessoas diferentes que editaram **o** mesmo arquivo. Se cada uma modificou partes diferentes do conteúdo, as mudanças costumam ser integradas automaticamente. Mas, se **duas** pessoas alteraram a mesma parte do arquivo, ocorre um conflito — e alguém precisa revisar essas alterações para decidir qual versão deve ser mantida. ## Exemplo de fluxo de trabalho Uma pessoa **A** e uma pessoa **B** decidem criar um blog. A pessoa **A** cria uma estrutura inicial do blog em seu computador e envia ("***PUSH***") essa versão para o repositório central.
A pessoa **B** se anima com o projeto e também quer contribuir, criando o seu primeiro blog post. Para isso, **B** precisa ter acesso à versão criada por **A**, que já está no repositório central no momento. **B** precisa fazer um "***PULL***", que nada mais é que fazer uma cópia da última versão do projeto que está no repositório central para a sua máquina local.
Agora, **B** tem acesso, em seu computador, ao projeto em sua versão mais atual. **B** escreve seu primeiro *blog post* e precisa enviar as mudanças de volta para o repositório central, para que **A** também possa ver o seu belo trabalho. **B** faz um "***PUSH***" do seu código, ou seja, envia uma cópia da sua versão para o repositório central.
Tudo pronto! Temos no repositório central a versão mais recente do blog, a qual contém o post de **B**. A versão inicial de **A** também está lá, guardada caso alguém precise consultá-la para comparar diferenças, ou até mesmo para reverter alguma alteração.
Mas, e se **A** também estiver empolgado e não conseguir esperar por **B**? Ao mesmo tempo que **B**, **A** começa a escrever seu próprio post. Quando **A** tenta enviar seu código para o repositório central, percebe que **B** já enviou antes a sua versão.
E para piorar, **A** e **B** modificaram o mesmo arquivo! E agora?
Bom, é aí que entra em jogo umas das principais funcionalidades de um sistema de controle de versão: o auxílio no Gerenciamento de Conflitos. O sistema lida com as mudanças feitas por diferentes colaboradores no mesmo arquivo, evitando conflitos e garantindo uma integração suave das alterações. Isso é feito por meio de um processo chamado 'mesclagem', que combina o trabalho de todos de forma harmoniosa e mantém a consistência do projeto. Dessa forma, **A** consegue tranquilamente enviar suas modificações sem comprometer em nada as mudanças feitas por **B**.
***

Mapa do funcionamento de um Sistema de Controle de Versão Centralizado

Exemplos de sistemas centralizados de controle de versão incluem o Subversion (SVN) e o Microsoft Team Foundation Version Control (TFVC). Embora os sistemas centralizados tenham sido amplamente utilizados no passado, muitas equipes estão migrando para sistemas de controle de versão distribuídos, como o Git, devido à sua flexibilidade, desempenho e recursos avançados que iremos começar a desvendar aos poucos daqui para frente. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://cumbucadev.gitbook.io/github-essentials/dia-2/introducao-a-sistemas-de-controle-de-versao/sistemas-de-controle-de-versao-centralizados.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.