Barrapunto

Mejorando el flujo de trabajo de ClearCase con Git [turbodad.com]

El plural de branch es branches

Eclipse trae algo que proporciona alguna de estas funcionalidades de forma integrada. Se llama Local History:

http://help.eclipse.org/help33/index.jsp?topic=/or g.eclipse.platform.doc.user/concepts/concepts-17a. htm [eclipse.org]

Hay mucha información por ahí sobre ventajas de los sistemas distribuidos de control de versiones (SCV en castellano, mejor que VCS), y no creo que esta entrada sea de lo mejor para profundizar en el tema, aunque son ideas interesantes. Para quien quiera encontrar referencias sobre ello, hay por ejemplo muuuucha información en el wiki de Git [git.or.cz] (incluso una transcripción [git.or.cz] de la mencionada polémica charla de Torvalds donde se metía con SVN y CVS).

Para la gente que ande un poco perdida en Git (que es lo único de lo que puedo hablar): Git lo empezó a desarrollar Linus Torvalds para cubrir el hueco dejado por el programa privativo BitKeeper que se utilizaba antiguamente para el control de versiones del kernel de Linux y al principio estaba considerado como extremadamente difícil de usar. El equipo de desarrollo actual ha hecho un trabajo muy duro desde hace un par años para acercarlo a cualquier desarrollador, y tanto es así que la interfaz más popular creada para simplificar su uso, Cogito, se ha dejado de desarrollar debido a que todos sus comandos, supuestamente más simples, ya tenían un equivalente en Git sin ninguna complicación. Los comandos tradicionales de Git que actúan a bajo nivel se llaman Plumbing (fontanería), pero el uso normal se debe hacer con los bonitos comandos conocidos como Porcelain. Todo está convenientemente documentado en la documentación de Git, que es justamente la versión web de las páginas del manual del comando. El que quiera aprender, puede empezar con alguno de los varios tutoriales y guías que hay ahí e ir cambiando entre ellos si se atasca.

No he probado a utilizar Git en Windows, y actualmente debe de haber varias versiones diferentes para elegir (hasta que se estabilice el desarrollo dando prioridad a la versión nativa), así que no sé cómo se hará ahí (cualquier opinión es bienvenida). En Linux, es aconsejable instalar la versión más reciente, aunque sea un pelín más complicada de instalar, en vez de arriesgarse a usar una versión antigua proporcionada por un paquete de la distribución, debido a los muchos detalles que cuidan las versiones actuales (más coloreado de sintaxis, mejores mensajes de ayuda, mayor coherencia entre los comandos, algunos más potentes, algunos más fáciles de usar, etc.). En Mac OS X debería funcionar bien porque muchos desarrolladores del proyecto lo usan, y en BSD y Solaris seguramente también.

El único hilo de esta noticia que no habla de aspectos técnicos es el de la ortografía. Todos los demás hablan de aspectos técnicos así que no se a que viene tu queja. Y por cierto el mensaje al que respondes y que según tú es el más técnico de todos es el de alguien que no ha usado un SCV distribuido o que no lo ha entendido.

Además de eso esta noticia habla de los SCV distribuidos en general, no de Git aunque lo nombre. Si quieres saber las diferencias entre Git y Mercurial aquí tienes unas cuantas. [rockstarprogrammer.org]

En cuanto al mensaje al que respondes, los commits locales no están pensados para substituir los commits al repositorio central. Tu a un repositorio central no puedes ir haciendo commits cada pocos pasos que realices porque si te cargas algo molestas a todo el mundo. Hasta ahora lo que se hacía era desarrollar en tu PC sin hacer commits hasta que no estabas muy seguro de que no ibas a romper nada, ahora lo que se hace es ir haciendo commits locales de los que nadie se va a enterar.

Por lo demás en Git puedes hacer que se ejecute un script al hacer commit, merge o lo que sea. Puedes hacer que este script te haga un backup o lo que tu prefieras.