CC CAP07 2025 VA02 VERSIONANDO PROJETOS

Chegou o momento
de a gente criar história.

A gente já entendeu
como o Git consegue nos ajudar.

Então, agora chegou a hora
de colocar a mão na massa

e de fato criar
o nosso primeiro repositório.

Antes da gente começar a criar
de fato a nossa aplicação,

vamos entender
o que é um repositório.

Ele trata-se nada mais nada
menos do que uma pasta,

mas uma pasta
com controle de versão.

Tudo o que nós colocarmos
dentro dessa pasta,

o Git vai observar e vai permitir

que a gente transforme isso
em commits,

que são pontos na linha do tempo.

Então,
ao longo do tempo,

conforme a nossa aplicação
for crescendo,

a gente consegue consultar
essa linha do tempo

e entender as evoluções
que nós tivemos,

o que foi implementado
e entender até mesmo quais arquivos

precisaram ser mexidos
e qual conteúdo deles

que mudaram
como a nossa aplicação funciona.

Então, vamos lá para a máquina
para começar isso de fato.

Eu já crieiuma pasta
chamada "Projetos"

aqui na minha área de trabalho

e é nela que a gente vai criar
todos os nossos repositórios.

Então,
vamos começar abrindo ela aqui

e criando uma nova pasta aqui dentro
chamada "Meu aplicativo".

Dentro dessa pasta
eu vou abri-la

e é muito importante que a gente
use um terminal aqui dentro,

porque o Git é uma ferramenta
de CLI.

Então, podemos usar o PowerShell,
o CMD

ou qualquer outro de nossa
preferência.

Mas como nós instalamos o Git
e o Git traz um próprio Bash dele,

vamos usar o Git Bash
para fazer essa tarefa.

Então,
usando novamente o botão direito,

vamos escolher a opção
"Open Git Bash here".

Um terminal será aberto
e você verá

que ele é bem semelhante
ao do Windows.

Vamos começar usando o comando
"git status",

que é o comando
que nós usamos do Git

para ver como o repositório atual
está se comportando.

Repare que nós recebemos
um erro.

Isso acontece porque trata-se
apenas de uma pasta comum,

não é um repositório do Git.

Para que essa pasta vire de fato
um repositório

e a gente possa personalizar arquivos.

Nós precisamos usar o comando
"git init".

Vamos executar
para ver o que acontece.

Executando o comando "git, init",
nós temos uma mensagem

de que um novo repositório vazio
foi inicializado nesse diretório

e veja que interessante.

Se nós voltarmos aqui
no Windows Explorer,

nós veremos
que tem uma nova pasta

que a gente não criou,
a ".git".

Essa pasta ela é uma pasta oculta

e talvez não apareça
no Windows Explorer,

mas nós conseguimos acessá-la
através do terminal do Git Bash.

Veja só como.

Voltando aqui,
nós conseguimos usar o comando "ls"

que serve para listarmos os arquivos
de um diretório atual.

Só que novamente,
quando a gente executa,

não tem nada,
porque aquela pasta é oculta.

Se nós quisermos usar o comando "ls"
para listar os arquivos ocultos,

nós precisamos passar a flag "LA"
no final do comando.

Veja só.

"ls -la".

E agora sim,
a gente consegue ver a pasta Git.

Ter uma pasta git
dentro de uma pasta

indica basicamente que aquela pasta
se trata de um repositório.

Se você tem o repositório
e a pasta git não está lá,

provavelmente tem algo errado.

E é muito importante que você
não apague essa pasta por acidente.

Se você fizer isso,
perderá todo o track de histórico

que você tem naquela aplicação.

Então, vamos lá.

Agora que temos
um repositório em mãos,

vamos usar o comando "clear"
e adicionar o nosso primeiro arquivo.

Vamos usar o próprio terminal

para criar um arquivo chamado página
ponto. TXT.

Será apenas um arquivo de texto,

mas vamos simular uma criação
de uma página de verdade.

Então vamos escrever o comando
touch página ponto.

TXT Se voltarmos no Windows Explorer
nós veremos que o arquivo foi

criado, então vamos usar o Notepad

para colocar algum conteúdo lá
dentro.

Eu vou vir aqui e vou colocar
minha página e salvar esse arquivo.

A partir desse momento,
um arquivo novo foi criado, então

eu posso usar o comando git status
para entender o que mudou aqui

dentro do meu repositório de status
eu consigo ter algumas informações.

Repare aqui

que eu ainda não tenho nenhum
commit, ou seja,

o meu repositório está vazio

e não há nenhum histórico
antes do momento atual.

E aqui
eu tenho a sessão de extract files

e dentro dela em vermelho
eu tenho o arquivo página txt

que eu acabei de criar.

Isso significa que o Git entendeu
que um novo arquivo apareceu aqui,

mas ele ainda não fará nada
a respeito desse arquivo.

A gente comentou que existem pontos
na história que são commits

e são eles que de fato
marcam as alterações que eu fiz

ao longo do tempo.

Mas para que eu consiga adicionar
esse arquivo

e a minha alteração
dentro de um novo commit,

