Introducing 

Prezi AI.

Your new presentation assistant.

Refine, enhance, and tailor your content, source relevant images, and edit visuals quicker than ever before.

Loading…
Transcript

Configurar git

Comprometiendo el repositorio

Local

git stash

Pila de trabajo temporal

Git trae una herramienta llamada git config que te permite obtener y establecer variables de configuración que controlan el aspecto y funcionamiento de Git. Estas variables pueden almacenarse en tres sitios distintos:

Archivo /etc/gitconfig: Contiene valores para todos los usuarios del sistema y todos sus repositorios. Si pasas la opción --system a git config, lee y escribe específicamente en este archivo.

Archivo ~/.gitconfig file: Específico a tu usuario. Puedes hacer que Git lea y escriba específicamente en este archivo pasando la opción --global.

Archivo config en el directorio de git (es decir, .git/config) del repositorio que estés utilizando actualmente: Específico a ese repositorio. Cada nivel sobrescribe los valores del nivel anterior, por lo que los valores de .git/config tienen preferencia sobre los de /etc/gitconfig.

En sistemas Windows, Git busca el archivo .gitconfig en el directorio $HOME (C:\Documents and Settings\$USER para la mayoría de usuarios). También busca en el directorio /etc/gitconfig, aunque esta ruta es relativa a la raíz MSys, que es donde quiera que decidieses instalar Git en tu sistema Windows cuando ejecutaste el instalador.

git connfig [key] [value]

add & commit

Agregarlos a la zona del Staged;

git add <filename>

git add *

Este es el primer paso básico.

Para pasar de la zona del Index al repositorio;

git commit -m "Commit message"

Ahora el HEAD, repositorio local, se ha posicionado en el último commit, pero aún no en tu repositorio remoto, si lo tuvieras.

FUNCIONAMIENTO

git config user.name "rafa.thefull"

git config --global user.email "rafa.thefull@gmail.com"

Comenzar

git config --system core.editor emacs

[ --bare ]

git init

Creación de un repositorio local .git

git config --system merge.tool meld

Ignorar ficheros

Crear un fichero .gitignore para que git los ignore

CHECKOUT SUBVERSION/CVS

git clone

Clonar repositorio local

git clone /path/to/repository

Clonar un repositorio remoto

git clone username@host:/path/to/repository

Comprometiendo el repositorio remoto

Envío de cambios

El HEAD de tu copia local a tu repositorio

remoto ejecuta;

git push origin master

Reemplaza master por la rama a la cual desees enviar tus cambios.

Si no has clonado un repositorio existente necesitas agregarlo con

git remote add origin

Ahora puede subir tus cambios al repositorio remoto selecionado

Podemos ver los repositorios remotos con

git remote -v

Recuperamos toda la información del repositorio remoto;

git fetch

Revisando la historia : git log

Diversos comandos

git log -p -2 Muestra diferencias de los 2 últimos commits

git log --stat Muestra estadísticas.

git log --oneline --graph --decorate . Muestra árbol con sus ramas

Deshaciendo cosas:

git commit --amend Reescribe tu último commit

git reset HEAD <file> Deshaciendo la preparación de un archivo

git checkout -- <file> Deshaciendo la modificación de un archivo

Etiquetas

Control de versiones distribuido

  • Existe un repositorio centralizado de todo el código, del cual es responsable un único usuario (o conjunto de ellos).
  • Se facilitan las tareas administrativas a cambio de reducir flexibilidad, pues todas las decisiones fuertes (como crear una nueva rama) necesitan la aprobación del responsable.

DIFERENTES FORMAS EN QUE PODEMOS TRABAJAR

Rafa Carmona 2013

git tag -a v10 Añade nueve etiqueta

git tag -f v10 Mueve aqui la etiqueta v10

git tag -l 'v1.4.*' Lista las etiquetas que cumpla v1.4.*

git show v1.5 Muestra información sobre la etiqueta v1.5

