• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer

Geekebrains

Para programadores, maker y geeks en general

  • Inicio
  • Zona Coders!
  • Zona Makers!
You are here: Home / Zona Coders! / git [Guía rápida]

22 mayo, 2019 Por admin8049 Leave a Comment

git [Guía rápida]

Git es una herramienta de gestión de versiones imprescindible si trabaja más de uno en un proyecto, y altamente recomendable en cualquier caso.

El modo de trabajo estándar se basa en que el código está en varios «sitios»: el directorio de trabajo, que es tu directorio de trabajo, el staging, es un estado intermedio antes de hacer un commit de los cambios y pasar al repositorio local, y en caso de colaborar con mas gente, se puede sincronizar los cambios con otro repositorio remoto, mediante push y pull.

git workflow


git init

Inicializa una carpeta para poder utilizar git de forma local. Crea unas carpetas ocultas donde guarda la información del estado de las versiones, etc.

>git init carpeta-de-trabajo

git clone

Si quieres descargar un proyecto de un repositorio para trabajar en local.

git clone /path/to/repository

git add

Añade ficheros para que los tenga en cuenta el repositorio.

>git add fichero.txt

Para enviar todo de forma recursiva:

>git add .

Si eliminas un fichero y quieres decírselo al repositorio para que lo quite, tambien se hace un «git add». Realmente este comando sincroniza tu carpeta con el repositorio.

git commit

Guarda el conjunto de cambios que tienes en tu repositorio local en la cabecera, HEAD, es decir en la última versión.

Le puedes poner una etiqueta, para cuando consultes el histórico de cambio poder revisarlo.

>git commit –m “Aquí toque cosas"

git push

>git push

git pull

Sincroniza el repositorio local con el remoto. Es lo mismo que hacer: fech + merge.

git push

Sincroniza el repositorio remoto con el local.

Envía los ficheros comiteados que estan en el HEAD al repositorio remoto.

Para evitar conflictos es bueno hacer un pull, antes de enviar el push.

git status

Devuelve el estado del repositorio. Te dice los ficheros que no estan en estado ‘normal’, etc.

git log

Muestra la historia de los commits.

git mv

Para git es lo mismo mover un fichero a otro sitio que renombrarlo.

git checkout

Cambia el directorio de trabajo con la rama que queramos, sino pones nada cogerá lo del stage.

git branch

Sirve para cambiar de rama, crear y eliminar ramas.

git tag

Nos permite darle un nombre a un esto en concreto del repositorio. Por ejemplo en el master se crean etiquetas con las distintas versiones que se van liberando.

Que es un Branche o Rama?

Un branche ó rama es una versión del todo el código del repositorio. Cuando trabajamos en equipos de desarrollo, lo normal es tener una versión principal del código que es la rama/branche «master». Cuando se crea una nueva funcionalidad o una nueva versión del producto, lo normal es crear una nueva rama y trabajar sobre ella, así siempre tenemos disponible la versión principal y corregir sobre esta pequeños errores que nos dicen los clientes y nuestros cambios con las nuevas funcionalidades solo las puede ver por ejemplo los del equipo de desarrollo.

Que Integra o hacer Merge?

Cuando se finaliza esta rama nueva y se testea que está todo ok, entonces se hace un MERGE, de nuestra nueva rama y la principal. Con esto sincronizamos el código de las dos ramas. Y a continuación podríamos enviar a los clientes la nueva versión y volver a hacer una nueva rama de mejoras y corregir los pequeños errores sobre la principal. Normalmente es hacer el merge con alguna herramienta gráfica, porque es más fácil de revisar los conflictos.

Que es un fork o bifurcación de Git?

El concepto de bifurcar un proyecto ha existido durante décadas en software libre y de código abierto. “Fork” significa tomar una copia del proyecto, cambiarle el nombre y comenzar un nuevo proyecto y una comunidad alrededor de la copia. Aquellos que se dedican a un proyecto rara vez, o nunca, contribuyen al proyecto principal nuevamente. 
Puede haber muchas razones para un proyecto fork. Tal vez el proyecto ha estado en barbecho por un tiempo y alguien quiere revivirlo. Quizás la compañía que ha suscrito el proyecto ha sido adquirida y la comunidad teme que la nueva empresa matriz cierre el proyecto. O tal vez hay un cisma dentro de la propia comunidad, donde una parte de la comunidad ha decidido tomar una dirección diferente con el proyecto. A menudo, una bifurcación del proyecto va acompañada de una gran cantidad de discusiones y posiblemente también de luchas comunitarias. Cualquiera que sea el motivo, un proyecto fork es la copia de un proyecto con el propósito de crear una comunidad nueva y separada a su alrededor. Si bien el fork requiere algún trabajo técnico, es principalmente una acción social.