eu preciso mover esse arquivo
para um outro estado chamado extend.

E para fazer isso
a gente usa o comando git.

Vamos ver.

Vamos usar o comando git dd
informar o caminho do nosso arquivo

página em txt para que ele entre
nesse novo estado,

então add página ponto txt.

Pronto,

Não temos nenhum feedback visual,

mas se nós executarmos o comando
git status

para entender o que mudou,
nós veremos algo interessante

o Git status.

Vemos que dessa vez
a gente ainda não tem nenhum commit,

mas o nosso arquivo página ponto txt
está em verde

e o git já o identificou
como um novo arquivo.

A partir desse momento

nós conseguimos

criar o nosso primeiro commit
descrevendo o que a gente fez aqui.

Como nessa
nossa primeira implementação,

nós basicamente adicionamos uma
página, digamos, a página principal.

É isso que nós colocaremos
como descrição no nosso convite.

E para de fato fazer o commit,
vamos usar o comando git commit

e essa mensagem vem no parâmetro
traço m.

Vamos ver git commit traço m

adicionando página principal

e assim que eu dei enter,
o git dessa vez retorna

um feedback visual para a gente,
informando algumas coisas.

A primeira delas é a branch
em que eu estou.

Falaremos mais sobre isso no futuro.

Um reach, que é o ID único
desse commit ao longo do tempo

e a minha informação,
a minha descrição que eu associei

com esse commit, ou seja,

uma descrição breve do que
eu implementei naquela mudança.

E aqui embaixo nós conseguimos ver
também os arquivos

que foram alterados que compõe
de fato esse ponto na história.

Então, se nós limparmos o terminal
e executarmos novamente

o Git status,

nós veremos que não tem
nada de modificado

dentro da nossa work tree
ou da nossa árvore de trabalho.

O que vamos fazer agora é entender

como nós conseguimos ver o conteúdo
que compõe uma alteração atual.

Ou seja, imagine que nós estamos
adicionando uma nova funcionalidade,

como por exemplo,
um carrinho de compras.

Imagine que antes de de fato
criar o commit e registrar

as minhas alterações na linha
do tempo do meu repositório,

eu deseje entender

os arquivos que foram alterados
ou, por exemplo, o conteúdo deles.

Vamos ver como a gente
consegue fazer isso agora dessa vez.

Então vamos usar o Windows Explorer

para criar um novo arquivo
chamado carrinho ponto txt.

A ideia é a mesma.

Vamos usar aqui
o botão direito novo carrinho

e dessa vez vamos editar aqui
o conteúdo do arquivo para conter

meu carrinho de compras.

Repare que o arquivo foi salvo.

Eu posso fechar

e novamente
voltar para o meu terminal

para poder executar
os comandos do Git

executando o Git status.

Eu consigo ver que o arquivo
carrinho txt foi adicionado,

mas ele ainda não está
no controle de versão do Git,

Então vamos usar o comando git added
para que o Git consiga ler

as mudanças que eu fiz
nesse arquivo.

Vamos lá.

Git add carrinho
como txt Vamos limpar o terminal

e usar o git log para recuperar
o histórico de commits.

Repare aqui nós temos o nome
de quem fez esse commit, o email,

a data em que esse convite aconteceu
e a descrição que eu coloquei.

Mas também muito importante.

A gente tem um REACH
que é um código único

gerado para cada commit
ao longo do tempo.

Com esse hash
nós conseguimos fazer várias

operações, como por exemplo
voltar no tempo para ver o conteúdo

que estava naquela época
e entre outras tarefas.

Nessa vez a gente vai usar esse REST
para comparar o que mudou dele

com o código que nós temos
atualmente no nosso repositório.

E para fazer isso
a gente usa o comando git diff.

Vamos ver como isso funciona.

Vamos executar o comando git diff
e informar o resto do commit

anterior que a gente fez,

Então eu vou vir aqui em cima copiar
e então colar É diferente.

Pronto,
agora nós temos um resumo bem claro,

tanto dos arquivos
que foram alterados,

mas dos conteúdos novos
que foram adicionados nele.

E a partir desse momento,
se nós estivermos de acordo,

podemos fazer um novo commit
e enfim colocar essa nossa alteração

dentro do histórico.

Vamos então escrever novamente
um convite,

só que com uma outra mensagem
informando que o carrinho de compra

está sendo adicionado.

Então para isso git commit

traço m

Adicionando carrinho de compras

e pronto.

Se nós executarmos o git status
mais uma vez

veremos que a nossa árvore
de trabalho está limpa

e executando o git log.

Nós conseguimos ver que agora
há dois commits no nosso histórico.

O primeiro
adicionando a página inicial

e o segundo
adicionando o carrinho de compras.

Incrível, não é mesmo?

A gente acabou de ver
como podemos usar o Git para de fato

criar um versionamento semântico
para o nosso repositório

e acompanhar ao longo do tempo
que foi alterado.

Então, a partir de agora você
não precisa mais recorrer a criar

V1, V2

ou qualquer outra estratégia
mirabolante

para fazer um controle de versão

e entender de forma clara
o que foi alterado no seu projeto.