Diferencia entre revisiones de «Trabajando con Git»

De Recursos Educativos
Ir a la navegación Ir a la búsqueda
Sin resumen de edición
mSin resumen de edición
 
(No se muestran 9 ediciones intermedias del mismo usuario)
Línea 1: Línea 1:
Receta para trabajar con Git. Para un solo desarrollador en multiples ordenadores. Es una configuracion muy sencilla (para lo que Git es capaz de hacer).
Anotaciones para ayudarme a migrar de Subversion a Git. La intención es documentar los flujos básicos de trabajo con Git, y anotar las principales diferencias de concepto que voy encontrando.
 
Mi uso es para un solo desarrollador en multiples ordenadores. Es una configuracion muy sencilla (para lo que Git es capaz de hacer).


Asunciones:
Asunciones:


* Servidor Git: aws.luisantolin.com
* Servidor Git: <code>aws.luisantolin.com</code>
* Usuario Git: git
* Usuario Git con intercambio de claves SSH ya configurado: <code>git</code>
* Una sola rama, la de por defecto: master
* Una sola rama, la de por defecto: <code>master</code>
* Una solo repositorio remoto por proyecto, el de por defecto: origin
* Una solo repositorio remoto por proyecto, el de por defecto: <code>origin</code>
* Intercambio de claves SSH ya configurado
* Nombre de proyecto: <code>proyecto</code>
* Nombre de proyecto: proyecto


== Proyecto nuevo ==
== Proyecto nuevo ==
Línea 16: Línea 17:
=== En el servidor ===
=== En el servidor ===


<nowiki>
<code>PROYECTO="proyecto" ; ssh git@aws.luisantolin.com "cd /var/git && mkdir \"${PROYECTO}\".git && cd \"${PROYECTO}\".git && git init --bare"</code>
ssh git@aws.luisantolin.com
cd /var/git
mkdir proyecto.git
cd proyecto.git
git init --bare</nowiki>


Listo, tenemos un repositorio vacio y listo para recibir datos.
Listo, tenemos un repositorio vacio y listo para recibir datos.
Línea 32: Línea 28:
git add -A
git add -A
git commit -m "Initial commit. Everything was in a dot."  
git commit -m "Initial commit. Everything was in a dot."  
git remote add origin git@aws.luisantolin.com:/var/git/proyecto.git
git remote add origin git@aws.luisantolin.com:/var/git/<nombreproyecto>.git
git push origin master</nowiki>
git push origin master
git push --set-upstream origin master  </nowiki>


Listo, tenemos nuestro proyecto local enviado al servidor.
Listo, tenemos nuestro proyecto local enviado al servidor.
Línea 41: Línea 38:
  <nowiki>
  <nowiki>
cd <donde queramos que se cree la raiz de nuestro nuevo proyecto>
cd <donde queramos que se cree la raiz de nuestro nuevo proyecto>
git clone git@aws.luisantolin.com:/var/git/proyecto.git
git clone git@aws.luisantolin.com:/var/git/<nombredeproyecto>.git
cd proyecto</nowiki>
cd proyecto</nowiki>


Línea 48: Línea 45:
== Trabajo diario ==
== Trabajo diario ==


1. Traemos la ultima version del repositorio
# Traemos la ultima version del repositorio: <code>git fetch</code>
 
# Vemos los cambios: <code>git diff master origin/master</code>
<nowiki>git fetch</nowiki>
# Incorporamos los cambios: <code>git merge origin/master</code>
 
# Hacemos nuestros cambios
2. Vemos los cambios
# Añadimos los ficheros cambiados al "staging area": <code>git add -A</code>
# Hacemos el commit de los cambios en el repositorio local: <code>git commit -m "descripcion de commit"</code>
# Enviamos los cambios al servidor: <code>git push</code>


<nowiki>git diff master origin/master</nowiki>
Nota: <code>fetch</code> y <code>merge</code> se pueden hacer juntos con <code>git pull origin master</code>


3. Incorporamos los cambios
Y vuelta a empezar :)


<nowiki>git merge origin/master</nowiki>
== Diferencias con Subversion ==


El paso 2 y 3 se pueden hacer de uno solo con <code>git pull origin master</code>
Tropezaré en estas mil veces.


4. Hacemos nuestros cambios
'''Lo que en Subversion era un solo paso (commit) aqui son tres: add, commit y push.'''


5. Añadimos los ficheros cambiados al "staging area"
Git tiene el concepto de "staging area", un area intermedia donde tengo que ir anotando los cambios explicitamente antes de hacer commit. De modo que desde que yo cambio un fichero hasta que esta disponible en el repositorio son 3 pasos:


