Hola!, On 2/11/10 10:48 AM, Skript Ke wrote: > Perdón... ahora entiendo... > > Que sepas que yo empecé con Perl y la Web picado con el notepad de > Windows 95 y a mucha honra :-) después me pase al Ultraedit, > posteriormente linux y Geany, y ahora ando con eclipse con un plugin > para Git (EGit) que he estado probando con Git instalado de forma > local. > Pues, si ya tienes el codigo en un repo git, lo unico que tienes que hacer es agregar el que has creado en github (ahi te dara la url de lectura-escritura):
git remote add [shortname] [url] En tu caso podria ser: > git remote add origin [email protected]:skriptke/nes.git y ahora solo te queda subir el codigo que ya tienes en el repo local: > git push origin master (he asumido que estas en la rama por defecto) y ya esta, una vez subido, solo haces "push" y "pull" (mirate tambien rebase) para mantener el proyecto en sincro con el repositorio "de origen" que seria el de github. Las ventajas, como te comentaba salva, son muchas, pero sobre todo, que facilita la colaboración. El flujo normal es que si alguien se interesa en tu proyecto, lo "forkee" y modifique su rama segun se vaya involucrando, cuando tenga algo que crea que debe ir a tu rama (la principal) te enviara un "pull request" que tu decidiras si aceptas. A partir de ese momento, probablemente aparezca gente que colabore asiduamente y github te permite que les des permisos en tu rama para que ellos mismos se acepten los pull request o para que directamente trabajen sobre ese mismo arbol, en definitiva, con git todas son ramas remotas (tu disco, github o un fork) que mantienen el punto de contacto y que mezclan commit a commit. El ultimo concejo, para que sea facil de gestionar, es importante que cada cammit sea lo mas chico posible, este bien documentado (el mensaje del commit) y ataque de a un problema a la vez, asi luego es mas facil hacer los merges sin tantos conflictos ;) Otra cosa, ya que estas justo en un topic bastante desarrollado hoy en dia, yo te recomiendo que te mires muy de cerca otros frameworks que estan haciendo cosas similares porque seguro que puedes utilizar partes y tecnicas comunes: http://github.com/rafl/catalyst-runtime http://github.com/kraih/mojo http://github.com/bestpractical/jifty Creo que estos son los mas destacados hoy en dia, por lo que yo conozco, creo que mojo es muy interesante. Eso es todo por el momento, si necesitas ayuda con algo par subir tu codigo a github comentalo por aqui e intentaremos ayudarte ;) Saludos, Diego > ------------------------------------------------------------------------ > > *De:* pancho horrillo <[email protected]> > *Para:* Lista de correo de Madrid Perl Mongers <[email protected]> > *Enviado:* jue,11 febrero, 2010 14:32 *Asunto:* Re: [Madrid-pm] Nes > PerlDigüeño > > On Thu, Feb 11, 2010 at 05:15:06AM -0800, Skript Ke wrote: >> Creo que me he explicado mal, en sourceforge no están más que los >> paquetes zip para descargarse, no uso subversion ni ninguna otra >> utilidad de sourceforge, lo tengo instalado de forma local en mi >> equipo, a la espera de subirlo GitHub, que no se ha hecho por los >> motivos que te comentaba. > [...] > > Creo que que Salva estaba respondiendote a: > > Skrip Ke thus spoke: >> [...] así que aún tengo los fuentes en mi equipo, > > > Salvador Fandiño thus spoke: >> eeeh... no, esto no me encaja. >> >> Usar un sistema de control de versiones no es algo que haces a >> posteriori de cara a publicar tu trabajo. >> >> Un sistema de control de versiones es una herramienta que tu mismo >> utilizas para ayudarte al desarrollo. >> > > Para que quede claro, la recomendación es desarrollar con un sistema > de control de versiones, no picar código «a pelo». > > > . Git funciona muy bien, y su modelo distribuído permite hacer > diabluras. > > . Mercurial es similar a git. > > . Y si quieres aferrarte al pasado, Subversion + SVK es otra > posibilidad. > > Pero trabajar «a pelo» tiene grandes riesgos, y reduce la > trazabilidad de las decisiones que tomas a medida que el código va > evolucionando. > > Se puede contar algo brevemente de sistemas de control de versiones > en la próxima reunión si alguien tiene interés. > > Saludos! > > -- pancho horrillo > > To be conscious that you are ignorant is a great step to knowledge. > > Benjamin Disraeli _______________________________________________ > Madrid-pm mailing list [email protected] <mailto:[email protected]> > http://mail.pm.org/mailman/listinfo/madrid-pm > > > > _______________________________________________ Madrid-pm mailing > list [email protected] http://mail.pm.org/mailman/listinfo/madrid-pm _______________________________________________ Madrid-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/madrid-pm