Técnicamente cuando haces un fork en git, estás haciendo un clone. La única diferencia es que con el fork, estas «insinuando» que te estan desvinculando de la comunidad del proyecto original y quieres crear una nueva comunidad.

Que es un Clon de Git?

Cuando queremos contribuir con un proyecto lo normal es que no tengamos permiso para añadir cambios al repositorio original. En esos casos se hace un clon local del repositorio, contra el cual puede hacer los cambios que desee. Si desea contribuir con los cambios al repositorio original, debe enviar una solicitud de extracción. 

Los clones, a diferencia de los forks, son acciones técnicas y no necesitan involucrar a la comunidad ni a ningún cambio social.

Que es un Pull Request?

Cuando estás trabajando en un clone y quieres notificar a los administradores del proyecto original que quieres enviarles una nueva funcionalidad entonces les envias a estos un Pull Request con tus cambios. Después depende de los administradores del proyecto original que quieran aceptarlo e integralo en su rama master.

Clientes gráficos de Git

Git

SourceTree

GitKraken

Que es un Stash o Reservado?

Qué alternativas hay a Git?

Para el control de versiones también existe: SVN (Subversión), CVS, Darcs, Mercurial, pero git es con diferencia el más utilizado.

Un poco de historia

Git lo creo Linus Torvalds, (el que mismo que creó Linux en 1991) para gestionar la gestión del código fuente del propio Linux, cuando en 2005 dejó de ser gratuito el servicio de control de código que utilizaba.

Internamente

Git para saber si hubo cambios en un fichero lo controla con número Hash que se obtiene con un algoritmo de tipo CheckSum en el caso de git utiliza el SHA-1. Cualquier cambio en un fichero daría como resultado un número Hash distinto y así puede hacer comparaciones más rápidamente.

Git no guarda los ficheros de modo incremental, sino que guarda una Snapshot completo de los ficheros de cada commit.

Conceptos más avanzados

hunk – cambio

cherrypick commit – Enviar un commit de una rama a la activa.

Filed Under: Zona Coders! Tagged With: git

Previous Post: « Java [Guía Rápida]
Next Post: HTML5 [Guía rápida] »

Reader Interactions

Deja una respuesta Cancelar la respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Primary Sidebar

Categorías

  • Cómo …?
  • Experimentos
  • GeekeBlocks
  • Noticias Geek
  • Proyectos
  • Qué es …?
  • Quién es …?
  • Zona Coders!
  • Zona Junior!
  • Zona makers!

Etiquetas

Arduino base64 Bases de Datos cert Certificados Digitales Clean Code Code Smells DBeaver Diseño de Software docker docker-compose Domain Drive Design https IDE Java javascript jest JSON lenguajes de programación Librerías de JavaScript linux lsoft Material UI MongoDb MySQL NodeJS NoSQL odoo Open Source openssl Oracle package.json Patrones de Diseño de Software pem plugins Postgres Prettier ReactJS Refactoring shell SQL Developer de Oracle SSL TypeScript utilidades de software Visual Studio Code

Entradas recientes

  • JWT
  • Lenguaje ubicuo en Domain-Driven Design (DDD)
  • NestJs
  • Docker-compose y mongoDB: Failed to start up WiredTiger under any compatibility version?
  • Ponerle nombre a las cosas: camelCase, snake_case, kebab-case, PascalCase, MACRO_CASE y Train_Case
  • OBS – Open Broadcaster Software
  • Duck typing
  • Patrón de arquitectura: Backend for Frontend – BFF
  • SaaS, PaaS y IaaS
  • Notion
Jesús A. Carballo Santaclara

Empezé trasteando en los 80' con un ZX espectrum, después pasé al potente "PC 8086" (jeje...). He trabajado haciendo software para la administración pública, para Hospitales, el sector de la Automoción, el sector Bancario, en algún e-Commerce de alguna multinacional y he emprendido en robótica educativa y en buscadores web.
Trabajo de forma profesional en esto de los ordenadores desde hace mas de 25 años espero poder contarte alguna cosa interesante.

Footer

Copyright © 2023 · GeekeZonia · Aviso Legal · Política de Cookies · Política de Privacidad · Log in