Solucionado (ver solução)
Solucionado
(ver solução)
5
respostas

Criando Tag em um projeto com vários arquivos

Aqui no fórum tem uma dúvida sobre o motivo de realizar um git push tanto do repositório quanto da tag separadamente. Eu também estava com essa dúvida e a conclusão que cheguei com a resposta do outro tópico é que a tag é um pacote do nosso projeto completo zippado mesmo.

Então, quando estamos em um projeto com vários arquivos envolvidos (exemplo, criando um site com arquivo html, css, js...) me parece que quando dermos o comando tag será criado um pacote de todos esses nossos arquivos... isso está certo? (Imaginar a tag como um pacote de lançamento do produto)

5 respostas

Olá, Julia. Tudo bem?

Tags são referências para pontos específicos na linha do tempo do Git. Elas são usadas para capturar um ponto na história do projeto que é usado para marcar uma versão de lançamento, ou release.

Se você estiver desenvolvendo um projeto e ele estiver parcialmente completo, você realiza o commit referente à ultima alteração e pode marcar que foi esse commit que finalizou a primeira versão da sua aplicação. Então você prepara a aplicação para ser entregue.

O git tag não gera um zip dos arquivos do projeto, quem faz isso é o Github, quando enviamos a tag com o push. Isso é feito para facilitar a entrega das versões. Essa funcionalidade nem sempre esteve disponível dessa forma, sendo que seria necessário que você fizesse a preparação para entregar os arquivos por conta própria.

Espero ter ajudado.

Acho que o que eu estou com dificuldade de compreender é que o commit a gente dá para cada arquivo, então quando mexermos no index.html, damos um commit nele, quando mexermos no style.css damos um commit nele.

Por sua vez com a tag a gente vai estabelecer uma versão para o projeto como um todo né? todos os arquivos que estiverem naquele repositório farão parte da tag? Fazendo uma comparação bastante simplista podemos dizer que o ponto de restauração do Windows é como se fosse uma tag?

solução!

Oi, Julia.

A tag, em si, é só um apelido para um determinado commit no seu repositório. Os commits criam um ponto na linha do tempo do seu projeto. Iniciamos somente com o index.html e fizemos o commit para criar um ponto na nossa linha do tempo. Depois adicionamos o style.css e damos outro commit para marcar outro ponto. Assim a gente consegue saber o que aconteceu em cada momento no projeto, correto?

Digamos que agora que temos o style.css decidimos que temos o suficiente para entregar uma versão inicial do projeto. A gente poderia copiar os 2 arquivos para o cliente e entregar. Mas como a gente pode saber, futuramente, em qual ponto foi que terminamos aquela primeira versão? Temos vários commits e não temos como ter certeza. Podemos criar um apelido para aquele commit que originou a primeira versão. A tag vai ser um identificador, um rótulo ( que é a tradução direta de tag), para esse commit.

Dito isso, acho que essa analogia com o ponto de restauração do windows faz sentido. Tinhamos nossa máquina num estado. Instalamos um programa e queremos ter um ponto para que possamos voltar para o estado em que o computador estava depois dessa instalação.

Espero ter deixado mais claro. Se tiver continuado com dúvidas, é só dizer.

Vitor, você explicou muito muito muito bem, realmente o commit não damos em um arquivo especifico, me confundi completamente, e agora com a analogia do ponto de restauração ficou realmente muito mais claro o funcionamento de tudo. Eu agradeço demais pela paciência :))

Oi, Julia.

Fico contente que tenha te ajudado. Não exigiu muito da minha paciência, não! Inclusive, a sua analogia ajudou a concretizar melhor as coisas pra mim também!

Bons estudos e, se precisar, estamos aqui!