Inicio en GIT

Unha longa introducción ao uso básico de GIT cómo crear, modificar, subir e descargar repositorios, así como ver os logs dos mesmos.

Que é GIT

A explicación longa lla deixo a wikipedia, básicamente é un VCS (Version Control System) un software para o control de versións de código, que nos permite conservar cambios e desfacer cambios no código, así como acceder a estados anteriores de código indo a un cambio determinado, consultar anotacións sobre dito cambio e moitas máis cousas.

GIT gañou en eficiencia, potencia e versatilidade a outros VCS antes da extensión de git o máis común era “Subversion”.

Broma do sector: Sabes que estás a tratar con software obsoleto cando o seu código todavía está versionado con Subversion.

En git está ben visto ir facendo os commits “pequenos”, se o que estamos a desenrolar inda non está usable o seu é crear unha nova rama “branch” e ir gardando nela os cambios, unha vez xa teñamos esa parte do código funcional se pode agregar “mergear” ou “facer merge” a rama principal que soe chamarse “main”.

Todo depende de como se organice a xente do proxecto git ofrece dende funcións básicas a outras moi avanzadas, cuestión do proxecto decidir de cales facemos uso.

Cómo traballa GIT

GIT non garda cambios incrementais dos seus repositorios, garda imaxes completas do seu directorio coma si fora un sistema de arquivos, dos cales garda unha copia dos ficheiros modificados e un enlace aos ficheiros que non se modificaron, esto fai que aforre moito espazo en disco.

Os tres estados, clave para entender git

A “clave” para entendela base de traballo de GIT, son os 3 estados que acadan os ficheiros no seu sistema de seguimento:

Estado:	Explicación:
Modified	Modificado con respecto a última versión do repositorio.
Staged	Sinadalo para ser aplicado ao repositorio.
Commited	Aplicado o ficheiro modificado ao repositorio.

Logo estaría un 4º estado básico que sería “unmodified” “sen modificar”.

Os unmodified, xa serían os máis básicos da imaxen do repositorio, esos que en sucesivas imaxes do mesmo (“snapshots”) son enlaces.

Rutas dos arquivos de configuración de GIT

A configuración xeral ou de cada repositorio individual se modifica a través de “git config”.

Este pode almacenala información sobre entorno onde se executa GIT nos 3 lugares seguintes:

Ruta:	Explicación:
`/etc/gitconfig`	Contén os valores para cada usuario no sistema e tódolos seus repositorios. Se pasas a opción “`--system`” a “`git config`” escribirá e cargará a configuración deste ficheiro.
`~/.gitconfig` ou `~/.config/git/config`	É específico de cada usuario, para este ficheiro hai que pasala opción “`--global`”.
`.git/config`	Este ficheiro de configuración está en cada repositorio, serve para aplicala configuración directamente ao repositorio sen afectar ao resto.

Identificarnos con nome e email

Para saber quén fai os commits, hai que configurar un nome de usuario e un correo electrónico.

Para configuralo usamos “git config” user.name e user.email:

git config user.name  <nome>
git config user.email <email>

Se engadimos “--global” esta configuración se gardará para tódolos aportes que fagamos en tódolos proxectos.

Se facemos “git config” sen o argumento “--global” , configurará o perfil para o proxecto seleccionado.

Editor de texto por defecto

Se non se configura usará o do sistema, mais se pode indicar a git qué editor usar para cando faga falta editar cousas en GIT.

Establecer vim como editor por defecto:

git config --global core.editor vim

Listalas configuracións

Útil para ver que configuracións están a coller os comandos git que fagamos.

Para listalas usamos:

git config --list

Atopar axuda e manuais sobre parámetros git

Ás veces no man se atopa documentación sobre determinados comandos git, outras veremos que está mellor explicado na propia axuda do git ou ben que esta redirixe ao man en cuestión.

Para atopar axuda sobre un parámetro de GIT:

git help <parámetro>

Xestión básica de repositorios

A parte común que utiliza todo novato e experto, os comandos do “día a día” que tamén son executados polo software de terceiros que ofreza ás opcións dunha maneira gráfica.

Inicializar un repositorio nun directorio existente

Úsase git init, para iniciar o proxecto no directorio:

git init

Crea un directorio chamado “.git” que é onde se gardará tódala configuración do repo GIT así como os seus obxetos.

AVISO: Se eliminas este directorio eliminas TODO o repositorio e configuración personalizada para o proxecto, so o podrás recuperar se tes backups ou publicache os cambios nun repositorio remoto.