git tag -a v1.2 9fceb02 Pon la etiqueta en el commit 9fceb02

git push origin [tagname] Sube la etiqueta al repositorio remoto

git push origin --tags Sube todas las etiquetas al repositorio remoto

Una forma de trabajar distribuida, similar a GitHub

Alias

  • Cada usuario tiene su propio repositorio.
  • No es necesario tomar decisiones centralizadamente.
  • Los distintos repositorios pueden intercambiar y mezclar revisiones entre ellos.
  • Enfocados a la gestión de ramas
  • Trabajar sin Red
  • Rápido, Eficiente, Seguro , Flexible
  • Git, no es una evolución, es una revolución en tratar la información.

git config --global alias.unstage 'reset HEAD --'

git unstage fileA, es lo mismo que vimos anteriormente.

Repositorio Centralizado

similar a CVS /SubVersion

Desarrollo kernel Linux

Buenas prácticas

Url de interés

RAMAS

ESTADO INICIAL

git branch <rama>; git checkout <rama>

git checkout -b <rama> <refs>

Solucionar bug v1.0

Las ramas son utilizadas para desarrollar funcionalidades aisladas unas de otras. La rama master es la rama por "defecto" cuando creas un repositorio.

https://www.git-scm.com/book

Establecer normas de funcionamiento

http://www-cs-students.stanford.edu/~blynn/gitmagic/intl/es/index.html

http://cheat.errtheblog.com/s/git

La ramas nacen ,crecen, se reproducen , fusionan y/o mueren, como los seres vivos ;-)

http://blogs.collab.net/subversion/a-look-at-git-cvs-svn

  • git checkout v1.0
  • git branch fixbug
  • git checkout fixbug
  • git commit

http://librosweb.es/pro_git/

Partimos de un esquema inicial

Donde podemos ver:

* rama master

* rama cliente_vip

* tags v1.0 y v1.1

http://gitref.org/index.html

http://git-scm.com/book/es/Empezando

http://ndpsoftware.com/git-cheatsheet.html

1 Mejora , 1 rama

Rama creada, desde master:

* brown1

git checkout -b brown1 master

https://github.com/

https://bitbucket.org/

http://xthefull.blogspot.com.es/2012/11/gitblit-un-gestor-de-repositorios-en.html

Servicios de repositorios

¿ Que me aporta el usar una rama ?

Pongamos un ejemplo funcional:

1.- Nos piden una nueva funcionalidad

2.- En medio de esa nueva funcionalidad , nos puelven a pedir, urgentemente, que arreglemos en la versión 1.0, liberada un bug.

3.- Todavía no hemos arreglado el bug, y hay otra orden de que nuestro principal cliente, necesita que de su versión adaptada, incorporar una seria de modificaciones.

4.-Despues, tendremos que "Escribir la historia..."

git branch -d <rama>

Usando MERGE

http://nvie.com/posts/a-successful-git-branching-model/ Abajo está la traducción.

http://jesuslc.com/2012/11/24/una-buena-manera-de-afrontar-la-ramificacion-branching-en-git/

Usando REBASE o MERGE

Y fusionamos , con la master, e incorporando las mejoras de brown y de nuestro cliente VIP.

Visualizando la historia

Muy Interesantes

  • git checkout master
  • git branch -d brown1
  • git branch -d fixbug

http://rogerdudler.github.com/git-guide/index.es.html

  • git checkout master
  • git merge brown1
  • git merge cliente_vip

http://xthefull.blogspot.com.es/2013/01/creando-comandos-en-git.html

Usando REBASE

http://bicosyes.com/2008/06/diferencias-entre-rebase-y-merge-en-git/

Merge y Rebase

http://cambrico.net/git-control-de-versiones/rebase-en-git

  • git checkout brown1
  • git rebase master
  • git checkout master
  • git rebase brown1
  • git merge cliente_vip
Learn more about creating dynamic, engaging presentations with Prezi