Introducing
Your new presentation assistant.
Refine, enhance, and tailor your content, source relevant images, and edit visuals quicker than ever before.
Trending searches
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.
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.
git config user.name "rafa.thefull"
git config --global user.email "rafa.thefull@gmail.com"
git config --system core.editor emacs
[ --bare ]
Creación de un repositorio local .git
git config --system merge.tool meld
Crear un fichero .gitignore para que git los ignore
CHECKOUT SUBVERSION/CVS
Clonar repositorio local
git clone /path/to/repository
Clonar un repositorio remoto
git clone username@host:/path/to/repository
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
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
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
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
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
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
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
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
¿ 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..."
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/
Y fusionamos , con la master, e incorporando las mejoras de brown y de nuestro cliente VIP.
Visualizando la historia
http://rogerdudler.github.com/git-guide/index.es.html
http://xthefull.blogspot.com.es/2013/01/creando-comandos-en-git.html
http://bicosyes.com/2008/06/diferencias-entre-rebase-y-merge-en-git/
http://cambrico.net/git-control-de-versiones/rebase-en-git