¿Demasiado experto para hacer commits en Git?
Los commits de Git sirven como documentación y facilitan la colaboración. Los desarrolladores de Salesforce enfrentan desafíos con Git y el control de versiones.
Por Randalyn Hill-Coffer·Revisado por el equipo de Blue Canvas··3 min de lecturaCon este artículo, descubre la importancia de hacer commits frecuentes en Git, cómo sirven de documentación y facilitan la colaboración, y por qué son especialmente relevantes para los desarrolladores de Salesforce.
Estas son nuestras 5 conclusiones clave:
- Hacer commits frecuentes en Git documenta dónde ocurrió una falla y por qué, y facilita una mejor colaboración entre colegas.
- Los commits continuos te permiten ver qué pensaba alguien y cómo llegó a una solución de forma natural y reveladora.
- Los commits de Git también sirven como puntos de referencia útiles que te ayudan a entender cómo provocaste una falla.
- Los desarrolladores de Salesforce enfrentan un doble desafío con Git y el control de versiones, y es importante registrar los cambios declarativos a intervalos regulares, tal como lo harías con un cambio en Apex.
- Herramientas como Blue Canvas pueden ayudarte al hacer commits automáticos en tu repositorio para los cambios declarativos.

https://xkcd.com/1597/
Git es excelente. Lo hemos dicho una y otra vez aquí en Blue Canvas. Pero puede ser difícil.
Estábamos explorando HackerNews el otro día y encontramos un enlace a esta práctica guía rápida de Git. Lo que nos llevó a otra, guía rápida interactiva de Git y a la historieta de arriba (¡gracias a los comentaristas de HN!).
Mientras revisábamos la sección de comentarios, encontramos esta opinión bastante común:
Creo que, aunque Git sería excelente como biblioteca, su experiencia de usuario como programa de uso directo podría mejorar: una buena experiencia de usuario implica que las cosas simples sean simples y las complicadas sean posibles, pero ahora mira el siguiente flujo de trabajo “básico” de git:… Quiero que git haga seguimiento de este archivo. Sí, a veces necesito agregar ciertas líneas, archivos, etc. Mantengan git add, commit y push. Pero incluyan un “git update” o algo así para principiantes (y para el 99% de los usos)
Más adelante, el comentarista agregó:
En la práctica, solo hago commit cuando está listo (compila y pasa las pruebas). Entonces, ¿por qué harías commit sin hacer push (a menos que estés sin conexión)?
Ahora bien, no decimos que este comentarista no tenga un punto interesante; francamente, hemos pasado por lo mismo (somos lo suficientemente perezosos como para usar una herramienta como SCM Breeze).
Aun así, registra tus cambios pronto y con frecuencia es una «regla de oro del control de versiones». ¿Por qué? ¿Debería serlo? ¿Con qué frecuencia debería un desarrollador hacer commits?
Esta pregunta es de especial interés para los desarrolladores de Salesforce, que tienen tantas personas involucradas haciendo cambios en sus organizaciones: desarrolladores, administradores, gerentes de producto, analistas de negocio, etc.

Hacer commits es una forma de documentar
Hacer commits pequeños y frecuentes es una de las principales propuestas de valor de Git. Sin embargo, muchos sienten que hacer commits con frecuencia es molesto. Puede interrumpir tu concentración, lo que no resulta agradable. Aun así, creemos que deberías hacer commits con frecuencia. ¿Con qué frecuencia? Eso depende de ti. No creemos que hacer commits deba convertirse en una carga, pero deberías hacer tantos como tenga sentido. Comprender el valor que aportan puede hacer que te resulte más llevadero detenerte y hacerlos.
A largo plazo, hacer commits de cambios pequeños ahorra tiempo. Al igual que las pruebas unitarias, gran parte de su valor se obtiene en el futuro. Como aprendimos de la charla de Kevin Poorman en Dreamforce, en promedio, el 75% del trabajo en un proyecto de software es mantenimiento. ¿Cuántas veces has pasado horas revisando código Apex escrito hace mucho tiempo por otra persona, intentando corregir un error que acabas de introducir? ¿Quién agregó esta línea? ¿Cuándo? ¿Y en qué contexto? ¡Si tan solo alguien hubiera escrito documentación!

Bueno, los commits de Git pueden servir como documentación de dónde falló algo y por qué. Los commits continuos te permiten ver qué pensaba alguien y cómo llegó a una solución, de forma natural y reveladora. Los commits de Git también sirven como puntos de control útiles que te ayudarán a entender cómo provocaste una falla. Además, facilitan una mejor colaboración entre colegas.
Como Jeff Atwood acertadamente dijo en 2008:
Si aprendes a hacer commits desde el principio y con frecuencia, tendrás tiempo de sobra para recibir comentarios, integrar y revisar durante el proceso. Y quién sabe: quizá también logres pulir esa joya de código final que buscabas.
Los desarrolladores de Salesforce y git commit
Esto surge de vez en cuando porque los desarrolladores de Salesforce enfrentan un doble desafío con Git y el control de versiones. Incluso los equipos más diligentes deben tener en cuenta los cambios declarativos en su organización. ¿Se están registrando estos cambios en el control de versiones? ¿Y con qué frecuencia? Muchos equipos hacen respaldos diarios o semanales en Git. Esto está bien, pero es como dejar pasar un día o una semana entera antes de hacer un segundo commit.
Es importante registrar los cambios declarativos a intervalos regulares, tal como lo harías con un cambio en Apex. Herramientas como Blue Canvas pueden ayudarte al hacer commits automáticos de los cambios declarativos en tu repositorio. Regístrate en nuestra beta para obtener más información.



