Hola buenas, vengo a darme de alta en la lista de gente cool.
Yo uso github mucho en el trabajo, nuestro workflow hace un uso intensivo de menciones (@boss), issues (#32) para los mensajes de commit y además solemos hacer pull requests, aunque menos. Solemos hacernos una rama para cada issue (un poco bestia, cuando son bugs pequeños los hacemos en la rama principal de la versión y ya).
Luego tengo ahí subido mierdas de la Universidad, proyectos a medio empezar, etc etc
Una de las cosas que más me gusta es lo fácil que es aportar con github a un proyecto, alguna vez me he clonado uno y he arreglado alguna tontería y es facilísimo enviar un pull request si te haces el fork. De hecho una vez lo mandé todo desde la web, editando el archivo directamente en Github :_D
Si usáis Sublime Text 2, el plugin de Git va bastante bien, y para Eclipse no puedo dejar de recomendar eGit.
Gracias a los dos #30 #31.
Es la primera vez que uso esto y me pierdo un poco. Todavia no sé para que sirve el concepto de branch y que utilidad tiene.
Me lo explicais para tontos? Ty 
#34 Perfecta la explicacion 
#33 pues tienes 2378734 tutoriales por ahí, busca porque te lo van a explicar mejor que nosotros, pero en resumen:
Cada uno de los commits de un repositorio es una "foto" del estado de tu proyecto en un instante determinado. Una serie de commits, uno tras otro, se pueden imaginar como una "linea del tiempo" (en la que puedes ir adelante y atrás, a gusto.)
(A partir de ahora voy a seguir con la métafora de la linea del tiempo.)
Por defecto existe una rama/branch (o linea del tiempo) principal llamada "master", que es la linea temporal principal de tu repositorio. La convención es que en esta rama SIEMPRE haya código finalizado, es decir, que se pueda compilar y funcione de acuerdo a las features implementadas hasta el momento. Hay mucha gente que sólo trabaja con master y le va de perlas (de hecho es lo más normal empezar con Git sin complicarte con ramificaciones para ir aprendiendo.)
De esta línea del tiempo puedes sacar nuevas lineas del tiempo PARALELAS sin que interfieran unas con otras, es decir, es como si tuvieras VARIAS lineas del tiempo en tu proyecto, independientes entre sí. En cualquier momento puedes viajar a la linea del tiempo que quieras de tu proyecto y cualquier cambio que hagas en ella sólo se reflejará en esa rama. Si en algún momento decides que el trabajo ha merecido la pena puedes realizar un merge (fusionar) una rama con otra.
(Las ramas avanzan de izquierda a derecha en este esquema, es decir, el tiempo es el eje horizontal.)
Cada uno de los "puntos gordos" en el esquema es un commit, una "foto" del proyecto. A medida que avanza hacia la derecha se añaden commits, es decir, evoluciona. Como ves, del segundo commit de "Master" sale una rama "Release". Ese commit pertenece a AMBAS ramas porque la foto del proyecto es LA MISMA. En el momento en el que se realiza un commit en "Release" puedes ver que la rama se separa de forma paralela. Fíjate también que en el commit 5 de "Master" se reunifica con los cambios en "Release" y por tanto deja de haber linea del tiempo paralela. De hecho ese commit SÓLO indica los cambios sobre "master" (que es la rama hacia la que se está fusionando.)
Los cartelitos azules son "head", lo que quiere decir que son el "presente" de la linea temporal indicada. Piensa que una rama no es más que una etiqueta que apunta hacia un commit concreto para poder decir en cualquier momento "quiero ir a Master", o lo que es lo mismo "quiero ir al head de Master", o lo que es lo mismo "quiero ir al último commit realizado en Master".
Como curiosidad: en SVN la rama principal, lo que sería "master" en Git (por covención, no por obligación) se llama trunk (tronco.) Piénsalo, tiene sentido que del tronco salgan ramas
Para todo lo demás: http://learn.github.com/p/branching.html
#33 Son líneas de cambio (ramas) sobre el tronco. Se realizan para desarrollar unidades funcionales en "paralelo" sin tocar los huevos al resto del personal (no suelen ser necesarias cuando vas solo a lo cowboy, pero sigue siendo best practice). Una vez finalizado se integra en el tronco haciendo un merge que en el mejor de los casos será automático aunque no es rara la necesidad de intervención manual especialmente cuando los desarrollos en rama se alargan demasiado en el tiempo.
Este es mi Github: https://github.com/radykal-com
Ahora mismo sólo tengo un repo, estoy migrando mi blog a Zend Framework 2 (aún en rc), es público ^^
Hay una cosa que no entiendo, como puede usar github una empresa, si el codigo que realizan es publico. Osea, el producto que vendan no sacarian provecho de el... no?
tiene que haber algo que se me escapa xD
GitHub tiene servicios de pago que incluyen repositorios privados (échale un ojo a los Business Plans en https://github.com/plans ). Los repositorios públicos en cambio son gratuitos y si no te importa poner tu código a disposición del resto del mundo son una buena opción. Por otro lado sitios como Github son un punto de encuentro para desarrolladores de software libre y se basan precisamente en que cualquiera pueda tener acceso a tu código para estudiarlo, modificarlo, utilizarlo etc.
cierto cierto, perdon. Es que llevo varios dias mirando la web sin hacer registro y me parecia raro eso... xDD
#40 También tienes alternativas como Bitbucket que ofrecen repositorios privados sin tener que pagar.
Os dejo mi github y mi bitbucket, aunque ahora uso más el segundo:
https://github.com/AthalberthH/
https://bitbucket.org/AthalberthH/
Lo que por mucho que leo sigo sin enterarme es si a la hora de modificar un solo archivo ya se debe hacer un commit o lo haría cuando terminara de modificar varios, o cuando implemente alguna novedad.
#49 En mi opinión y experiencia, lo mejor es que un commit sea un fix de algo, un nuevo feature o algo así, con todos los archivos afectados. Cuanto más localizado mejor, un commit que es simplemente "Multiple fixes" o algo así, dice poco, o si tiene una biblia de mensaje con todo lo que arregla es casi igual de malo. Piensa que alguien igual tiene que leer el log, revisarlo o lo que sea.
Si en un mismo archivo cambias 5 funciones y cada uno arregla un fallo y no has ido haciendo add+commit de cada fix, puedes hacer commits de trozos (chunks) del archivo.
#50 ¿Y si tienes una feature a medias? ¿Le haces commit o esperas al día siguiente a terminarla para hacerlo?
#51 Depende. Si es un feature muy complejo y lo vas haciendo por partes que funcionan independientemente, sí.
Si es algo con interfaz de usuario yo suelo hacer primero un mock con los controles y a lo mejor datos falsos, luego añadir interacción y luego engancharle el controlador que le va a dar los datos del servidor o lo que sea.
Si trabajas tú solo hazlo como quieras, al fin y al cabo tú te lo guisas y tú te lo comes. Si trabajas con un equipo poneos de acuerdo en cómo debería hacerse.
#52 Perfecto, me ha quedado mucho más claro. Ahora otra duda más, el README se usa solo para una pequeña descripción y la Wiki para la documentación, ¿no?
¡Gracias!
para el que no lo conozca, un script muy util para deploys de git
http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/
#49 #50 Pienso que para este caso en particular Git, con el tema del branching, te permite crear una branca en la que trabajarías tú sólo y en la que pudieras hacer los commits que quieras, de tal forma que no "ensucias" las brancas en las que trabaja más gente.
Igualmente lo mejor es ponerse de acuerdo con el equipo para diseñar el workflow.
#56 branca? ¡Rama!
En cualquier caso las vas a ensuciar a la que hagas el merge. Hay gente que propone rebasear commits para darle una unidad lógica antes de hacer el push+merge final.
#57 Pero si haces el merge haciendo otro commit sobre la rama (perdón, síntoma de bilingüismo) en principio te queda limpia. No sé si me explico. Yo por ejemplo uso SourceTree como cliente y me da esa opción. No sé si alguno más o el propio Git lo permite, pero haciéndolo de esta forma la rama sobre la que haces el merge queda limpia.
#58 no puede ser. Tu haces el merge y puedes trazar hacia atrás (es la gracia de un VCS) la rama de origen. Si vienes de una rama "sucia" esos commits están sucios para siempre.
