[Madrid-pm] Nes PerlDigüeño

Skript Ke skriptke en yahoo.es
Vie Feb 12 03:50:41 PST 2010


Ya lo he subido GitHub, no se si bien...

Gracias.




________________________________
De: Diego Kuperman <diego en kuperman.com.ar>
Para: Lista de correo de Madrid Perl Mongers <madrid-pm en pm.org>
Enviado: jue,11 febrero, 2010 16:06
Asunto: Re: [Madrid-pm] Nes PerlDigüeño

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 git en github.com: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 <pancho en pancho.name>
> *Para:* Lista de correo de Madrid Perl Mongers <madrid-pm en pm.org> 
> *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 Madrid-pm en pm.org <mailto:Madrid-pm en pm.org> 
> http://mail.pm.org/mailman/listinfo/madrid-pm
> 
> 
> 
> _______________________________________________ Madrid-pm mailing
> list Madrid-pm en pm.org http://mail.pm.org/mailman/listinfo/madrid-pm
_______________________________________________
Madrid-pm mailing list
Madrid-pm en pm.org
http://mail.pm.org/mailman/listinfo/madrid-pm



      
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.pm.org/pipermail/madrid-pm/attachments/20100212/c774bfb5/attachment.html>


Más información sobre la lista de distribución Madrid-pm