Inicialo seguimento dos ficheiros (preparar un commit)

Os ficheiros que todavía non están seguidos polo git no seu repositorio, non se engaden por defecto. Hai que indicarlle a git que lles faga seguemento a primeira vez.

Para engadilos ficheiros dos que queremos facer un seguimento facemos:

git add <nome_ficheiro_ou_ficheiros>

Gardar os cambios no repositorio

Cada ficheiro no teu directorio de traballo pode ter 2 estados dende o punto de vista do seguemento por parte de git:

tracked
untracked

Tracked: Seguido/Supervisado por git.
Untracked: Sen seguimento/Sen supervision por parte de git.

Nome:	Descripción:
tracked	Os ficheiros xa agregados na última imaxen de estado do repo “snapshot”, vamos os máis recentes dentro do repositorio, dentro do repositorio teñen algún dos estados xa mencionados: - “unmodified”. - “modified”. - “staged”.
untracked	Son aqueles que pertencen a antigas imaxes de estado “snapshots”. Non están na última snapshot do repositorio e tampouco están na coñecida coma “staging area”, que é a onde irían en caso de ser sinalados como “staged” para ir formar parte da próxima aplicación “commit” ao repositorio

Cando rematas de clonar un repositorio, tódolos ficheiros que descargache pasan de ser “tracked” (Seguidos) a “unmodified” (Sen modificar) debido a que non están modificados e os acabas de clonar dunha versión do repositorio que xa estaba aplicada “commited” (ou “comiteada”).

Unha vez modifiques algún ficheiro, GIT o verá cómo modificado por que mudou dende o último commit, podes agregalo (poñer a “staged” os ficheiros) e logo aplicar os cambios (facer un commit) de estos ficheiros ao repositorio local ou remoto, a partir de ahí o ciclo se repite mentres vas denvolvendo a túa aplicación.

Comprobar o estado dos ficheiros

Unha das accións máis repetidas, xa que nos da información sobre ás diferenzas entre os nosos ficheiros no disco con respecto aos que están na imaxen “snapshot” actual do repo git.

Para ver en qué estado se atopan os ficheiros do repositorio:

git status

Nos devolverá a información acerca do estado da nosa imaxen local “snapshot local” dos ficheiros do repositorio.

Exemplo de git status

Creamos un directorio e dentro deste un ficheiro de texto.

Así é cómo se ve co git status, o novo directorio se ve que non está sendo seguido polo git “untracked”, git informa de que non está sendo seguido:

git status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)

        DIRECTORIO_UN/

nothing added to commit but untracked files present (use "git add" to track)

Agora se engadimos o directorio con “`git add`” e facemos “`git status`” veremos cómo informa de o está a seguir “tracked” e que as mudanzas van ser aplicadas “committed” a próxima vez que fagamos commit:

$git add DIRECTORIO_UN
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        new file:   DIRECTORIO_UN/pepito.txt

GIT recorre o directorio na procura de ficheiros que estén debaixo del, polo que atopou o ficheiro de texto que metín no directorio.

Entonces desta maneira, GIT non engade ficheiros que ti non queiras engadir ao repositorio, salvo que os engadas explícitamente ou incluas os seus directorios superiores.

Noutra sección deste artigo indico como omitir ou deixar de seguir ficheiros e directorios.

Ver un resumo de `git status`, usamos `-s` ou `--short`:

git status -s
A  DIRECTORIO_UN/pepito.txt

Amosará só dúas columnas, para máis información consultar a axuda de git con:

git help status

Ignorando ficheiros en GIT usando gitignore

Esto é moi importante, xa que se queremos evitar que ficheiros ou directorios do noso proxecto como por exemplo:

ficheiros con contrasináis.
binarios resultantes da compilación do código.
Configuracións do IDE que usemos (como o directoiro .vscode).
Arquivos temporais, cachés e demáis “lixo”.

Sexan engadidos ao repositorio, debemos crear un ficheiro co nome exacto .gitignore o cal deberá conter patróns de nomes de ficheiros que queremos que GIT ignore.

Por exemplo no `.gitignore` podriamos poñelo seguinte, sendo un patrón por liña:

# Unha liña de comentario.
*~            # ficheiros backup
*.tmp         # ficheiros temporáis
*.[oa]        # terminados en "o" ou "a".
*.log         # Os logs
# Resulta que si nos interesa engadir os arquivos update.log,
# con "!" negamos que ignore os ficheiros con ese nome:
!update.log

