Version Control with Git: Tracking and Collaborating on Security Scripts

Why Version Control Matters in Cybersecurity

Security professionals write scripts constantly — for log parsing, vulnerability scanning, incident response automation, and more. Without a disciplined way to track changes, a single bad edit can break a critical tool at the worst possible moment. Version control lets you record every change, understand why it was made, roll back to a working state, and collaborate safely with teammates. Git is the industry-standard distributed version control system used across nearly every professional environment.

Core Git Concepts

Repository (repo): A directory that Git monitors. It contains your files and a hidden `.git` folder that stores the full history of every change.

Commit: A snapshot of your files at a specific moment. Every commit has a unique hash, an author, a timestamp, and a message explaining what changed and why.

Branch: An independent line of development. The default branch is usually called `main`. You create branches to develop new features or fixes without disturbing working code.

Merge: Combining changes from one branch into another. When two branches modify the same part of a file differently, Git cannot decide automatically — this is a merge conflict that you must resolve manually.

Remote: A version of the repository hosted elsewhere (for example, on GitHub or an internal server). You push local commits to a remote and pull others' commits down.

Essential Git Commands

| Command | What it does |

|---|---|

| `git init` | Creates a new local repository in the current directory |

| `git status` | Shows which files are modified, staged, or untracked |

| `git add <file>` | Stages a file for the next commit |

| `git commit -m "message"` | Records staged changes with a descriptive message |

| `git log --oneline` | Displays commit history in a compact format |

| `git branch <name>` | Creates a new branch |

| `git checkout <name>` | Switches to a branch (or use `git switch <name>`) |

| `git merge <name>` | Merges the named branch into the current branch |

| `git diff` | Shows line-by-line differences not yet staged |

Always run `git status` before you commit. It prevents you from accidentally staging files that should stay out of the repo.

Protecting Secrets with .gitignore

One of the most serious mistakes in security scripting is committing credentials, API keys, or passwords into a repository — even a private one. Once a secret enters Git history it is extremely difficult to remove completely, and if the repo is ever made public or cloned carelessly, the secret is exposed.

A `.gitignore` file tells Git to ignore specific files or patterns. Place it in the root of your repository. Example entries for a security-script project:

```

secrets.env

*.env

config.local.py

.DS_Store

__pycache__/

*.pyc

```

Create `.gitignore` before your first commit so the ignored files are never tracked. If you accidentally commit a secret, treat the credential as compromised immediately — rotate it regardless of any Git history cleanup you attempt.

Writing Good Commit Messages

A commit message is documentation for your future self and your teammates. A weak message like `fix stuff` tells no one anything useful. A strong message explains what changed and why:

• `Add port-scan script with configurable timeout`
• `Fix false-positive in log-parser regex for IPv6 addresses`
• `Refactor credential handling to read from environment variables`

Using the imperative mood (`Add`, `Fix`, `Refactor`) is the widely accepted convention in professional projects.

Branching and Merging Workflow

A common workflow for a security script project:

1. Work on `main` for stable, tested code.

2. Create a feature branch: `git branch add-alerting` then `git checkout add-alerting`.

3. Make commits on the feature branch.

4. When the feature is tested, merge it back: `git checkout main` then `git merge add-alerting`.

Resolving Merge Conflicts

When a merge conflict occurs, Git marks the affected file like this:

```

<<<<<<< HEAD

print("Alert: threshold exceeded")

=======

print("WARNING: limit reached")

>>>>>>> add-alerting

```

The section between `<<<<<<< HEAD` and `=======` is what the current branch has. The section between `=======` and `>>>>>>>` is what the incoming branch has. You decide which version is correct (or combine them), delete all the marker lines, save the file, then run `git add <file>` and `git commit` to complete the merge.

Always test the resolved file before committing the fix. In a security context, a broken script may mean missed alerts or a failed automated response.

Lab Safety and Best Practices

• Never commit secrets. Use `.gitignore` and environment variables.
• Work inside your Ubuntu VM only. Do not push lab repositories to public hosting services during the course without instructor approval.
• Use descriptive commit messages — this is evaluated in the pass/fail check.
• Back up your VM snapshot before the merge-conflict exercise so you have a clean state to return to if needed.