Overview

Connect Git branches and pull requests to automated checks and deployment workflows.

Git CI/CD is about controlling change safely. Git becomes much easier when you check state often, make small commits, and understand whether a command changes files, history, or only your view of the repository.

Core Ideas

• Use Git CI/CD with git status nearby so you always know the current state.
• Separate working tree changes, staged changes, commits, and remote branches in your mind.
• Use small commits so review, rollback, and history reading stay simple.
• Prefer safe commands such as revert when other people may share the branch.

Step by Step

1. Run git status before starting Git CI/CD.
2. Perform one command or small command group.
3. Run git status or git log again to see exactly what changed.
4. Write down whether the working tree, staging area, commit history, or remote changed.

Beginner Explanation

Git CI/CD covers Git tools used when repositories, assets, security, automation, or branch coordination become more complex.

Advanced Git is safest when you inspect state first, work in small steps, and keep a recovery path such as a backup branch or reflog note.

Beginners should learn what each advanced command changes before using it on shared project history.

Before You Start

• Before practicing Git CI/CD, create a temporary folder or throwaway repository so mistakes are harmless.
• Run git status before every important command and read the output slowly.
• Make one tiny file change at a time so you can connect each command to one visible result.
• Avoid destructive commands while learning unless you have a backup or a disposable repository.
• Write down whether the command affects the working tree, staging area, commit history, or remote repository.

Key Git Concepts

• .gitignore prevents local or generated files from entering history.
• .gitattributes controls file handling such as line endings, diff drivers, and merge behavior.
• Git LFS stores large file pointers in Git while the real content lives in LFS storage.
• Cherry-pick, patches, signing, submodules, and CI/CD should be used with clear team rules.

Plain-English Glossary

• Repository: a project folder with Git history.
• Working tree: the files you are currently editing.
• Staging area: the selected changes prepared for the next commit.
• Commit: a saved snapshot with an ID, author, date, and message.
• Branch: a movable name that points to a commit.
• Remote: another copy of the repository, usually on a server.
• HEAD: the current commit or branch checkout.
• Conflict: a place where Git needs a human to choose the final content.

What You Will Learn

• Explain what state Git CI/CD changes in Git.
• Predict the output of git status before and after the command flow.
• Use git log or git diff to verify what changed.
• Choose a safe recovery command when something goes wrong.

Where You Use This in Real Projects

You use Git CI/CD when building features, reviewing pull requests, fixing bugs, releasing versions, debugging regressions, collaborating with teammates, or deploying production code.

Git is valuable because it creates a record of decisions, allows parallel work, and makes recovery possible when a change breaks something.

In real teams, good Git habits are communication habits: small commits, clear branch names, useful messages, and careful review context.

Safety and Recovery Notes

• Run git status before commands that change files or history.
• Use git diff to inspect unstaged changes before staging or discarding anything.
• Use git diff --staged to inspect what will be committed.
• Prefer git revert for undoing shared commits because it preserves history.
• Be careful with reset, clean, checkout of files, and force push because they can discard work.

Beginner Mental Model

Think of Git CI/CD as moving changes between four places: working tree, staging area, local history, and remote history.

Most beginner confusion comes from not knowing which place a command reads from or writes to.

When unsure, pause and inspect: git status for state, git diff for file changes, git log for history, and git remote -v for shared destinations.

Command Flow Checklist

1. Check state with git status.
2. Inspect file content with git diff or git diff --staged.
3. Run the smallest command that moves the work one step forward.
4. Check state again and compare the output.
5. Write a short note explaining what Git CI/CD changed.

Code Example

name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: php spark test

Another Example

# Ignore local and generated files.
printf "node_modules/
.env
writable/logs/
" > .gitignore
git add .gitignore
git commit -m "Add ignore rules"

# Inspect advanced repository information.
git remote -v
git branch -vv
git reflog --date=relative

More Practice Examples

Example 1: Inspect before changing anything