No exemplo ignoramos os ficheiros de backup (rematados en “~”), os que sexan temporais “.tmp” e aqueles con extensión “o” ou “a”.

As liñas en branco ou as que comecen por cancelo son ignoradas ao igual que os comentarios como os usados no exemplo anterior.

Pódense utilizar expresións regulares.

Coa exclamación ao principio da liña, conseguimos que se negue o ignorar os nomes que coincidan co patrón dado. Esto serve por exemplo para ignorar tódolos logs, salvo os de update (por se resulta útil aportalo ao repositorio, normalmente non soe ser útil).

Para ver máis exemplos podes ir a seguinte dirección onde crearon diferentes .gitignore para os diferentes tipos de proxectos máis comúns:

https://github.com/github/gitignore

Comprobando diferencias en GIT

Con git status podiamos ver qué ficheiros estaban modificados con respecto a imaxen do repositorio, ou qué ficheiros non estaban marcados para ser aplicados ao mesmo.

Con git diff podemos ver que diferenzas teñen a nivel de código, útil para leer que código se modificou.

Para velas diferencias destos ficheiros, usamos git diff:

git diff

Para velas diferenzas dos ficheiros marcados para aplicar ao repositorio (staged para “comitear” ao repositorio), usamos o parámetro “`--staged`” con `git diff`:

git diff --staged

Exemplo diferenzas entre “`git diff`” e “`git diff --staged`”:

git diff
$ echo "ola1!" > proba1.txt
$ git diff
$ git diff --staged
$ git status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)

        proba1.txt

nothing added to commit but untracked files present (use "git add" to track)

$ git add proba1.txt
$ git diff
$ git diff --staged
diff --git a/proba1.txt b/proba1.txt
new file mode 100644
index 0000000..25a108e
--- /dev/null
+++ b/proba1.txt
@@ -0,0 +1 @@
+ola1!

Número liña:	Explicación:
1	Se fai un “`git diff`” sen cambios, se ve que non indica nada.
2	Creo un arquivo novo para á proba.
3	Fago “`git diff`” e como o arquivo non está no repo, non indica nada.
4	Fago “`git diff --staged`” e como non está marcado o ficheiro, non indica nada.
5	Consulto o estado actual do repositorio.
6-13	Git me informa de que hai ficheiros novos que non están sendo seguidos.
14	Engado o ficheiro “`proba1.txt`” para ser seguido por git.
15	Executo só “`git diff`” como non está no repo, non me devolve nada indicado que non hai cambios con respecto ao que ten no repo.
16-23	“`git diff --staged`” me indica que os cambios do ficheiro actual con respecto ao que ten no repo (nada = null), como o ficheiro é novo para o repo, pasaría de estar a “null” ao contido do mesmo.
20	Indica co apuntamento ao binario “`/dev/null`” que non había unha versión do ficheiro no repo.
21	Indica que se vai a engadir o ficheiro con “`+++`”.
23	Co + nos indica que se vai a engadir dita liña (a única que contén o ficheiro de exemplo, se non habería moitas máis precedidas por +).

Se pode ver que se non marcamos para aplicalo “comitealo” ao repositorio, con git add non o veriamos, nen se quera veriamolo ficheiro en si (por iso é importante facer git add na raíz do proxecto e co .gitignore evitaremos que se suban ficheiros delicados). Unha vez marcado para ser aplicado o veremos co “--staged”.

“Comitear” ou aplicalas mudanzas a un repositorio ou “facer commit”

A acción de “commit” básicamente é “aplicalas mudanzas” ao repositorio, tamén se coñece en xerga informática como “comitear” ou “facer commit”.

Para facer un commit hai que usar:

git commit

Con isto saltará o noso editor favorito ou o de por defecto, no que se amosarán as mudanzas que se realizarán no repositorio.

Todo o que esté comentado con cancelos “#” será ignorado, o resto será engadido coma mensaxe do commit.

Unha recomendación é facer commits por cada pequena mudanza e co seu correspondente mensaxe breve que describa a mudanza.

“Broma do sector”: Os commits non son concursos literarios, para iso está a documentación…

De tódolos xeitos para ser máis rápido aplicando as mudanzas (comiteando), se pode usar “`-m`”, da seguinte maneira:

git commit -m "Descripción do commit"

Engadindo automáticamente novos ficheiros ao commit

