Skip to content

Instantly share code, notes, and snippets.

@maxiyommi

maxiyommi/diagramGit.png

Last active March 18, 2021 17:34
Show Gist options
  • Save maxiyommi/b5d2ef4c66f17870a92bc27f4afe71c2 to your computer and use it in GitHub Desktop.
Save maxiyommi/b5d2ef4c66f17870a92bc27f4afe71c2 to your computer and use it in GitHub Desktop.
Download ZIP
Git
Raw
gitflow.md

Git - Flow propuesto para trabajo de nuevos proyecto

Pensando en una nueva metodología de trabajo a la hora de organizar nuestros repositorios, propongo comenzar los nuevos proyectos de la siguiente manera:

El coordinador del proyecto crea el nuevo repo y lo inicia.

mkdir nuestro-proyecto
cd nuestro-proyecto
git init

Se crean los siguientes branchs:

  • master: no es una rama de trabajo (no se hacen modificaciones directamente acá), sino más bien suele tener la última versión funcionando (rama por defecto).

  • develop: es la rama de trabajo, el punto de partida de los branches que añaden características al proyecto (feature). NO SE TRABAJA DIRECTAMENTE EN EL MISMO.

git checkout -b develop master

Ambas ramas (master y develop) deben estar siempre sincronizadas, luego de hacer cada realese .

Inicialmente ambas ramas están vacías, para comenzar a completarlas y trabajar se arma un branch:

En caso de estar en un proyecto ya iniciado, realizar un commit antes (git add . y git commit -m "mensaje")

  • feature-<>: es la rama de la nuevas funcionalidades. Las feature branches nacen de la rama develop y se incorporan a esa misma rama.
git checkout -b feature-nueva_caracteristica develop
git branch -av

Una vez terminado con el trabajo de la nueva característica, es el momento de incorporar los cambios a la rama develop:

git checkout develop
git merge feature-nueva_caracteristica

Cuando tengamos varias nuevas características incorporadas en el branch devolop (definido de antemano), se procede a realizar un release, documentando las nuevas características en un archivo .md. Para lo cual, primeramente creamos una nueva rama_

  • release: una vez finalizadas y probadas las nuevas funcionalidades, comienza el lanzamiento de la actualización con su respectiva documentación.
git checkout -b release develop
git branch -av

No se hacen modificaciones en el código, solo documentación de la actualización o posibles bugs, errores o comentarios.

Una vez documentado se procede a fusionar la rama con develop y master:

git checkout develop
git merge release
git checkout master
git merge develop

En cualquier instancia deberíamos enlazar el repositorio local, aun repositorio remoto para compartir los avances:

git add .
git commit -m "first commit"
git remote add origin https://github.com/NOMBRE_USUARIO/NOMBRE_PROYECTO.git
git push -u origin master

Una vez avanzado el proyecto en nuestro repo local suele aparecer las ramas que son eliminadas o merge, para limpiar eso:

git remote update origin --prune
git branch -a

Referencias:

Raw
introduccion.md

Git - Introducción

Este documento es una traducción de @mglerner en GitHub por Google Translate y adaptado para este documento.

El control de versiones es un método para realizar un seguimiento de los cambios que presentamos a un conjunto de archivos o documentos que usamos. El control de versiones nos permite comparar versiones más nuevas de código con versiones anteriores e investigar cuándo se realizaron ciertos cambios que pueden haber causado un mal funcionamiento del código. Git es uno de esos software de control de versiones, que fue creado por Linus Torvalds para ayudar a escribir el kernel de Linux.

Los sistemas de control de versiones almacenan archivos en un directorio conocido como repositorio de manera local o remota. Además de los archivos, un repositorio también contiene información sobre el historial de cada archivo y todas las modificaciones que se realizaron.

Ante cualquier duda ir a la documentación oficial Git.

Un versión simplificada de los comandos básicos y uso más común de la herramienta, se encuentra en el siguiente link.

Una excelente aplicación web diseñada para ayudar a los principantes a manejar los poderosos conceptos que hay detrás del trabajo con ramas (branches) en Git es learngitbranching.js.org.

Git en windows

Instalar Git en Windows es muy fácil, simplemente descarga el archivo .exe del instalador desde la página de Git for windows. Una vez instalado (con todas las configuraciones por defecto), tendrás tanto la versión de línea de comandos (incluido un cliente SSH) como la interfaz gráfica de usuario estándar.

Antes que nada

Cuando escribimos mensajes commit, necesitamos usar un editor de texto. El editor de texto predeterminado, vim, es ... antipático. Es increíblemente poderoso, pero no es amigable. A la luz de eso, cambiemos el editor predeterminado al nano haciendo lo siguiente en una terminal (solo hacemos esto una vez, los cambios persistirán):

