Notas rápidas Git - GitHub
Tags: git, webdev, tutorial, spanish
Published: 2023-02-16 10:32:51

## :checkered_flag: TABLA DE CONTENIDO :checkered_flag:

- [Idea de este post](#idea-de-este-post)
- [Configuracion inicial](#configuracion-inicial)
- [Comandos unix relevantes](#comandos-unix-relevantes)
- [Git ignore](#git-ignore)
- [README.md](#readmemd)
- [Atajos y soluciones](#atajos-y-soluciones)
- [Inicializar un repositorio](#inicializar-un-repositorio)
- [Manejo del staging area](#manejo-del-staging-area)
- [Git commit](#git-commit)
  * [Comandos avanzados para commit](#comandos-avanzados-para-commit)
    + [Comandos avanzados de sobreescritura](#comandos-avanzados-de-sobreescritura)
- [Git tag o Etiquetas](#git-tag-o-etiquetas)
- [Git log](#git-log)
- [Ramas](#ramas)
- [Git merge o fusiones](#git-merge-o-fusiones)
  * [Algunos conflictos con merge](#algunos-conflictos-con-merge)
- [Git rebase](#git-rebase)
- [Git stash](#git-stash)
- [Git clean](#git-clean)
- [Git cherry pick](#git-cherry-pick)
- [Git Reset y Reflog](#git-reset-y-reflog)
- [Git grep](#git-grep)
- [Comandos para lider de equipo de desarrollo o scrum](#comandos-para-lider-de-equipo-de-desarrollo-o-scrum)
- [Git alias](#git-alias)
- [GitHub](#github)
  * [Inicializar un repositorio local y en github vacio](#inicializar-un-repositorio-local-y-en-github-vacio)



***
  
## Idea de este post

Este post está pensado para personas que les gusta aprender de una forma rápida o simplemente quieres tener como desarrollador a la mano una guía simple y sencilla de los comandos y soluciones de Git y GitHub.

Como desarrollador uso Windows, así que los comandos están enfocados a este sistema operativo.

Es una guía completa de comandos básicos y avanzados que he aprendido y usado, creo que son los más relevantes para la solución inmediata del entorno de trabajo personal y en equipo

Si te deseas que añada algun otro comando o resolviste algun problema en tu trabajo y no esta esa solucion aqui puedes enviarla con capturas de pantalla [a mi correo](https://linktr.ee/oswaldoecheverria) con tus datos de contacto para agregarlas otorgandote el respectivo credito 


***
## Configuracion inicial 

* Comandos para saber la configuración actual de Git 
```sh
git config 
git config --list | grep user
git config --list --show-origin
```
* Comandos para configuración personal con tu usuario 
```sh
git config --global user.name "Escribe aqui tu nombre"
git config --global user.email "Escribe aqui tu correo git"
git config --global core.editor notepad
```

## Comandos unix relevantes 

Todos los siguientes comandos los puedes ejecutar desde la terminal gitbash

- Crear carpeta `mkdir nombre_carpeta`

- Crear archivo `touch nombre_archivo.extencion_archivo`

* Visualizar contenido de archivo en consola `cat nombre_archivo.extencion`

* Editar archivo en blog de nota de Windows 
`notepad nombre_archivo.extencion`

* Ver ubicación actual `pwd`

* Listar archivos ocultos `ls -al`

* Limpiar consola en gitbash `clear`


## Git ignore

Es un documento en donde nos permite ignorar una serie de archivos que por buenas practicas no deben subirse al repositorio git ni guthub ya que git esta diseñado para alojar texto plano.

¿Que no debería subir a git y github?
* Passwords
* Imgenes jpj, png etc
* Videos
* Entre otras

__Como usar git ignore__
1. Dentro de la carpeta de tu proyecto despues haber iniciado git en tu proyecto y antes de meterle codigo creas un archivo tipo ignore. Si estas en la consola de git puedes usar.
`touch .ignore`
2. Editas el archivo con tu editor de texto favorito o notepad `notepad .ignore` y escribimos todo lo que debe ser ignorado ejemplo.
Podemos escribir linea a linea 
 * `*` Para ignorar todo tipo de archivo
 * `*.jpg` Todas las imagenes .jpg
 * `*.png` Todas las imagenes .png
 * `*.svg` Todas las imagenes .svg
3. Despues de guardar la configuracion .ignore haces commit `git commit -am "Git ignore"`. 
Una ves realizado el commit ahora si metele mano al codigo
 
 Si quieres saber mas sobre como usar git ignore puedes entrar en Github y buscar librerias oficiales y leer su .ignore para que sepas y estudies como funcionan y normalmente que se ignora en el desarrollo deacuerdo a la tecnologia que uses.

Ahora te dejare un recurso que puedes usar. Si vas a  [ésta página](https://www.toptal.com/developers/gitignore) podras escribir la tecnologia que usas y te generar un archivo `.ignore` de guia mostrandote lo que deberias ignorar en el desarrollo.

Haremos un ejemplo de generar un .ignore para django


![Biscador de generador ignore](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0aegxd0ynn7723gcusgm.png)

Ponemos en el navegador django y nos generara el archivo.


![git ignore django](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/76bzkskvlygzktgg612k.png)

__Nota:__
1. Si eres nuevo usando git te recomiendo que desde tu primer proyecto uses git ignore ya que cuando recien comenzamos a aprender git trabajamos con imagenes para landing page svg y pngs
2. Si trabajas con imagenes  y quieres guardarlas en tu git te invito a buscar un servidor que aloje imagenes y te de el link de ellas para que la puedas susar en tu proyecto 
3. En caso que trabajes con imagenes locales te recomiendo disminuir su peso quitandole toda informacion meta de ella para ello podrias usar el siguiente [recurso](https://tinypng.com/)

***

## README.md
Cuando estas empezando con git tarde o temprano entras en GitHub en donde usarás este archvivo que por recomendación debes crearlo despues del .ignore antes de meterle codigo a tu proyecto con git, entonces usa `touch README.md`. No te olvides de hacer commit despúes de la creación del archivo.

La ultima recomendación es a nivel de Github, cuando crees un repositorio en GitHub, crealo sin el README.md ya que cuando creas un repo te pregunta si quieres generar ese archivo.
crealo mejor tu mismo desde tu repositorio local y cuando hagas tu primer push se enviará el README.md con tu proyecto. De esta manera evitarás conflictos que para alguien nuevo es un dolor de cabeza. 
Este conflicto se suele dar ya que antes de hacer push deberias hacer pull al servidor eso sirve para primero actualizar tu repositorio local con el de Github por que en realidad son dos repositorios distintos entonces si tienes el README.md en Github tendrás que resolverlo con un merge entre dos ramas distintas, borrar la rama antigua local y dejar la actual que ahora es la de github   


__¿Para que sirve?__
Este archivo sirve para mostrar tipo documentación lo que hace tu repositorio o lo que quieras decir de tu repositorio en Github donde todo el mundo lo verá.

Para escribir en el README.md debes usar html o MARKDOWN Asi que te recomendare el siguiente recurso, [aquí](https://pandao.github.io/editor.md/en.html), tendrás un ejemplo y un editor  



***

## Atajos y soluciones

* Si ingresas un commit sin mensaje y quieres salir del error usa 
`esc + shift + z + z`

* Para escribir en el editor vim `esc i`

* Para salir de alguna venta de información como `git log` usamos la letra `q`

* Ayuda de comandos git `git help comando_git` o 
`git comando_git --help`.

* Ver el historial de comandos usados `git history`.
> Se desplegara una lista enumerada y ordenada con todos los comandos usados y si queremos hacer  uso de alguno de ellos escribimos `!` seguido del numero del comando


***

## Inicializar un repositorio

* Si no tienes creada ni la carpeta del proyecto.
Esté comando, te creará la carpeta y te iniciará el proyecto en git 
`git init nombre_carpeta_proyecto` o si piensas que lo vas a usar en GitHub `git init nombre_carpeta_proyecto -b main`

* En caso de que ya esté creada la carpeta del proyecto.
Dentro de la carpeta ejecutas `git init` y si lo vas usar con github
`git init -b main`

***
## Manejo del staging area 

* Observar el estado de los archivos `git status`

* Agregar un solo archivo al staging area 
`git add nombre_archivo.extencion`

* Agregar todos los archivos al staging area sin excepciones, es decir, con los que estemos trabajando, modificando o no `git add .`

* Agregar todos los archivos con los que estamos trabajando al staging area `git add -A`

* Sacar un archivo del staging sin que los borre del disco duro, pero git le sigue dando seguimiento 
`git reset HEAD nombre_archivo.extencion`

> Este es el comando mas usado ya que aveces solo queremos que el archivo salga de la zona de staging en un estado de untracked. Esto significa que de inmediato podras hacer git add y git commit nuevamente.


* Sacar un archivo del staging area y del seguimiento de git 
`git rm -cached nombre_archivo.extencion`

>Una vez que apliques este comando sacaras del repositorio de git el archivo, no lo borra del disco duro. Si quisieras hacerle un add y commit no lo encontrarias en el repositorio, tendrias que esperar hasta el proximo commit para que apareciera.

* Sacar un archivo del stagig area y borrarlo de forma local 
`git rm -f nombre_archivo.extencion`

* Comprobar si un archivo fue agregado al staging area aunque parezca que no `git add -n nombre_archivo.extencion`

* Recuperar un archivo borrado por error 
`git checkout -- nombre_archivo.extencion`

* Ver diferencias entre el estado actual y el staging `git diff`


***
## Git commit 

El proceso de tradicional de realizar un commit es:

 
- Primero: Ver el estado del archivo modificado `git status`

- segundo: Añadir archivo al stagind area :pushpin: 
`git add nombre_archiv.extencion`

- Tercero: Hacer commit añadiendo una descripción del commit 
`git commit -m "Entre comillas escribe la descripcion"`


### Comandos avanzados para commit 


- Hacer commit directamente sin pasar por el staging 
`git commit -am "Descripcion"`


- __Ver la diferencia de un commit con otro__
Para esto necesitamos el identificador de los dos commit.
Para ver el identificador podemos usar `git log` 

> Nota: El identificador del commit es el numero alfanumerico. Este numero es muy largo pero es suficiente para identificarlo si solo usamos los primeros 5 numeros.

Luego de saber el identificador de los dos commit usamos 
`git diff identificador1 identificador2`

- __Sobreescribir un commit__.
Este comando lo usamos inmediatamente después que hemos cometido el error.
Antes de ejecutarlo corrigen el error  
`git commit --amed -m "Descripcion"`

> Podemos reescribir solo la descripcion, algun error, u algo faltante.

#### Comandos avanzados de sobreescritura 

Los siguientes comandos hay que tratarlos con cuidado porque podríamos perder código en el proceso
 

- Nos quitará el último commit, pero los archivos los dejará preparado en el staging para un nuevo commit. Usamos `git log` para ver el identificado del commit y luego :pushpin: 
`git reset --soft identificador`

- Nos quitará el último cambio y datos, no se guardarán en ningún lugar ni en el staging ni en el disco duro. Usamos `git log` para ver el identificado del commit y luego :pushpin: 
`git reset --mixed identificador`

- Borra todos los commits, stagings y working hasta el punto del commit que se requiere. Usamos `git log` para ver el identificado del commit y luego :pushpin: 
`git reset --hard identificador`

- __Recuperar commits depues de un reset hard__.
Lo primero que necesitamos es buscar el identificador de un commit seguro antes del reset hard.
Usamos `git reflog` o `git log -g`.

Una vez encontrado el commit seguro ejecutamos 
`git reset --hard identificador_commit_seguro`

- __Ver un commit a través del tiempo__.
Sabemos que a medida que se hacen los commit se van añadiendo cambios. Entonces este comando nos ayuda a ver el estado y el contenido de un commit pasado, es decir, antes de los cambios actuales.
Los cambios que se realicen no serán permanentes.

: Para ir al estado anterior del commit.
Usamos `git log` para ver el identificado del commit y luego 
`git checkout identificador nombre_archivo`


: Para regresar al tiempo actual `git checkout master`

: Si queremos hacer permanentes los cambios que hemos hecho en 
un commit pasado. Después de hacer los cambios correspondientes hacemos `git add .` y :pushpin: 
`git commit -m "Descripcion"`.
> Se hace un commit y los cambios seran enviados al commit 
actual.

- __Mover un commit de rama__. Este commit se lo debe ejecutar dentro de la rama donde se lo quiere mover :pushpin: 
`git cherry-pick identificador_commit`


- __Visualizar en consola los cambios de un archivo en su historia__. Este comando nos permitirá observar los cambios que existe en un archivo en el actual commit con el mismo archivo pero en el commit pasado. No solo nos muestra las modificaciones entre un commit y el otro, sino también donde están los cambios en la base de datos, diferencia en peso, bytes :pushpin: 
`git show nombre_archivo.extencion` 

- __Que cambios hubo entre un commit y otro__ 
`git diff identificador1 identificador2`

> El orden de los identificadores hara que muestre la informacion de una manera u otra.

***
## Git tag o Etiquetas 

Que es un tag

* Es un nombre que puedes usar para marcar un punto relevante, estructural o especifico de tu codigo en la historia del repositorio.

* Son relevantes en producción, trabajando en remoto GitHub con equipos. En GitHub se lo usa mucho para detallar versiones listas o release de un proyecto 

* Aunque los tags no son commit hay que enviarlos al repositorio principal 

__Comandos__

* Tags lijeras `git tag nombre_tag`


* Tags firmado por correo `git tag -a nombre_tag -m "Descripcion"


* tags formados por clave GPT del correo electronico 
`git tag -s nombre_tag "Descripcion"`

* Ver la lista de los tags `git tag -l`

* Renombrar tag :pushpin:
`git tag -f -a nuevo_nombre_tag "Descripcion"`


* Borrar tag `git tag -d nombre_tag` 
> Si borras un tag y trabajas con repositorios remoto no olvides actualizar la accion `git pull origin master` y despues `git push origin --tags`

> Aunque de esta manera se borro localmente aun queda en github ya que los releases o versiones listas son muy importantes asi que para evitar equivocaciones de borrado hay que borrarlo de forma especial con :pushpin: 
`git push origin :ref/tags/nombre_tag`

* Ver el commit que pertenece a la etiqueta :pushpin: 
`git show nombre_tag`


* Saber a que commit o hash esta vinculado un tag :pushpin: 
`git show-ref --tags`

* Filtrar etiquetas `git tag -l "patron de busqueda"`

***


## Git log

Muestra instantáneas confirmadas. Se utiliza para enumerar y filtrar el historial del proyecto, y buscar cambios particulares. El `git log` solo funciona en el historial comprometido en comparación con de `git status` que trabaja con el área de preparación o staging.

Si eres un scrum master o lider de proyecto usaras muchas configuraciones con este comando para revisar el trabajo de tus compañeros o ver como va el codigo en el dia etc. Pero para uso personal y para mi son las mas necesarias son:

* Instantánea estándar `git log`
* Muestra todas las ramas ` git log --all`
* Instantáneas abreviadas en una línea ` git log --pretty=online`
* Instantáneas gráficamente con el identificador abreviado y descripción `git log --pretty=format:"%h %s" --graph`
* Muestra las diferencias introducidas entre cada commit con limite en las dos ultmas entradas `git log -p -2`

Para mas configuraciones puedes visitar la  [Pagina oficial](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Ver-el-Historial-de-Confirmaciones)

***
## Ramas


![Imagen que muestra como funcionan las ramas en git](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/828o57pgu1tjmin8b02v.png)


__Nota:__
Si creamos una rama y no hacemos commit todo lo realizado se perdera.


* Crea una rama `git branch nombre_rama`

* Entrar en una rama diferente `git checkout nombre_rama`

* Crear una nueva rama y entrar en ella al mismo tiempo `git checkout -b nombre_rama`

* Listar ramas `git branch -l`

* Listar ramas remotas | GitHub `git branch -r`

* Listar ramas remotas GitHub y locales `git branch -a`

* Historia de rama `git show-branch --all`

* Elimina rama `git branch -d nombre_rama`

* Elimina rama con commits adentro `git branch -D nombre_rama`

* Renombrar una rama 
`git branch -m nombre_rama_anterior nombre_rama_nueva`

***
## Git merge o fusiones 



![Imagen de ejemplo grafico de merge](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hzznzcd43ajb6x63qbmx.png)
> Comenzamos con esta imagen para dar un ejemplo.
Tenemos 
Rama master: Tenemos el contendio html 
Rama Cabecera: Tenemos el diseño en cabecera

Queremos llevar el diseño de la rama cabecera a la rama master. Entonces guardamos commit en cabecera, nos dirigimos a la rama master `git checkout master` y en la rama master hacemos el merge a cabecera 
`git merge cabecera -m "Descripcion"`

> El `git merge` es un commit mas en el proyecto.

* Para saber que ramas no han sido fucionadas aun en la rama actual 
`git branch --no-merged`

* Para saber las ramas que ya han sido fucionadas. Si las ramas se eliminaron despues del merge entonces saldra master.
`git branch --merged`

### Algunos conflictos con merge

* Si sale un mensaje de Fast-forward significa que estas haciendo un merge en la continuacion directa de la rama en la cual salio

* Si no eres el primero en hacer un merge te va a pedir en tu editor para que coloques que quieres mezclar y como se va a llamar. Esto es un commit que pide confirmar los cambios, en otras palabras es una mezcla recursiva que obliga hacer un commit adicional, este se presenta en log como un commit mas a la rama principal.

* Cuando e ha cambiado lineas de codigo anteriores o archivos se denomina Auto-mergin y saldrá un mensaje de CONFLICT en donde preguntará  con que version se quedará. Una vez que se haya escojido u arreglado el conflicto se debe hacer un  nuevo commit 

* Cuando una rama intenta hacer merge en un documento que ha sido modificado por dos ramas distintas eso genera un conlicto. Entonces abrimos el documento y corregiremos de forma manual una vez eso mandamos al staging y luego hacemos commit.
> VisuslCode tiene ayudas para estas situaciones 

***
## Git rebase

Se usa cuando quieres que una rama no sea una rama si no mas bien que sea parte de la historia del master y no quede huella de que fue una rama.

__Caracteristicas__
* Primero quiero decirte que `git rebase` es una muy mala practica usarla de forma remota por lo cual esta puesta en este post ya que si puede ser usada de forma local de algunas formas.
* Es una mala practica por que reescribe la historia de los repositorios 
* Uno de los inconvenientes es que cuando haces rebase no queda historia, no se sabe quien hizo que cosa o que cambios y si la rama master avanzo mucho antes del rebase los problemas y conflictos seran muchos y habrá que solucionarlos de forma manual uno por uno causando retraso a todo el equipo

La unica forma en que se la puede recomendar es trabajarla de forma local en un proyecto personal  o en un proyecto en equipo siempre y cuando apliques rebase y arregles los conflictos antes de enviarlo al servidor. Por ejemplo.

Supongamos que traiste localmente el codigo del proyecto de equipo para hacer tu parte que es desarrollar el script de unas funciones en el diseño y el diseño entonces el primer dia tuviste un error que no pudiste resolver, al siguinte, dia2 resulves hacer una rama para arreglar el bugfix pero seguir trabajando en la linea principal en el diseño, 


![rebase1](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/13rdepj5e5yk1t0m4jkd.png)


terminaste el diseño en el mismo dia 2. 
En el dia 3 comienzas a resolver el bugfix y lo logras, entonces tu trabajo esta terminado. Puedes hacer un merge e incorporarlo a  tu linea de trabajo principal 



![merge](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zxlsgatl4d5zhzzorwk1.png)

pero no deseas que esa rama de bugfix quede en tu historial por que no ha sido algo relevante asi que haces rebase, resulves los conflictos y a la finl tu linea de trabajo quedará asi 


![rebase](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/a1k0be8ygvnr76bkvvla.png)

Como si nunca hubiera habido una rama y sin huellas de que haya habido una.

__Comandos__

Usaremos el mismo ejemplo anterior para el codigo  de acontinuación

* Estando en la rama del bugfix
`git rebase master` 

* Lugo desde el master. :pushpin:
`git rebase nombre_rama_rebase_anterior`

* En este momento hay dos ramas que contienen lo mismo el master y en bugfix

* Solucionar de forma manual los conflictos en la rama master 

* Por ultimo eliminar la rama bugfix
`git branch -D rama_bugfix`

***

## Git stash 

Sabemos que si hacemos cambios en una rama y luego cambiamos de rama sin hacer commit antes, perderemos los cambios hechos anteriormente. 

Para evitarlo existe `git stash`. Nos permite guardar cambios temporalmente para usarlos despúes o en una nueva rama 

Se usa cuando  estas probando algun codigo que no merece un rebase o una nueva rama y quieres regresar rapido a tu estado anterior

Si usas un stash en una rama antes ya creada causarias muchos conflictos. Solo se recomienda usarla en una nueva rama 

__Comandos__

* Para guardar el cambio temporal
`git stash`
* Para listar stash guardados
`git stash list`
* Para ejecutar el stash guardado en una nueva rama :pushpin:     
`git stash pop`
* Para deshacer el pop 
`Control z`
* Guardar un stash en una rama nueva 
`git stash branch nombre_rama` y luego
`git commit -am "Descripcion"`
* Eliminar stash `git stash drop`

***

## Git clean 

Es un comando que nos ayuda a limpiar el entorno de trabajo. Ejemplo

Si tenemos archivos duplicados o archivos que no han sido utilizados, llamados entre otros

A `git clean` no le interesan las carpetas solo los archvivos, tampoco tomará encuenta todo lo que este en .ignore


El comando que se usa es `git clean` pero no se usa solo. Cuando lo quieras usar ejecuta 
`git clean --dry-run`
Este comando te mostrara en lista una simulacion de todo lo que puede ser eliminado por clean.
Si estas satisfecho con todo lo que te muestra para borrarlo entonces ahora si ejecutas `git clean -f` para eliminar

***

## Git cherry pick 

Se usa cuando estamos trabajando un avance en una rama y se requiere en el master de urgencia un commit especifico de tu rama en al que estas trabajando 

__Pasos para ejecutar cherry pick__

1. Hacer `git checkout` a la rama donde esta el commit solicitado 
2. Hacer `git log` para copiar el identificador del commit solicitado.
3. HRegresamos al master con `git checkout master` y ejecutamos en el master 
`git cherry-pich identificador_commit_solicitado`

> Cuando se termine lo que se estaba haciendo en la rama y se valla hacer un merge oviamente abran conflictos por que la rama master ya tiene un commit de la rama, pero esto se soluciona simplemente fixeandolo manualmente o con ayuda del editor de codigo

__Su estas trabajando con Github__
Cuando lo quieras enviar al servidor no olvidar primero hacer `git pull origin master` y ahora si `git push origin master` para enviarlo
> GitHub nunca se enterará de los combios locales 

***
## Git Reset y Reflog

* Se usa en casos de emergencia, se usa cuando hemos hechos cambios tan drasticos que queremos recuperar el punto antes de ese momento. 
* En regflog no se borra  ningun commmit o cambio en el tiempo
* si en `git log` no se ecuentran los cambios por que han sido eliminados de seguro en `git reflog` si estarán 

__Pasos para ejecutarlo__
1. Ejecutamos `git reflog`
2. Nos aparecera una lista de commit incluyendo los commits borrados y los que no han sido borrados
3. Buscamos el ultimo commit en donde todo esta correcto o el que deseamos recuperar y copiamos su identificador o head.
4. Para recuperar tenemos tres opciones:

   * Reset soft: Te regresa a un punto donde los archivos estan preparados en el staging a la espera de un nuevo commit
`git reset --soft identificador_commit`

   * Reset mixed: Te regresa a un punto donde los archivos estan en el repositorios de git y no se ha hecho ni staging ni commit.
`git reset --mixed identificador_commit`

   * Reset hard: Te regresa a un punto donde se recuperan los archivos pero solo lo puedes ver localmente es decir git no les esta dando segumiento, tendrias que darle commit a ese estado para que la proxima vez ya git le pueda dar seguimiento en el repositorio. Este reset solo se usa cuando has hecho algo masl y quieres volver a empezar de nuevo pero quieres los archivos 
`git reset --hard identificador_commit`

***

## Git grep

Este comando lo usamos cuando el proyecto es muy grande y por ovia razones muchos archivos y queremos buscar algo dentro de un archivo como una sintaxis. Por ejemplo

Si queremos buscar la etiqueta <p> entre todos los archivos 

__Comandos__
* Buscar el archivo donde esta la palabra o etiqueta. :pushpin:
`git grep "codigo, palabra o etiqueta"`


* Buscar el archivo y la linea de codigo.
`git grep -n "codigo, etiqueta o palabra"`


* Contar la cantidad de veces que una palabra aparece. :pushpin:
`git grep -c "palabra, codigo o etiqueta"`


* Si quiero buscar algo que no esta en el codigo sino en la historia de los commit. Por ejemplo. Cuantas veces escribi la palabra diseño en los commit o donde la palabra diseño tiene algo que ver con respecto a los commit. :page_with_curl: :pencil2: :pushpin: `git log -S "diseño"`

***
## Comandos para lider de equipo de desarrollo o scrum 

* Cuantos commits ha realizado cada miembro del equipo.
`git short log`

* Mostrar las personas que han realizado ciertos commits en el equipo. 
`git short log`

* Mostrar todos los commits incluidos los eliminados 
`git shot log -sn --all`

* Mostrar todos los commits incluidos los eliminados pero que no incluya los merges o los commits fusionados. 
`git short log -sn --all --no-merges`

* Saber quien hizo que en el codigo. 
`git blame -c nombre_archivo`

* Saber quien hizo que en el codigo especificando las lineas de codigo de donde(33) hasta donde(55). 
`git blame nombre_archivo -L33,55`

***

## Git alias
Lo usamos para abreviar un comando largo y dificil de recordar en uno mas corto y facil de recordar y referenciado con su accion 

Ejemplo:
`git short log -sn --all --no-merges`

Para tranformarlo en un alias usamos:
 
`git config --global alias.nombre_nuevo "git short log -sn --all --no-merges"`

***

## GitHub

### Inicializar un repositorio local y en github vacio

1. Crear repositorio en Github sin el archivo README.md
2. Crear la carpeta del proyecto y dentro de la carpeta del proyecto crear de forma manual el archivo readme o por cmd `echo "# readme" >> README.md`
3. Dentro de la carpeta del proyecto iniciamos git. :page_with_curl: :pencil2:
`git init -b main`
>En caso que la rama master se llame master debemos cambiarle a main con el comando 
`git branch -M main`.

4. Verificamos que todo este listo. Ejecutamos `git add .` y `git commit -m "Inicio de proyecto"`
5. Copiamos el link del repositorio que creamos en Github el de http ejecutamos 
`git remote add origin http.tulinkrepositorio`
6. Hacemos push `git push -u origin main`
7. Puedes comprobar que tus archivo README.md esta en GitHub

__Apartir de aqui cada cambio que quieras enviar__ 
1. Revisalo y soluciona errores
2. Refrescar a tu repositorio local el Github con :pushpin:
`git pull origin main`
3. Enviar tus actualización con 
`git push origin main`

> Si estas trabajando despues con varias ramas pero deseas enviar la actualizacion de una sola rama al master en Github usa 
`git push -u origin main`