Para engadilos novos ficheiros creados (e parece ser que non directorios) se pon “-a” para automatizar isto. GIT procurará nos subdirectorios todo ficheiro modificado que non esté ignorado e o agregará.

git commit -a -m "mensaje"

Para borrar ficheiros ou directorios dun repositorio

En principio se borramos algún ficheiro, logo ao realizar o seguinte commit estos ficheiros serán eliminados da nova imaxen “snapshot” (o seu enlace non será copiado na nova imaxen de estado “snapshot” nin nas sucesivas) do proxecto.

Eliminar realmente un ficheiro de todo o repositorio

+info: Doc oficial git-rm

Se queremos eliminar un ficheiro do repositorio podemos usar git rm:

git rm <nome_ficheiro>

Logo nos quedaría aplicalas mudanzas con “git commit”.

Se queremos eliminar directorios, engadimos “-r”:

git rm -r <directorio>

Logs

Como git é un software de seguimento de cambios, os logs son parte indispensable do mesmo xa que podremos leer a descripción de tódolos cambios que se foron facendo, por iso é importante comitear con mensaxes breves e concisas o cal inclue ir comiteando pequenos cambios en lugar de un gran cambio.

Ver o historial da aplicación de mudanzas no repositorio (log de commits)

Para velo historial de mudanzas nun repositorio, usamos “git log”:

git log

Onde se verán as mudanzas da máis recente a máis antiga.

Con `-p`podrás velas diferencias das mudanzas entre versións, se engadimos `-2` nos limitaremos as 2 últimas aplicacións de mudanzas no repositorio “commits”:

git log -p -2

Con --stat podremos ver qué modificacións se fixeron en cada commit.

Se engadimos “--pretty=” veremos unha vista máis compacta do log.

Con “--pretty=oneline” veremos cada commit co seu comentario dunha maneira compacta.

Dar formato a saida con git log –pretty

Se logo queremos parsear ou manipulalos logs con outras aplicacións, podremos xerar unha saida persoalizada con --prety:format:<formato>”.

Exemplo git log `--pretty=format:<formato">` :

git log --pretty=format:"<formato>"

Este formato funciona como o faría no comando date, estas serían as opcións:

Opción:	Explicación:
%H	hash do commit
%h	hash abreviado do commit
%T	hash do árbore de directorios
%t	hash abreviado do árbore de directorios
%P	hash dos pais
%p	hash abreviado dos pais
%an	Nome do/a autor/a do repo
%ae	Email do/a autor/a do repo
%ad	Data creación do repo, segue o formato de –date=opción
%ar	Data creación do repo, relativa.
%cn	Nome de quen realizou o commit.
%ce	Email de quen realizou o commit.
%cd	Data de quen realizou o commit.
%cr	Data relativa de quen realizou o commit.
%s	Mensaxe do commit

Buscar nos logs

Opcións para buscar nos logs

Estas serían as opcións para buscar nos logs:

Opción:	Explicación:
-`<número>`	Ver ata `<número>` dende o último commit.
–since, –after	Limita a vista de commits, aos realizados despóis da data indicada.
–until, –before	Amosa os commits realizados antes da data indicada.
–author	Amosa os commits que realizou un/ha determinad@ autor/a.
–committer	Amosa os commits que realizou un/a determinad@ colaborador/a.
–grep	Amosa só os commits que conteñan un mensaxe determinado.
-S	Amosa os commits que haxan eliminado ou inserido no código indicado.

Podes mudar estos parámetros para afinalas túas búsquedas nos logs do repositorio.

Ver demaneira “gráfica” con liñas os commits nos diferentes branch do proxecto

Esta opción visual é moi útil para ver puntos por cada commit existente no repositorio, e estos van unidos ao seguinte commit cunha liña o cal da como resultado a representación dun resumo do estado do repositorio a nivel visual fácil de seguir.

Máis información na documentación oficial.

Para velas diferentes liñas de aplicacións de mudanzas ao repositorio, podemos usar -graph:

git log --graph

Velos commits realizados dende unha época definida, podemos usar –since`<número>.<unidade_tempo_en_inglés>`:

git log --since=2.days

Xestión algo máis avanzada de repositorios

A esta sección lle chamei así por que soen ser cousas que apenas se usan, git ten moitas opcións que a gran maioría de usuarios non van requerir de usar. Por eso digo “máis avanzada” xa que a xestión avanzada de git é algo que a min se me escapa e tamén queda lonxe de un artigo sobre “inicio en git”.

