Abraçar mudanças (I)
Tags: git, development, desenvolvimento
Published: 2020-12-19 13:22:50

Este é o primeiro artigo de uma série sobre [Git](https://www.git-scm.com). É um assunto extenso que será dividido em: 

I - Controle de versão
[II - Configuração](https://dev.to/hilam/abracar-as-mudancas-ii-246b)
[III - O que há por baixo dos panos](https://dev.to/hilam/abracar-as-mudancas-iii-5f7h)
[IV - Comandos mais comuns](https://dev.to/hilam/abracar-mudancas-iv-3p63)
V - Fluxo de trabalho
VI - Serviços Git na web
VII - Contribuindo com código aberto

### Controle de versão

Nos processos de escrita, nos defrontamos constantemente com um desafio: **precisamos produzir** (incluir, alterar ou excluir texto); para testar novas possibilidades, descartar coisas que não fazem mais sentido,  aplicar novas aprendizagens, é necessário **manter versões anteriores**, para que se possa perceber a evolução em que a obra foi processada e, eventualmente, retornar a um estágio anterior, desistindo de tais mudanças.

A forma viva dos escritos é o **rascunho**. A escrita acontece enquanto processo. Tudo é rascunho, até que nos **comprometemos** com um "momento", para dar a obra como "acabada". Não costumamos enxergar a gradação e evolução numa obra acabada, mas elas estão lá. 

Daí, decorre uma lição importante: não se apegue demais ao que escreve, pois tudo flui. Mesmo a obra dada como acabada por um autor, ainda **poderá evoluir (ou degradar)**, ser escrita de forma diferente, seja pelo mesmo autor, seja por outros.

Códigos em linguagens de programação, se beneficiam muito do que chamaremos "controle de versão". É necessário testar antes de distribuir, sempre mantendo a possibilidade de reversão de quaisquer mudanças, e, em algum momento, há o comprometimento com uma estabilidade temporária, que poderá ser distribuída a terceiros.

A ferramenta mais utilizada atualmente para controle de versão é o [Git](https://www.git-scm.com/downloads). O objetivo é a fácil recuperação em caso de erros ou perda de arquivos. Os meios: histórico e documentação das mudanças, comparação de diferenças e possibilidade de desfazer alterações, todas elas disponíveis nessa ferramenta.

### Termos comuns do Git

* Repository (repositório): Uma pasta de arquivos, nomeada **.git**, criada e controlada pela ferramenta, que armazena objetos internos, metadados e os arquivos e pastas que queremos **rastrear**. Tem, por padrão uma ramificação (branch) inicial, atualmente denominada "main"

* Clone: Cópia, duplicação de um repositório

* Working area (área de trabalho): Uma lista de arquivos da pasta sendo rastreada, em que cada arquivo tem um **estado**, na ramificação ativada no momento: "não rastreado" (untracked), "não modificado" (unmodified), "modificado" (modified) ou "confirmado" (staged)

* Index (índice, sumário): Um arquivo do repositório que armazena informação sobre **quais alterações farão parte do próximo** envio ao repositório. Também conhecida como Staging Area (área de preparação)

* Commit (envio, entrega): Confirmação das mudanças incluídas no índice, que são enviadas ao repositório, na forma de "instantâneos" (snapshots, no sentido fotográfico). Um momento de **comprometimento**

* Branch (ramo, galho): Uma ramificação (versão) obtida a partir do ramo principal ou de outra ramificação, cujas confirmações de alterações estão **separadas** do ramo de origem

* Push (empurrar): Transferir arquivos de um repositório fonte (atual) para outro repositório (local ou remoto)

* Pull (puxar, extrair): Trazer as últimas mudanças de um repositório (local ou remoto) para o repositório atual.


No [próximo artigo](https://dev.to/hilam/abracar-as-mudancas-ii-246b), começamos a desentranhar a ferramenta, iniciando pela sua configuração.