git status
git diff
git log --oneline -5
git branch --show-current

• These commands are read-only and safe for beginners.
• status tells you the current state.
• diff and log show what changed and what was already saved.

Example 2: Make a focused commit

git status
git add app/Views/learn/path.php
git diff --staged
git commit -m "Improve learn path layout"
git status

• Stage only the file that belongs to this change.
• diff --staged lets you review the exact commit content.
• A focused message makes history easier to read later.

Example 3: Pause work safely

git status
git stash push -m "WIP lesson edits"
git pull --ff-only
git stash pop
git status

• stash is useful when you need a clean tree temporarily.
• pull --ff-only avoids unexpected merge commits while learning.
• stash pop may create conflicts if the same files changed upstream.

Real-World Workflow Example

# A safe daily Git loop
git switch main
git pull --ff-only
git switch -c feature/lesson-copy

# Edit files, then inspect.
git status
git diff

# Stage only the focused changes.
git add app/Data/LessonsData.php
git diff --staged
git commit -m "Expand Git lesson examples"

# Share for review.
git push origin feature/lesson-copy

• This Git CI/CD workflow starts from an updated main branch so the new work is based on current code.
• The feature branch keeps the task isolated until it is reviewed.
• The status and diff checks prevent accidental files from being committed.
• Pushing the branch shares local commits without rewriting shared history.

Example Explained

• The Git CI/CD example starts by inspecting state before changing anything.
• Each command moves information between the working tree, staging area, local history, or remote history.
• The safest examples use status, diff, log, and branch information before commands that change files.
• The commit message describes the reason for the saved snapshot, not only the file name.

How to Read This Example

1. Read the command and ask which Git area it touches.
2. Predict the next git status output before running the command.
3. Run the command in a practice repository.
4. Run git status or git log afterward to confirm the result.
5. Explain the Git CI/CD flow in one sentence before moving to the next example.

Checklist

• Run status before and after each important command.
• Commit small logical changes with clear messages.
• Avoid destructive commands unless you know exactly what they change.

Common Mistakes

• Running history-changing commands without checking the branch state.
• Making one large commit that mixes unrelated work.
• Pulling or rebasing with uncommitted work and no clear recovery plan.

Do and Don't

• Do: practice Git CI/CD in a temporary repository before using it on important work.
• Do: inspect with status, diff, and log before changing files or history.
• Do: make small commits with clear messages.
• Don't: run reset, clean, force push, or file checkout commands casually.
• Don't: mix unrelated work into one commit just because the files are already edited.

Practice Challenge

Try the Git CI/CD command flow in a temporary repository so you can inspect each state with git status and git log.

Try These Changes

• Run the example once, then write down how git status changed after each command.
• Create one extra file and practice staging only that file.
• Make two commits, then inspect them with git log --oneline.
• Use git diff before staging and git diff --staged after staging.
• Explain which command in Git CI/CD would be risky on shared work and why.

Quick Check

• Question: What command should you run often? Answer: git status.
• Question: What does git add do? Answer: It stages selected changes for the next commit.
• Question: What is a branch? Answer: A movable name pointing to a commit.
• Question: Which command is safest for undoing a shared commit? Answer: git revert.
• Question: What should Git CI/CD help you understand? Answer: Where your changes are and how to move them safely.

Debugging Checks

• Run git status and read every section before trying to fix the problem.
• Run git branch --show-current to confirm the branch you are on.
• Run git log --oneline --decorate -5 to inspect recent history.
• Run git diff and git diff --staged to separate unstaged and staged changes.
• If a command seems dangerous, stop and create a backup branch before continuing.

Mini Project

Build an advanced Git lab for Git CI/CD: create ignore rules, inspect attributes or remotes, practice one non-destructive advanced command, and write the recovery command you would use if it went wrong.

Mastery Check

• You can predict the repository state after the Git CI/CD command flow.
• You can recover from a small mistake without deleting work.
• You can explain the command to another developer before running it.