echo "export EDITOR=nano" >> .bashrc
source .bashrc

Configurar Git

Antes de usar Git, tenemos que configurar dos cosas para ayudar a rastrear los cambios que hacemos a los archivos. Ejecute los siguientes comandos, completando su información personal. Asegúrese de usar la misma dirección de correo electrónico que utilizó para registrarse en Github, Gitlab o Bitbucket.

git config --global user.email "your.github.email"
git config --global user.name "First Last"

Si copia y pega éstos, asegúrese de hacerlo una línea a la vez. Si pega dos líneas en un terminal, ejecutará el primer comando automáticamente y Git pensará que su dirección de correo electrónico es "your.github.email".

Para comprobar la configuración usar el comando git config --global --list

Obteniendo ayuda

Si alguna vez necesitas ayuda usando Git, hay tres formas de ver la página del manual (manpage) para cualquier comando de Git:

git help <comando>

Por ejemplo, puedes ver la página del manual para el comando config ejecutando:

git help config

Creando un Git repositorio

Primero vamos a hacer un nuevo directorio que se convertirá en nuestro primer repositorio de git. ¿Recuerdas el comando para hacer un nuevo directorio? ¡Es mkdir! Nos gusta mantener todos nuestros directorios de git en una carpeta llamada "git". Hagamos esa carpeta primero.

mkdir git

Ahora creemos una nueva carpeta llamada "first_repo" que será, como era de esperar, nuestro primer repositorio.

cd git
mkdir first_repo

Cuidado: si está acostumbrado a usar espacios en los nombres de las carpetas, ¡cuidado! En Linux (y OSX) si ejecuta el comando.

mkdir first repo

De hecho, terminará con dos carpetas, una llamada "first" y otra llamada "repo".

Agregue un script Python al nuevo directorio

Vamos a cd en "first_repo" y luego creamos un script rápido de Python.

cd first_repo
nano HelloWorld.py

¿Qué es nano?

nano es un editor de texto simple basado en terminal. Hay varios editores increíblemente potentes basados en terminales (Vim, Emacs) pero vienen con curvas de aprendizaje bastante empinadas. nano es mucho más amigable.

El archivo HelloWorld.py no existe, pero ejecutamos nano HelloWorld.py y crea ese archivo y lo abre para su edición.

Volviendo al script

Ingresar:

print("Hello, World!")

Luego presiona Ctrl + o para guardar el archivo, luego Ctrl + x para salir de nano.

Inicializando un repositorio

Ahora tenemos una carpeta llamada "first_repo" con el script HelloWorld.py en ella. Ahora vamos a convertir esta carpeta en un repositorio de Git

Primero, verifica que estés en la carpeta que creaste con pwd:

pwd

Si estás en el lugar correcto:

git init

Ahora "first_repo" es un repositorio Git.

Estado de un repositorio

Para chequear el status del repositorio:

git status

Devolverá lo siguiente:

# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   HelloWorld.py
nothing added to commit but untracked files present (use "git add" to track)

¿Qué está pasando aquí?

  • El historial del repositorio se almacena a lo largo de una línea de tiempo conocida como branch (rama). Estamos en la branch "master" (principal).
  • En cualquier momento, el usuario puede elegir guardar una snapshot de todos los archivos en el repositorio. Cada snapshot se conoce como commit. El acto de guardar una instantánea se conoce como committing changes.

Agregar archivos al repositorio

El comando status también nos dijo que tenemos un "Untracked files" (HelloWorld.py). Eso significa que HelloWorld.py no forma parte de ninguna snapshots y Git no registra su historial.

El resultado también nos dice qué debemos hacer para commit a nuestros cambios: (use "git add ..." para incluir el commit). Así que hagámoslo y revisemos el estado nuevamente:

git add HelloWorld.py
git status

Que nos da:

# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#   new file:   HelloWorld.py
#

Tenga en cuenta que esto aún no confirma los cambios. El comando git add agrega el archivo a lo que se conoce como el área staging (de ensayo). Aquí es donde se almacenan todos los cambios en los archivos que están listos para committed. Todos los archivos en el área staging se enumeran en "Changes to be committed:". Podemos ver que HelloWorld.py se ha agregado a esta lista.

Committing changes I

Queremos guardar un snapshot del repositorio tal como está ahora; es hora de commit!

git commit

Esto abrirá nano y verá un montón de información sobre el commit que está realizando. Centrémonos en escribir nuestro primer mensaje commit. Escriba un mensaje commit:

First commit.  Add HelloWorld.py

Luego presiona Ctrl + o para guardar y luego Ctrl + x para salir.

