Session 2: Git in Practice

Why Git is the Foundation

Everything in modern DevOps starts with Git:

Git gives us three superpowers:

1. Traceability — who changed what, when, and why
2. Reversibility — something broke? Roll back to the last working version
3. Collaboration — multiple people can work on the same codebase without stepping on each other

The rule: Git is the single source of truth for everything.

Git Basics Recap

The Flow

Working Directory → Staging Area → Local Repo → Remote Repo
    (edit)          (git add)     (git commit)   (git push)

Essential Commands

The .gitignore File

Never commit these to Git:

• Secrets and API keys (.env, credentials.json)
• Dependencies (node_modules/, venv/)
• Compiled binaries and build artifacts
• IDE settings (.vscode/, .idea/)
• OS files (.DS_Store, Thumbs.db)

⚠️ Once a secret is in git history, it’s there forever — even if you delete the file. If you accidentally commit a secret, rotate it immediately.

Branching Strategies

There are two main schools of thought on how teams use branches.

GitFlow

main ─────────────────●────────────────●──────────
                     ↑                ↑
release/1.0 ────────●   release/2.0 ──●
                    ↑                ↑
develop ──●──●──●──●────●──●──●──●──●
          ↑  ↑  ↑               ↑
feature/  ●  ●  ●          feature/
login   cart search         payments

How it works:

• main — always matches production
• develop — integration branch for features
• feature/* — one branch per feature, created from develop
• release/* — cut from develop when ready to ship
• hotfix/* — emergency fixes, branched from main

When to use GitFlow:

• Scheduled releases (e.g., every 2 weeks)
• Multiple versions to support simultaneously
• Large teams that need branch isolation

GitHub Flow

main ──●──────●──────────●──────────●──────
       ↑      ↑          ↑          ↑
      feature  feature   feature   feature
      branch   branch    branch    branch
      (PR→merge→deploy)

How it works:

• main is always deployable
• Create a feature branch off main for every change
• Open a PR when your work is ready for review
• CI runs on the PR, teammates review
• Merge to main → deploy immediately

When to use GitHub Flow:

• Teams that deploy continuously
• Simpler projects that don’t need multiple release versions
• Teams new to branching strategies (easy to learn)

Key difference from GitFlow: No develop, release, or hotfix branches. Just main + feature branches. Much simpler.

Trunk-Based Development

main ──●──●──●──●──●──●──●──●──●──●──●──●──
       ↑     ↑        ↑        ↑
      feature  feature  feature  feature
      (hours)  (1 day)  (hours)  (hours)

How it works:

• Everyone works off main
• Short-lived feature branches (hours to 1-2 days, not weeks)
• Merge back to main frequently
• Main is always deployable

When to use Trunk-Based:

• Fast CI/CD environments
• Teams with good test coverage
• When using feature flags for incomplete work

Comparison

Recommendation: GitHub Flow is a great default for most teams. Trunk-based is ideal if your team has strong test coverage and wants maximum speed. GitFlow only if you need scheduled releases or multiple supported versions.

Pull Request Workflow

The pull request (PR) is where code quality happens.

The Lifecycle

1. Create branch     git checkout -b feature/add-login
2. Make changes      (write code, commit)
3. Push branch       git push -u origin feature/add-login
4. Open PR           (on GitHub)
5. Review + CI       (teammate reviews, pipeline runs)
6. Merge             (if review ✅ AND pipeline ✅)

What Makes a Good PR

Code Review is NOT Gatekeeping

Code review serves three purposes:

1. Catch bugs before they reach production
2. Share knowledge across the team
3. Maintain quality standards

Think of it as a collaborative conversation, not an approval gate.

Branch Protection Rules

Set these up on your main branch in GitHub:

• ✅ Require pull request reviews (at least 1 reviewer)
• ✅ Require CI status checks to pass before merging
• ✅ No direct pushes to main
• ✅ Require branches to be up to date before merging

This ensures nothing reaches main without being reviewed and tested.

Merge Conflicts

Merge conflicts happen when two people change the same lines in the same file. They’re normal — not something to fear.

When You See a Conflict

<<<<<<< HEAD
const port = 3000;
=======
const port = 8080;
>>>>>>> feature/change-port

• Above ======= — your current branch’s version
• Below ======= — the incoming branch’s version

How to Resolve

1. Open the conflicted file
2. Decide which version to keep (or combine both)
3. Remove the conflict markers (<<<<<<<, =======, >>>>>>>)
4. Stage and commit

git add <resolved-file>
git commit -m "resolve merge conflict in config"

How to Avoid Conflicts

Writing Good Commit Messages

Your commit history tells the story of your project. Make it readable.

Format

<type>: <short summary in imperative mood>

Optional longer description explaining the why,
not the what.

Types

Examples

✅ feat: add user authentication endpoint
✅ fix: prevent crash when database connection times out
✅ refactor: extract validation logic into shared module

❌ fixed stuff
❌ WIP
❌ asdfgh
❌ update

Hands-On Activity

Setup (5 minutes)

1. Create a new GitHub repository
2. Enable branch protection on main:
   • Require PR reviews
   • Require status checks (we’ll add CI in Session 3)

Practice PR Workflow (15 minutes)

1. Clone the repo locally
2. Create a feature branch: git checkout -b feature/add-readme
3. Add a README.md with a project description
4. Commit and push: git push -u origin feature/add-readme
5. Open a PR on GitHub with a clear description
6. Review each other’s PRs (pair up)
7. Merge the PR

Resolve a Merge Conflict (10 minutes)

1. Two people edit the same line in the same file on different branches
2. First person merges their PR
3. Second person’s PR now has a conflict
4. Resolve the conflict, push, and merge

Session 2 Key Takeaways

1. Git is the single source of truth for everything in DevOps
2. Trunk-based development is recommended for most teams — keep branches short-lived
3. Pull requests are where quality happens — keep them small and focused
4. Branch protection ensures nothing reaches main without review and passing tests
5. Merge conflicts are normal — keep branches short to minimize them
6. Good commit messages tell the story of your project

Discussion Questions

Think about these before next session:

1. What branching strategy does your team currently use? Is it working?
2. How large are your typical PRs? Could they be smaller?
3. Do you have branch protection rules set up? If not, what’s stopping you?
4. How long do feature branches live before being merged?

Next Session: CI/CD - The Backbone — what continuous integration and continuous delivery really mean, GitHub Actions, pipeline best practices, and deployment strategies.