Eliminar commits xa existentes no repositorio

Esta é a parte “delicada” de GIT, onde podrás perder parte do teu traballo se manipulas mal estos comandos, VAI CON COIDADO.

Ante a dúbida sempre está a documentación oficial sobre git rm.

Editalo teu último commit (“correxir o commit enmendándono”)

Exemplo de uso:

“Fixen git commit e resulta que faltaba x ficheiro, cambio ou a descripción a quero mudar sen facer un novo commit.”

Resumen: “git commit -–amend” Edita o último commit.

Se acabas de realizar un commit, e puxeche mal a mensaxe do commit ou te olvidache de algún ficheiro, ou algo polo estilo… podes usar a opción --amend (enmendar).

Uso:

git commit --amend

Se eliminas un ficheiro do directorio de traballo e queres que tamén se elimine no último commit, has de facer:

git rm <nome_ficheiro>

Quitar un ficheiro do próximo commit (Que pase de staged a unstaged)

Termos:

staged : Ficheiro preparado para ser comiteado.

unstaged : Ficheiro non preparado para ser comiteado, falta que o humán o revise e/ou marque como stagged.

Suponte que por exemplo fas un git add de todo un directorio, mais un ficheiro non queres engadilo ao commit por algún motivo.

Reiniciar o estado dun ficheiro para que non sexa aplicado no seguinte commit

Esto só muda o estado en git, non altera o ficheiro físico.

O podes facer con GIT reset HEAD:

git reset HEAD <nome_fichero>

Reinicialo seu estado indicado no último estado “HEAD”.

Desta maneira afectas a selección actual de estar marcado como “staged” ou non marcado “unstaged”.

Restaurar ficheiro físico con checkout

Desfacela última mudanza sobre un ficheiro (checkout)

Para recuperar o estado dun ficheiro a cómo estaba na última versión aplicada ao repositorio “comiteada”.

ALTERA O FICHEIRO FÍSICO xa que se perderán os cambios non comiteados do ficheiro físico e que quede coma estaba no último commit.

Podemos usar o “checkout”:

git checkout -- <nome_ficheiro>

Para recuperalas últimas mudanzas que fixeche, en principio non se pode (salvo tirar de backups, file recoveries, etc…)

Para evitar a pérdida, deberías de haber creado un branch (ramificación do repositorio), mudarte a ese branch e facer commit nese branch así logo se realmente querías esos cambios os podes “merxear” no branch main ou no que estés a traballar.

Traballar con repositorio remotos

Git pode funcionar perfectamente en local tendo so o seu directorio .git na raíz do teu proxecto, engadir un repositorio externo básicamente garante redundancia do código, centralización de esforzos / colaboración, publicación do mesmo para acceso por terceiras persoas.

Tamén cando clonamos un proxecto esta copia vai ter como repositorio remoto a orixe dende a que o clonamos.

Clonar un repositorio

Unha das accións máis básicas e utilizadas cando se traballa con git, básicamente é coma se che enviaran o directorio .git e logo se procesara no teu equipo local para rexerar tódolos ficheiros, podrás traballar no proxecto clonado e ata enviar os cambios ao repositorio de orixe.

Usamos git clone:

git clone https://github.com/libgit2/libgit2 <Opcional_nome_directorio_novo>

Listar os repositorios remotos dun proxecto (remote)

Se temos un repositorio clonado ou queremos ver se é clonado, podemos usar “git remote”.

Usado nun directorio local non clonado, non amosará saida algunha, se é clonado nos amosará “origin” o alias por defecto que lle dará a url remota de orixe.

Listar os repos remotos:

git remote

Se queremos velas urls dos repos dos colaboradores ou a orixinal:

git remote -v

Engadir un repositorio remoto ao proxecto con git remote add

Para engadila url do repositorio remoto:

git remote add <alias_repositorio> <url>

Exemplo `git remote add`:

git remote add repo_de_paquito https://github.com/paquito/oproxecto

Agora co nome engadido podemos referirnos a esa url por dito nome.

Descargalos datos dos repositorios remotos con git fetch

Se queremos consultar se actualizaron o repositorio remoto ou básicamente actualizar a nosa copia do repositorio coas actualizacións do remoto entonces facemos “git fetch”.

Pódese descargalos datos destos repositorios remotos con:

git fetch <alias_repositorio>

Enviar unha copia do teu repositorio a un remoto con `git push`

