Git: poner los scripts del equipo bajo control de versiones

Qué vas a conseguir

Que los scripts de PowerShell y Bash del equipo dejen de vivir en C:\Scripts\final_v3_bueno.ps1 y pasen a un repositorio con historial, revisión y un sitio único del que todo el mundo tira. Con el flujo mínimo que un equipo de IT usa de verdad.

Antes de empezar

• Git instalado (git --version). En Windows, Git for Windows; en Linux viene o se instala con apt/dnf.
• Una cuenta en el servidor de Git de tu empresa (GitHub, GitLab, Azure DevOps, Bitbucket) y un repositorio vacío creado por quien administre: it-scripts.
• Tu nombre y correo configurados una vez: git config --global user.name "Laura Prado" y git config --global user.email laura.prado@contoso.com.

1. Lo que nunca entra en un repo

Antes de la primera subida, porque después es muy difícil sacarlo del historial:

• Contraseñas, claves de API, tokens, certificados con clave privada. Van en el gestor de secretos y el script los lee de una variable de entorno o de un vault.
• Ficheros con datos de personas (exports de AD con correos, listados de usuarios).
• Lo que se genera: logs, output/, CSV de resultados.

Un .gitignore en la raíz lo evita:

# resultados y temporalesoutput/*.log*.csv# secretos: nunca*.pfx*.key.envsecrets.*

2. Primer repositorio

›git clone https://git.contoso.com/it/it-scripts.git›cd it-scripts›mkdir -p powershell bash›cp ~/scripts/check-server.sh bash/›git status --short?? .gitignore?? bash/check-server.sh›git add .gitignore bash/check-server.sh›git commit -m "bash: comprobación diaria de disco, carga y servicios"[main 3f2a9c1] bash: comprobación diaria de disco, carga y servicios 2 files changed, 58 insertions(+)›git push -u origin main

git status antes de cada add te enseña qué vas a subir. git add . a ciegas es como se cuela un .pfx.

3. Cambios con rama y revisión

El flujo que evita que un cambio a medias llegue a producción: cada cambio en una rama, se sube, alguien lo revisa en un pull request (merge request en GitLab) y se fusiona a main.

›git switch -c fix/umbral-disco-90›nano bash/check-server.sh›git diff-DISK_MAX=85+DISK_MAX=90›git commit -am "check-server: umbral de disco al 90% (acordado en la reunión del 20/10)"›git push -u origin fix/umbral-disco-90remote: Create a pull request for 'fix/umbral-disco-90':remote:   https://git.contoso.com/it/it-scripts/pull/new/fix/umbral-disco-90

En el pull request, el compañero ve el diff, comenta y aprueba. Después, main se actualiza y todos hacen git pull. Nombres de rama que ayudan: fix/…, feat/…, docs/….

4. Commits que se entienden

Un commit es un cambio con un motivo. El mensaje: qué cambia y por qué, en una línea de menos de 70 caracteres, en imperativo o en presente. Si hace falta más, una línea en blanco y el detalle.

• Bien: vpn-check: reintentar 3 veces antes de avisar (falsos positivos en la VPN de Milán).
• Mal: cambios, arreglo, v2.

Si lo que vas a escribir es "varios cambios", son varios commits.

5. Lo que harás cada semana

# ponerte al día antes de empezar›git switch main && git pull# ver qué ha cambiado y quién›git log --oneline -10›git log -p bash/check-server.sh# deshacer un cambio local que no has confirmado›git restore bash/check-server.sh# volver a una versión anterior de un fichero sin perder el historial›git checkout 3f2a9c1 -- bash/check-server.sh

git push --force y git reset --hard reescriben o borran. Si no sabes exactamente qué hacen, no los uses sobre main; pide ayuda y se arregla en dos minutos. Casi todo en Git se recupera; lo que se pierde es por forzar.

Siguientes pasos

• Protege main en el servidor: sin push directo, pull request obligatorio con una aprobación.
• Añade una comprobación automática al pull request: shellcheck para Bash, PSScriptAnalyzer para PowerShell.
• En el Nivel 3 verás Jenkins y CI/CD: el repositorio es lo que dispara las pruebas y los despliegues.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.