<nowiki>git add -A</nowiki>
# add lo anota como cambiado en la "staging area", totalmente local
# commit agrupa todos los cambios de la "staging area" y les da un ID y una descripcion, ¡aun todo local!
# push envia el commit al repositorio remoto


6. Hacemos el commit de los cambios en el repositorio local
'''En Git todo son ramas, fetch se trae los cambios a lo que llama "rama remota" dentro del repositorio local'''


<nowiki>git commit -m "descripcion de commit"</nowiki>
Al traer cambios del repositorio también hay mas pasos que en Subversion. Aqui el concepto nuevo (y confuso en mi modesta opinión) es que se trae los cambios a una rama remota local, nombre confuso donde los haya, quizá queda mas claro decir una rama remota del repositorio local. Es decir que en el repositorio local tenemos dos tipos de ramas, las locales, y una copia de las remotas (se ven todas con <code>git branch -a</code>.


7. Enviamos los cambios al servidor
# fetch trae los cambios desde el repositorio a una rama remota de nuestro repositorio local.
# merge incorpora los cambios, de cualquier rama a cualquier rama, en este caso de la remota a la local


<nowiki>git push</nowiki>
[[Category:Tips]]
[[Category:Tecnologia]]
[[Category:Linux]]

Revisión actual - 18:15 21 oct 2020

Anotaciones para ayudarme a migrar de Subversion a Git. La intención es documentar los flujos básicos de trabajo con Git, y anotar las principales diferencias de concepto que voy encontrando.

Mi uso es para un solo desarrollador en multiples ordenadores. Es una configuracion muy sencilla (para lo que Git es capaz de hacer).

Asunciones:

  • Servidor Git: aws.luisantolin.com
  • Usuario Git con intercambio de claves SSH ya configurado: git
  • Una sola rama, la de por defecto: master
  • Una solo repositorio remoto por proyecto, el de por defecto: origin
  • Nombre de proyecto: proyecto

Proyecto nuevo

Creando un proyecto nuevo. Git usa un repositorio por proyecto.

En el servidor

PROYECTO="proyecto" ; ssh git@aws.luisantolin.com "cd /var/git && mkdir \"${PROYECTO}\".git && cd \"${PROYECTO}\".git && git init --bare"

Listo, tenemos un repositorio vacio y listo para recibir datos.

En el cliente

cd <directorio raiz del proyecto>
git init .
git add -A
git commit -m "Initial commit. Everything was in a dot." 
git remote add origin git@aws.luisantolin.com:/var/git/<nombreproyecto>.git
git push origin master
git push --set-upstream origin master  

Listo, tenemos nuestro proyecto local enviado al servidor.

En otro cliente

cd <donde queramos que se cree la raiz de nuestro nuevo proyecto>
git clone git@aws.luisantolin.com:/var/git/<nombredeproyecto>.git
cd proyecto

Listo, ya podemos trabajar en este otro cliente.

Trabajo diario

  1. Traemos la ultima version del repositorio: git fetch
  2. Vemos los cambios: git diff master origin/master
  3. Incorporamos los cambios: git merge origin/master
  4. Hacemos nuestros cambios
  5. Añadimos los ficheros cambiados al "staging area": git add -A
  6. Hacemos el commit de los cambios en el repositorio local: git commit -m "descripcion de commit"
  7. Enviamos los cambios al servidor: git push

Nota: fetch y merge se pueden hacer juntos con git pull origin master

Y vuelta a empezar :)

Diferencias con Subversion

Tropezaré en estas mil veces.

Lo que en Subversion era un solo paso (commit) aqui son tres: add, commit y push.

Git tiene el concepto de "staging area", un area intermedia donde tengo que ir anotando los cambios explicitamente antes de hacer commit. De modo que desde que yo cambio un fichero hasta que esta disponible en el repositorio son 3 pasos:

  1. add lo anota como cambiado en la "staging area", totalmente local
  2. commit agrupa todos los cambios de la "staging area" y les da un ID y una descripcion, ¡aun todo local!
  3. push envia el commit al repositorio remoto

En Git todo son ramas, fetch se trae los cambios a lo que llama "rama remota" dentro del repositorio local

Al traer cambios del repositorio también hay mas pasos que en Subversion. Aqui el concepto nuevo (y confuso en mi modesta opinión) es que se trae los cambios a una rama remota local, nombre confuso donde los haya, quizá queda mas claro decir una rama remota del repositorio local. Es decir que en el repositorio local tenemos dos tipos de ramas, las locales, y una copia de las remotas (se ven todas con git branch -a.

  1. fetch trae los cambios desde el repositorio a una rama remota de nuestro repositorio local.
  2. merge incorpora los cambios, de cualquier rama a cualquier rama, en este caso de la remota a la local