¡Felicitaciones! ¡Acabas de hacer tu primer commit! Escribir buenos mensajes de commit es una buena práctica de programación. Te ayudará a vos y a cualquier otra persona que use tu código más adelante.git st

Verifique el estado del repositorio nuevamente:

git status

Y se deberia ver, algo asi:

# On branch master
nothing to commit (working directory clean)

Editando un tracked file

Ahora, supongamos que decide realizar algunos cambios en el archivo. En lugar de imprimir "Hello, World!", Quieres mostrar "Greetings Earth! We come in peace." Abre nano nuevamente para editar el archivo.

nano HelloWorld.py

y realice los cambios apropiados en el archivo:

print("Greetings Earth! We come in peace.")

Luego presiona Ctrl + o para guardar y luego Ctrl + x para salir.

Verifique el estado del repositorio nuevamente:

git status

Y se debería ver, algo asi:

# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   HelloWorld.py
#
no changes added to commit (use "git add" and/or "git commit -a")

Tiene una lista de archivos que se han modificado desde el último commit, junto con algunos consejos sobre lo que puede hacer con ellos.

Ver cambios

Solo cambiamos una línea en un archivo; pgit diero a veces puede editar varias líneas, o tomar un café y volver, y descubrir que no puede recordar todo lo que ha hecho. Aquí es donde entra en juego git diff. Mostrará todos los cambios realizados en el repositorio actual (¡incluso si aún no están committed !).

git diff

Y se debería ver, algo asi:

diff --git a/HelloWorld.py b/HelloWorld.py
index ed708ec..ce3f2ef 100644
--- a/HelloWorld.py
+++ b/HelloWorld.py
@@ -1 +1 @@
-print "Hello world!"
+print "Greetings Earth! We come in peace."

Todas las líneas que comienzan con - son aquellas que han sido eliminadas, y las líneas que comienzan con + son las que se han agregado. En nuestro caso, podemos ver que la impresión ("Hello world!") Se ha eliminado y agregado ("Greetings Earth! We come in peace.") en su lugar.

Committing changes II

Queremos agregar los cambios que hicimos al historial del archivo "HelloWorld.py". Para hacer esto, seguimos los mismos pasos que cuando agregamos el archivo por primera vez.

Primero, el stage de los cambios ejecutamos

git add HelloWorld.py

Ahora revisa el estado del repositorio nuevamente:

> git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   HelloWorld.py
#

¡Ahora estamos listos para commit ese cambio! Pero es un cambio bastante simple, ¿no? Si sabemos que no necesitamos escribir un mensaje de commit más complicado, podemos usar un atajo:

git commit -m "Edit the message to sound more friendly"

-m es la abreviatura de mensaje. Este comando confirmará los cambios con el mensaje que le pasamos. ¡No es necesario abrir nano esta vez!.

Viendo el historial del repositorio

Hemos guardado dos snapshots de este repositorio. Podemos ver la lista de todas las commits usando el comando git log.

git log

que dará como resultado algo así como:

commit e9d7cbab2205d00d5ef574fcae8ff75701529565
Author: Gil Forsyth <gforsyth@...>
Date:   Tue Aug 19 16:36:08 2015 -0400

    Edit the message to sound more friendly.

commit 16bb3d3b5af5e485e4713a3fdefcff7ae88ce7df
Author: Gil Forsyth <gforsyth@...>
Date:   Tue Aug 19 15:45:12 2015 -0400

    First commit. Add HelloWorld.py.

Ciclo de vida del estado de los archivos

Dado un repositorio Git completo, y una copia de trabajo de los archivos de ese proyecto (en algún repositorio remoto), surge la necesidad hacer algunos cambios, y confirmar snapshot de esos cambios a tu repositorio cada vez que el proyecto alcance un estado que desees grabar.

Recuerda que cada archivo de tu directorio de trabajo puede estar en uno de estos dos estados: bajo seguimiento (tracked), o sin seguimiento (untracked). Los archivos bajo seguimiento son aquellos que existían en la última instantánea; pueden estar sin modificaciones, modificados, o preparados. Los archivos sin seguimiento son todos los demás —cualquier archivo de tu directorio que no estuviese en tu última snapshot ni está en tu área de preparación—. La primera vez que clonas un repositorio, todos tus archivos estarán bajo seguimiento y sin modificaciones, ya que los acabas de copiar y no has modificado nada.

A medida que editas archivos, Git los ve como modificados, porque los has cambiado desde tu última confirmación. Preparas estos archivos modificados y luego confirmas todos los cambios que hayas preparado, y el ciclo se repite. Este proceso queda ilustrado en la siguiente figura:

Push para crear un nuevo proyecto

