Version Control with Git: Foundation of Team Collaboration

Why Version Control?

Imagine you are working on a control program for a production line. You add a new feature -- and suddenly the system stops working. You want to roll back to the version that was running correctly, but you saved over the original file. Everything is gone.

This scenario happens daily at companies that do not use version control. The solution is Git -- a system that records every change you make to your code and lets you return to any point in the project's history.

Why Git matters for industrial software:

• Safety: if something breaks, revert immediately to the last stable version
• Traceability: know who changed what, when, and why
• Collaboration: multiple developers work on the same project without conflicts
• Documentation: the commit history forms automatic documentation
• Compliance: required by industrial standards such as IEC 62443

Git: Core Concepts

Git works on a simple idea: every change you save is called a commit (a snapshot). The project history is a chain of these snapshots.

Installation:
  Windows: download from https://git-scm.com
  Linux:   sudo apt install git
  macOS:   brew install git

Initial setup:
  git config --global user.name "Your Name"
  git config --global user.email "you@example.com"

Key concepts:

Daily Workflow with Git

Creating a New Repository

# Start a new project
mkdir plc-monitor
cd plc-monitor
git init

# Or clone an existing one
git clone https://github.com/company/plc-monitor.git

The Basic Cycle: Edit, Stage, Commit

# 1. Edit files (write code)
#    ... modify sensor_reader.py ...

# 2. Review changes
git status              # which files changed?
git diff                # what are the exact changes?

# 3. Stage files
git add sensor_reader.py          # single file
git add src/                      # entire directory
git add .                         # everything

# 4. Commit with a clear message
git commit -m "feat: add temperature threshold alarm for CNC line"

# 5. View history
git log --oneline

Writing good commit messages:

Pattern: <type>: <short description>

feat:     new feature
fix:      bug fix
docs:     documentation update
refactor: restructure without behavior change
test:     add tests

Examples:
  feat: add vibration monitoring for pump station
  fix: correct temperature unit conversion from F to C
  docs: update API reference for alarm endpoints

Branches: Parallel Development Lines

Suppose you want to add a new feature to the monitoring system but do not want to risk breaking the stable version. The solution: create a branch.

# List branches
git branch

# Create and switch to a new branch
git checkout -b feature/predictive-alerts

# You are now on the new branch -- all changes are isolated here
# ... write code ...
git add .
git commit -m "feat: implement moving average for predictive alerts"

# Switch back to main
git checkout main

# Merge the branch when done
git merge feature/predictive-alerts

Team branching strategy:

main          stable production code
  |
  +-- develop     daily development branch
       |
       +-- feature/alarm-queue     new feature
       +-- feature/dashboard-v2    another feature
       +-- fix/sensor-timeout      bug fix

Merge Conflicts

A conflict occurs when two people edit the same line in the same file. Git cannot decide which version is correct -- it asks you to resolve it:

# When a conflict occurs, Git marks the file like this:
def get_max_temperature():
<<<<<<< HEAD
    return 85.0  # version on your current branch
=======
    return 90.0  # version from the merged branch
>>>>>>> feature/new-limits

Resolving a conflict:

# 1. Open the file and choose the correct version (or combine both)
# 2. Delete the conflict markers (<<<<, ====, >>>>)
# 3. Test the code
# 4. Stage the file and complete the merge

git add config.py
git commit -m "fix: resolve temperature limit conflict, use 90°C per new spec"

Tips to avoid conflicts:

• Pull updates daily: git pull
• Keep commits small and focused
• Avoid two people editing the same file simultaneously
• Communicate with the team about shared areas

Working with GitHub

GitHub (or GitLab or Bitbucket) is a remote server that stores a copy of your repository and facilitates collaboration:

# Link your local repository to GitHub
git remote add origin https://github.com/company/plc-monitor.git

# Push code
git push origin main

# Pull updates from the team
git pull origin main

Pull Request Workflow

A Pull Request (PR) is the structured way to add changes -- one person writes the code, another reviews it before merging:

1. Create a branch:        git checkout -b feature/alarm-history
2. Write code and commit:  git commit -m "feat: add alarm history view"
3. Push the branch:        git push origin feature/alarm-history
4. Open a Pull Request on GitHub
5. Teammates review and comment
6. Address feedback and push again
7. On approval: merge into main

Essential Git Commands

The .gitignore File: What Not to Track

Some files should never be in the repository -- passwords, build artifacts, large sensor data files:

# Environment files (passwords and keys)
.env
secrets.toml

# Build artifacts
target/
__pycache__/
*.pyc

# Large data files
data/*.csv
logs/

# IDE settings
.vscode/
.idea/

Git is not just a tool -- it is a fundamental engineering practice. In industrial software where a mistake can halt an entire production line, the ability to track every change and revert to any previous point is not a luxury -- it is a necessity.