Cando usamos git push estamos a tratar de enviar os nosos cambios comiteados no repositorio local aos remotos ou remoto se definimos un específicio. Dependendo da configuración do repositorio remoto poden aceptar os cambios sen máis ou bloquear os aportes externos.

Enviar unha copia local a tódolos repositorios remotos e tan simple como non indicar un en específico:

git push

Enviar unha copia local a un repositorio remoto específico:

git push <nome_servidor_remoto> <nome_branch>

Se por exemplo queres enviar a copia da túa versión master do repositorio local, onde “origin” é o nome dado ao repositorio remoto:

git push origin master

Tags (Etiquetas)

En moitos CVS (Concurrent Version System), acostuman a etiquetalos aportes con respecto as súas versións xa sexa o lanzamento dunha beta, dun v1.0 ou calquer outro elemento que o os seus desenroladores consideren importante, as etiquetas serven básicamente para iso.

Consultalos tags dun repositorio

Os tags (etiquetas) non son máis que un sistema para destacar determinados commits sobre o resto, o cal axuda a organización do proxecto.

Son ás que permiten cousas como indicar que versión do estado do proxecto é estable ou beta.

Para velas etiquetas dun repositorio:

git tag

Crear tags

Tipos de tags

GIT usa dóus tipos de etiquetas:

lightweight.
annotated.

Nome:	Descripción:
lightweight	É máis coma un branch que non muda, apunta a un commit específico.
Annnotated	Garda tódolos obxetos nunha base de datos GIT, a estos se lles realiza unha función resumo “HASH”. A etiqueta contén: - A etiqueta co nome, email e data do creador. - Unha mensaxe da etiqueta. - Poden ser asinadas e verificadas con chaves GPG.

Polo xeral é recomendable ir creando etiquetas annotated, que conteñen a información do repositorio cando o proxecto vai alcanzando unhas funcionalidades determinadas.

Mais se por algún motivo precisamos deixar unha anotación no repositorio, podemos facer uso das etiquetas lightweight.

Tags annotated

Para crear unha etiqueta annotated, hai que engadir “-a” cando se executa o comando tag:

git tag -a v1.2 -m "New version 1.2"

Tags lightweight

Unha lightweight non é máis que o checksum do commit almacenado nun ficheiro.

Para crealas non hai que engadir “-a, -s ou -m”:

git tag v1.3-lw

Consultar un tag específico

Ponse “git show `<tag>`”:

git show v1.3-lw

Isto nos amosaría a información do commit, os cambios que se fixeron, autor, ficheiros modificados, etc…

Básicamente, os tags veñen sendo como “apodos” de determinados commits (por iso se poñen cando se remata algunhas funcións cruciais do noso proxecto), e son máis doadas de lembrar que unhas datas ou a orde na que está o commit, polo que os fai máis accesibles.

Etiquetar “Taguear” un commit antigo

Para etiquetar un commit antigo, has de executalo comando tag da maneira habitual, só que engadindo ao final do comando todo ou parte do inicio do hash, para que poida atopar o commit a etiquetar.

Exemplo:

git tag -a <etiqueta_do_commit> <checksum_ou_parte_do_checksum>

Compartir etiquetas ou “pushear tags”

Normalmente por defecto o comando push de GIT non comparte as etiquetas entre os servidores.

Se tes que enviar etiquetas a un servidor determinado logo de habelas creado, tes que envialas explícitamente ao servidor destino.

Este proceso sería cómo compartir branchs remotos.

Enviar unha etiqueta has de mencionar o repo remoto seguido do nome da etiqueta:

git push origin <etiqueta>

Enviar tódalas etiquetas a un repo remoto:

git push origin --tags

Usar alias praos comandos GIT

Para facer comandos que repetimos no día a día (e poden ser algo longos de escribir), a maneira máis breve sería usar un alias como o que usariamos nunha terminal GNU/Linux.

Para usalos poñemos o seguinte:

git config --global alias.<o_alias> <o_comando_git>

E con isto remata a introducción a git, agoramesmo xa podes crear o teu propio repositorio, engadirlle ficheiros e directorios, ademáis de poder engadir repositorios remotos e de aplicar as túas mudanzas a outros repositorios.

Para máis detalles sempre é bo consultar ás documentacións oficiáis que reinventalas rodas:

https://git-scm.com/docs

Tamén dispoñen de cheat sheets, que básicamente son resumos que conteñen o máis utilizado: https://training.github.com/