Cuando crea un nuevo repositorio localmente, en lugar de ir a GitLab (por elegir una opción) manualmente crea un nuevo proyecto y luego presiona el repositorio, puedes presionarlo directamente para GitLab para crear el nuevo proyecto, todo sin salir de tu terminal. Si tienes acceso a eso espacio de nombres, crearemos automáticamente un nuevo proyecto en ese espacio de nombre de GitLab con su visibilidad configurada como Privada de manera predeterminada (más tarde puede cambiarla en la configuración del proyecto).

Git push usando HTTP

git push --set-upstream https://gitlab.example.com/namespace/nonexistent-project.git master

Actualizar el repositorio en Github, Gitlab o Bitbucket

Una de las características ingeniosas de Git es que le permite copiar la carpeta que contiene el repositorio a cualquier otra ubicación, y toda la información relacionada con el historial del repositorio también se transfiere automáticamente. También le permite crear una copia de seguridad de su repositorio en un servidor remoto. Los servicios como Github ejecutan servidores donde puede alojar sus repositorios de forma gratuita.

Crea una cuenta en Github y sigue las instrucciones para crear tu propio repositorio Github.

Para evitar confusiones, es una buena idea darle al repositorio de Github el mismo nombre que la carpeta en su computadora.

Después de que se crea el repositorio, Github mostrará instrucciones para enviar un repositorio existente a Github usando la línea de comando. Los comandos son:

git remote add origin https://github.com/gforsyth/first_repo.git
git push -u origin master

Por supuesto, debe hacer los cambios apropiados para que refleje su nombre de usuario Github y el nombre de su repositorio.

  • git remote add es el comando utilizado para especificar información sobre el repositorio remoto al que desea cargar. Para hacer esto, necesitamos proporcionar un nombre para el control remoto y la dirección del servidor donde está alojado. En lo anterior, nombramos el origin del repositorio remoto (por convención) y especificamos el URL creado por Github.

  • git push se usa para enviar todos los cambios desde el repositorio local al repositorio remoto. La bandera -u solo se usa la primera vez que empuja una nueva rama.

403 Forbidden while accessing...

La versión anterior de git a veces arroja errores al intentar push a GitHub o cualquier otro sitio que utiliza la autenticación HTTPS. Si obtienes el error anterior al intentar hacer git push, puedes arreglarlo con una línea adicional:

git remote add origin https://github.com/gforsyth/first_repo.git
git remote set-url origin https://gforsyth@github.com/gforsyth/first_repo.git
git push -u origin master

Asegúrese de cambiar el nombre de usuario y el nombre del repositorio para que coincida con lo que ha creado. Si está utilizando una versión anterior de git, la solución más fácil es actualizar, pero si no puede hacerlo por el motivo que sea, ejecutar ese comando adicional cuando configure un nuevo repositorio debería solucionar el problema.

Ver en el repositorio de GitHub

Sus cambios deben reflejarse inmediatamente en Github. La URL de su repositorio debe ser https://github.com/<your username>/first_repo.

Workflow en Git

Esta sección analiza brevemente el flujo de trabajo en Github, en una situación en la que un repositorio tiene muchos colaboradores. Para más detalles ver este link del sitio Github, que incluye una versión más linda del diagrama y una explicación detallada de cada parte del proceso.

La rama principal, llamada master, sólo contiene avances probados y concluidos. Cada vez que queremos aplicar un avance o idea nueva en un repositorio creamos una rama o branch sobre la cual probamos las nuevas modificaciones. Los commits se hacen dentro de la rama y cuando consideremos que hemos finalizado con el avance en que estuvimos trabajando realizamos un pull request. Ésto hace que se inicie una discusión sobre el avance con los colaboradores y el dueño/administrador del repositorio. Éste último puede aceptar el 'request' y agregar el avance en la rama 'master' mediante un merge.

Comandos para la consola de GIT:

  • Crear un branch con el nombre 'pantalla-principal': git branch pantalla-principal
  • Ubicarse dentro del branch para hacer cambios ahí: git checkout pantalla-principal
  • Forma abreviada para hacer ambas cosas a la vez: git checkout -b pantalla-principal
@imazzala
Copy link

Es importante tener en cuenta que GitHub al crear el repositorio ya no llama a la rama principal master sino main. Hay dos posibilidades acá para evitar conflictos con nuestro repo local, la primera y recomendable por buenas prácticas es el renombrar en nuestro repositorio local la rama principal a main, para ello, dentro del repo local, debemos ejecutar el siguiente comando:

git branch -m master main

La segunda posibilidad es dentro de GitHub, en el repositorio del archivo vamos a Settings -> Branches y dentro de Default Branch elegir la opción de editar que aparece como un pincel al lado del nombre de la rama y modificamos el nombre de Main a master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment