Iñigo GonzálezIT Operations · Infra

GuíasGuides · Nivel 2Level 2

Git: poner los scripts del equipo bajo control de versionesGit: putting the team's scripts under version control

Repositorio, ramas, commits que se entienden, pull request con revisión, y lo que nunca debe entrar en un repo.Repository, branches, commits that make sense, pull requests with review, and what must never go into a repo.

Nivel 2Level 2 · GitGit · 3 min3 min read · ActualizadoUpdated 21 oct 202621 Oct 2026

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:

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

2. Primer repositorio

bash · tu equipo
git clone https://git.contoso.com/it/it-scripts.gitcd it-scriptsmkdir -p powershell bashcp ~/scripts/check-server.sh bash/git status --short?? .gitignore?? bash/check-server.shgit add .gitignore bash/check-server.shgit 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.

bash · tu equipo
git switch -c fix/umbral-disco-90nano bash/check-server.shgit diff-DISK_MAX=85+DISK_MAX=90git 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

bash · chuleta
# ponerte al día antes de empezargit switch main && git pull# ver qué ha cambiado y quiéngit log --oneline -10git log -p bash/check-server.sh# deshacer un cambio local que no has confirmadogit restore bash/check-server.sh# volver a una versión anterior de un fichero sin perder el historialgit 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.

What you'll get

The team's PowerShell and Bash scripts stop living in C:\Scripts\final_v3_good.ps1 and move into a repository with history, review and one place everyone pulls from. With the minimal flow an IT team really uses.

Before you start

  • Git installed (git --version). On Windows, Git for Windows; on Linux it ships or installs with apt/dnf.
  • An account on your company's Git server (GitHub, GitLab, Azure DevOps, Bitbucket) and an empty repository created by whoever administers it: it-scripts.
  • Your name and email set once: git config --global user.name "Laura Prado" and git config --global user.email laura.prado@contoso.com.

1. What never goes into a repo

Before the first push, because afterwards it is very hard to get out of the history:

  • Passwords, API keys, tokens, certificates with private keys. They live in the secrets manager and the script reads them from an environment variable or a vault.
  • Files with personal data (AD exports with emails, user lists).
  • Anything generated: logs, output/, result CSVs.

A .gitignore at the root prevents it:

.gitignore
# results and temporary filesoutput/*.log*.csv# secrets: never*.pfx*.key.envsecrets.*

2. First repository

bash · your device
git clone https://git.contoso.com/it/it-scripts.gitcd it-scriptsmkdir -p powershell bashcp ~/scripts/check-server.sh bash/git status --short?? .gitignore?? bash/check-server.shgit add .gitignore bash/check-server.shgit commit -m "bash: daily check of disk, load and services"[main 3f2a9c1] bash: daily check of disk, load and services 2 files changed, 58 insertions(+)git push -u origin main

git status before every add shows what you are about to push. A blind git add . is how a .pfx slips in.

3. Changes with a branch and a review

The flow that stops a half-finished change reaching production: every change on a branch, pushed, reviewed by someone in a pull request (merge request in GitLab) and merged into main.

bash · your device
git switch -c fix/disk-threshold-90nano bash/check-server.shgit diff-DISK_MAX=85+DISK_MAX=90git commit -am "check-server: disk threshold to 90% (agreed in the 20/10 meeting)"git push -u origin fix/disk-threshold-90remote: Create a pull request for 'fix/disk-threshold-90':remote:   https://git.contoso.com/it/it-scripts/pull/new/fix/disk-threshold-90

In the pull request, a colleague sees the diff, comments and approves. Then main is updated and everyone runs git pull. Branch names that help: fix/…, feat/…, docs/….

4. Commits that make sense

A commit is one change with one reason. The message: what changes and why, in one line under 70 characters, in the imperative or present tense. If more is needed, a blank line and the detail.

  • Good: vpn-check: retry 3 times before warning (false positives on the Milan VPN).
  • Bad: changes, fix, v2.

If what you are about to write is "various changes", that is several commits.

5. What you'll do every week

bash · cheat sheet
# catch up before startinggit switch main && git pull# see what changed and who did itgit log --oneline -10git log -p bash/check-server.sh# undo a local change you haven't committedgit restore bash/check-server.sh# bring back an earlier version of a file without losing historygit checkout 3f2a9c1 -- bash/check-server.sh

git push --force and git reset --hard rewrite or delete. If you don't know exactly what they do, don't use them on main; ask for help and it is fixed in two minutes. Almost everything in Git is recoverable; what gets lost is lost by forcing.

Next steps

  • Protect main on the server: no direct push, pull request required with one approval.
  • Add an automatic check to the pull request: shellcheck for Bash, PSScriptAnalyzer for PowerShell.
  • In Level 3 you'll see Jenkins and CI/CD: the repository is what triggers tests and deployments.

Is something missing, or different in your environment? Get in touch and I'll fix it.

Tech Career Lab · newsletter

¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.

Apúntate y llévate las 33 ideasSign up and get the 33 ideas →