Git Para Profesionales Salesforce: Por Qué Necesitas Aprenderlo
"Yo configuro todo desde la interfaz, ¿para qué necesito Git?" Esa es la pregunta que más escucho de profesionales Salesforce — tanto Admins como Developers. Y la respuesta corta es: porque el mercado cambió, y quien no se adapte se va a quedar atrás.
Sé que suena fuerte, pero es la realidad. Git dejó de ser "cosa de developers" hace rato. Hoy, el control de versiones es una habilidad fundamental para cualquier profesional que trabaje con Salesforce. En este artículo, te voy a explicar por qué, y cómo esto impacta directamente tu carrera.
La pesadilla de trabajar sin control de versiones
Antes de hablar de Git, déjame pintarte un escenario que tal vez conoces bien.
Pasaste el día entero configurando un Flow complejo en una sandbox. Lo probaste, lo validaste, todo funcionando. Al día siguiente, un compañero hizo un refresh de la sandbox sin avisar. ¿Tu trabajo? Se esfumó.
O también: estás haciendo deploy a producción usando Change Sets. El deploy rompe algo. ¿Y ahora? ¿Qué cambio causó el problema? ¿Quién tocó qué? ¿Cuándo? Sin historial, descubrir eso se vuelve una investigación policial.
Estos escenarios son reales y pasan todos los días en equipos que no usan control de versiones. No es cuestión de "si" te va a pasar — es cuestión de "cuándo".
Otros clásicos que ya presencié:
- Archivo_final_v2_FINAL_corregido.zip — ¿quién no? Nombrar archivos con versiones manuales es un caos que escala rápidamente.
- "¿Quién tocó esto?" — en equipo, nadie sabe quién cambió qué, cuándo ni por qué.
- Sobrescribieron el código que funcionaba — sin historial, no hay manera de volver atrás.
Tip: El control de versiones es como un "Ctrl+Z infinito" para todo tu proyecto, con la capacidad de ver exactamente qué cambió, cuándo y por quién. Si alguna vez perdiste trabajo por falta de trazabilidad, Git es la solución.
Qué es Git y por qué domina el mercado
Git es un sistema de control de versiones distribuido, creado en 2005 por Linus Torvalds (el mismo creador de Linux). Más del 95% de los desarrolladores en el mundo usan Git, y GitHub — la principal plataforma para alojar repositorios Git — ya superó los 200 millones de repositorios.
En la práctica, Git registra cada cambio que haces en tus archivos. Cada "punto de guardado" se llama commit, e incluye la fecha, el autor y una descripción de lo que se hizo. Puedes volver a cualquier versión anterior, comparar cambios y trabajar en paralelo con otras personas sin conflictos.
Y lo más importante: Git es 100% gratuito y open source.
Git en el contexto Salesforce: SFDX y el modelo source-driven
"Está bien, Marina, ¿pero cómo se aplica Git a Salesforce específicamente?"
La respuesta es directa: los metadatos de Salesforce son código. Cada campo personalizado, cada Flow, cada layout, clase Apex y Lightning Web Component está representado por archivos XML y código fuente que pueden — y deben — ser versionados.
Salesforce DX (SFDX) revolucionó la forma en que desarrollamos para Salesforce al introducir el modelo source-driven. El cambio es fundamental:
| Antes (Modelo Clásico) | Ahora (Source-Driven / SFDX) |
|---|---|
| Cambios directo en la org | Código fuente versionado en Git |
| Deploy manual vía Change Sets | Deploy automatizado vía CLI (sf deploy) |
| Sin historial de cambios | Cada cambio es un commit rastreable |
| Colaboración vía correo/hoja de cálculo | Pull Requests y Code Review en GitHub |
| Sandbox = fuente de la verdad | Git = fuente de la verdad |
En el modelo source-driven, el repositorio Git es la fuente de la verdad de tu proyecto. La org es solo un reflejo de lo que está en el repositorio. Esta inversión cambia completamente la forma en que los equipos trabajan.
DevOps Center: Git nativo en la plataforma
La propia Salesforce reconoció que Git es esencial y lanzó el DevOps Center — una herramienta nativa que integra control de versiones directamente en la plataforma.
El DevOps Center usa GitHub (u otros providers) por debajo. Cada work item crea una branch automáticamente. Acompañas el estado de cada cambio visualmente, haces reviews y promueves cambios entre ambientes con trazabilidad total — todo esto dentro de Salesforce.
Lo que esto significa en la práctica: saber Git ya no es un diferencial para profesionales Salesforce. Es un prerrequisito. El DevOps Center literalmente no funciona sin un repositorio Git conectado.
.gitignore y .forceignore: qué versionar en proyectos Salesforce
Un error común de quienes están empezando con Git en proyectos Salesforce es versionar todo. No todos los archivos deben ir al repositorio.
La carpeta force-app/ contiene todo el código fuente y los metadatos — esa sí debe ser versionada. En cambio, las carpetas .sfdx/ y .sf/ son cachés locales de la CLI, que se regeneran automáticamente. node_modules/ contiene dependencias que se recrean con npm install.
Un .gitignore básico para proyectos SFDX debe incluir:
- .sfdx/ y .sf/ (caché de la CLI)
- node_modules/ (dependencias)
- *.log (archivos de log)
- .DS_Store y Thumbs.db (archivos del sistema operativo)
- .vscode/ y .idea/ (configuraciones personales del editor)
- coverage/ (resultados de pruebas locales)
Además, los proyectos SFDX tienen el .forceignore — que define lo que la CLI ignora en los deploys y retrieves. Son complementarios: .gitignore controla Git, .forceignore controla la CLI de Salesforce.
Tip importante: configura el .gitignore y el .forceignore ANTES del primer commit. Los archivos que ya fueron commiteados no se eliminan automáticamente por el .gitignore — tendrías que limpiar manualmente con git rm --cached.
Por qué hasta los Admins necesitan aprender Git
Sé que muchos Admins leen esto pensando: "pero yo no escribo código, esto no es para mí." Voy a ser directa: sí lo es.
- Admins — el DevOps Center requiere conocimiento de Git. Muchas empresas ya piden Git en el proceso de selección para Admins.
- Developers — absolutamente obligatorio. Sin Git, no puedes trabajar en ningún equipo profesional.
- Consultores — necesitan entender el flujo para orientar a clientes en la adopción de DevOps y buenas prácticas.
- Architects — definen la estrategia de branching, CI/CD y gobernanza del repositorio.
Los números lo confirman: 72% de las vacantes Salesforce ya piden Git/GitHub, y los profesionales con Git en el currículum tienen 3x más oportunidades en entrevistas. La mayoría de los profesionales Salesforce aún no domina Git — y es exactamente ahí donde está la oportunidad para quien lo aprenda ahora.
El impacto real en tu carrera
Saber Git no es solo sobre usar una herramienta. Es sobre demostrar madurez profesional. Cuando un reclutador ve Git y GitHub en tu perfil, el mensaje es claro: esta persona trabaja de forma profesional, sabe colaborar en equipo y entiende buenas prácticas de desarrollo.
Ya vi profesionales Salesforce ser promovidos y recibir mejores ofertas simplemente por saber implementar un flujo básico de Git en proyectos de la empresa. Es una habilidad que te diferencia de la mayoría — y que, honestamente, no es tan difícil de aprender como parece.
La inversión de tiempo es pequeña comparada con el retorno. En pocas semanas de práctica consistente, ya puedes usar Git con confianza en el día a día.
Cómo empezar
Si llegaste hasta aquí convencido de que necesitas aprender Git, el siguiente paso es simple: empieza. No necesitas dominar todo de una vez. Lo básico — repositorio, commits, branches, push, pull — ya va a transformar la forma en que trabajas.
En la Rangers League Academy, creamos el curso Git & GitHub Esencial exactamente para profesionales Salesforce que quieren aprender Git desde cero, con ejemplos prácticos orientados al ecosistema. El curso cubre desde los fundamentos hasta configuración de .gitignore para proyectos SFDX y estrategias de branching para equipos Salesforce. Si quieres dar ese paso en tu carrera, es por ahí que recomiendo empezar.
Preguntas Frecuentes
¿Necesito saber programar para aprender Git?
No. Git es una herramienta de control de versiones, no un lenguaje de programación. Los Admins que trabajan con configuración, Flows y metadatos pueden (y deben) usar Git para rastrear sus cambios. El DevOps Center, de hecho, fue creado pensando en profesionales que no escriben código.
¿Git y GitHub son lo mismo?
No. Git es el software de control de versiones que corre en tu computadora. GitHub es una plataforma en línea para alojar repositorios Git y colaborar con otras personas. Piénsalo así: Git es el motor, GitHub es la carretera. Existen alternativas a GitHub, como GitLab y Bitbucket, pero todas usan Git por debajo.
¿Cuánto tiempo toma aprender lo básico de Git?
Con dedicación consistente, en 2 a 3 semanas ya puedes usar Git con confianza en el día a día. Los comandos esenciales — init, add, commit, push, pull, branch, merge — cubren el 90% de lo que vas a necesitar. El resto lo aprendes conforme la necesidad aparece.
¿El DevOps Center reemplaza la necesidad de saber Git?
No. El DevOps Center simplifica el flujo visual, pero usa Git por debajo. Cuando algo sale mal — y eventualmente va a salir mal — necesitas entender lo que está pasando en el repositorio para resolverlo. Saber Git te da autonomía para diagnosticar problemas y no depender de otra persona para desbloquear tu trabajo.
