Sin compromisos
git commit -a -m “Esto es un cambio”
Git @canubeproject 12
¿Y tú de quién eres?
Generar pareja de claves y subirla
https://help.github.com/articles/generating-ssh-keys
Git @canubeproject 13
Empujando a los cambios
Git push origin master
Git @canubeproject 14
Antes de la existencia de GitHub
mkdir repo; cd repo; git init; touch README; git
add README; git commit -m “1st”
[Crear repo en GitHub]
git remote add origin
https://github.com/username/myrepo.git
Git @canubeproject 15
Mientras puede haber habido
algún cambio
git pull origin master
Git @canubeproject 16
¡Hay un conflicto!
Aparece en el texto y se corrige
+ commit + push
Git @canubeproject 17
Hay que ponerse a trabajar
Los “issues” de GitHub están integrados con el git
Git @canubeproject 18
Hitos y asuntos
Los issues o tickets se organizan en hitos
(milestones)
Git @canubeproject 19
No se cierra hasta que no se
acaba
git commit -m “references o fixes o closes #xxx”
Git @canubeproject 20
Hay muchas más cosas
●
Fetch
●
Merge
●
Rebase
●
checkout
Git @canubeproject 21
Creando un fork
Y, además, añadiendo repositorios upstream (y
fusionando con el original)
Git @canubeproject 22
Integración continua
Github está integrado con Travis y permite hacer
integración continua
Git @canubeproject 23
Eso es todo
¿Alguna pregunta?
Git @canubeproject 24
Notes de l'éditeur
En general, desarrollo de software, pero también cualquier tipo de desarrollo
En general, desarrollo de software, pero también cualquier tipo de desarrollo
En general, desarrollo de software, pero también cualquier tipo de desarrollo
En general, desarrollo de software, pero también cualquier tipo de desarrollo
GitHub no es el único sistema gratuito (freemium, en realidad) de alojamiento de Git. También está Google Code, Sourceforge, Bitbucket (que te permite diferentes repos privados) o Gitorius (basado en un backend libre). Lo que ocurre es que GitHub es simplemente el mejor y por eso también el más popular.
Lo fácil es instalarlo en Linux, pero también puedes instalarlo para cualquier otro tipo de cliente y sistema de desarrollo. Por supuesto, también en emacs http://blog.art-of-coding.eu/using-git-and-github-in-emacs/ También hay clientes de Git no específicos de GitHub, pero no permiten aprovechar todas estas capacidades.
Pero generalmente se usa como si fuera un sistema centralizado. Eso no quiere decir que no se pueda usar como uno quiera. En general, se puede sincronizar ocn cualquier ordenador al que se tenga (o al que se dé) acceso
Repositorio = repo para los amigos. No hace falta crear un repositorio para empezar a trabajar, nos pueden añadir a otro. Pero empecemos así. Cuando diga si se va a crear un README, decidle que sí. En GitHub los proyectos son públicos por omisión. Sólo permiten un repositorio privado en las cuentas de pago o bien para enseñanza.
Mi repositorio de té abierto. Cada cual tendrá el suyo. Es importante tener en cuenta que un repositorio puede tener diferentes URLs con diferentes privilegios. Si se usa un cliente de Git o Github habrá que configurarlo con la dirección del repositorio y usar “clone” del menú. Esa es también la estructura de las órdenes de git Git + comando + url + rama Hay, por otro lado, diferentes formas de clonar un repositorio. En este caso lo hace usando ssh por debajo, lo que te permite más adelante subir los cambios sin necesidad de introducir la clave. Dependiendo del URL los privilegios serán diferentes. Por ejemplo, git:// será un clon de sólo lectura y https:// no te permitirá más adelante usar la clave pública/privada para enviar info fácilmente. Esta línea de órdenes se puede usar tanto en Linux como para un cliente que se crea en Windows de línea de órdenes similar al bash de Linux.
Comodines y toda la pesca. Puedes añadir directorios completos. Todo esto se puede hacer también desde el interfaz gráfico con apunta y dale al botón, claro.
Un commit es un punto de cambio en el repositorio local, igual que todos los comandos anteriores. En ningún caso hemos subido nada a github todavía. Sólo establecemos un punto de control para volver en caso necesario.
Se puede usar la autentificación por https, pero es un poco latosa porque hay que meter el nombre de usuario y clave de cada vez. No es necesario en caso de que uses un cliente github.
Se trata de enviarlo al repositorio. En general, puedes hacerlo a cualquier repositorio, pero en este caso lo haremos al GitHub. Con git push en la mayor parte de los casos es suficiente. Por otro lado, un repositorio puede tener varios orígenes. Si estás trabajando con GitHub y quieres, por ejemplo, subir las cosas a Gitorious no tienes más que hacer Git remote add origin [URL] http://caiustheory.com/adding-a-remote-to-existing-git-repo
Para más info y comentarios, https://help.github.com/articles/create-a-repo En vez de https puede que sea más conveniente usar alguna de las otras URLs. En todo caso, la que te dé el repositorio. Generalmente, por cierto, es más cómodo hacerlo de otra forma, pero esta es la forma también de tener un repo local sin necesidad de subirlo a ningún sitio.
Git pull es git fetch + git merge http://stackoverflow.com/questions/292357/whats-the-difference-between-git-pull-and-git-fetch
Los conflictos se producen en los ficheros binarios o cuando dos usuarios han modificado el mismo grupo de líneas. Se puede producir tanto en el pull como en el push, siempre que haya habido una divergencia. Se puede liar todavía más parda, pero lo dejamos para más adelante.
Un issue es simplemente una orden de trabajo. En principio es para una persona, pero se puede en el mismo mencionar a otras personas mediante @username; esas personas recibirán notificaciones (creo)
No es obligatorio, pero es conveniente. U hito puede ser un hito del proyecto, o una tarea. El principal problema es que, a diferencia de otros sistemas de gestión más avanzados (como redmine) no se organizan de forma jerárquica, con lo que la cosa está (relativamente) limitada.
Esos commits aparecen en la página web y se pueden, a su vez, comentar o actuar de alguna forma sobre ellos. Este tipo de commits aparecen con un tipo de letra especial.
https://help.github.com/articles/fork-a-repo
Cada vez que se hace un push se puede activar un “trigger” que hace una serie de cosas: pasar tests, por ejemplo. Se puede usar http://travis-ci.org o cualquier otro servicio de integración continua (en tu propio servidor o en la nube)