• Period 1: What is Shell \& First Script
  • 🎯 Learning Objectives
• Shell Basics 🐚
  • Main Structure
  • Common Shell Types
• Types of Shell at One Glance 🐚
  • Key Point 💡
• Shebang (#!) 📝
  • Example
  • Purpose 🎯
  • Common Interpreters
• Two Ways of Running a Script ▶️
  • 1. Run with Shell Command
  • 2. Run as Executable File
• Period 2: Variables \& Input
  • 🎯 Learning Objectives
• Variables 📦
  • Variable Declaration
  • Using Variables
  • Key Points 💡
• Environment Variable \& export 🌎
  • Exporting a Variable
  • Checking Environment Variables
  • Key Points 💡
• Special Variables ⚡
  • Common Special Variables
  • Example
• read Command ⌨️
  • Basic Example
  • With Arguments
  • Common Arguments
  • Key Points 💡
• Period 3: Control Flow, Functions \& Automation
  • 🎯 Learning Objectives
• Conditional Statements: if / elif / else / fi 🔀
  • Basic Structure
  • Example
  • Key Points 💡
• test Operator 🧪
• Loop Statements 🔁
  • for Loop
  • while Loop
  • Key Points 💡
• Function 🛠️
  • Defining a Function
  • Calling a Function
  • Example
  • Key Points 💡
• Debugging 🐞
  • Common Debugging Options
  • Example
  • Key Points 💡
• Period 4: Working / Staging / Repository
  • 🎯 Learning Objectives
• Why Version Management is Necessary 📂
  • Why It Is Needed
  • Without Version Control ❌
  • With Git ✅
• 3 Areas of Git: Working / Staging / Repository 🗂️
  • 1. Working Directory
  • 2. Staging Area
  • 3. Repository
  • Git Workflow 🔄
• git add \& git commit 📌
  • git add
  • git commit
  • Key Points 💡
  • Workflow 🔄
• git status git diff git log 🔍
  • git status
  • git diff
  • git log
  • Key Points 💡
• Period 5: Branch / Merge / Conflict
  • 🎯 Learning Objectives
• Branch 🌿
  • Create a Branch
  • Switch Branch
  • Create and Switch at Once
  • Key Points 💡
• Branch Commands: branch switch checkout 🌿
  • git branch
  • git switch
  • git checkout
  • Key Points 💡
• 2 Ways of Merge: Fast-Forward vs 3-Way Merge 🔀
  • Fast-Forward Merge
  • 특징
  • 3-Way Merge
  • 특징
  • Comparison 📊
• Why Conflicts Occur? ⚠️
  • Common Causes
  • Example Situation
  • Conflict Example
  • Key Points 💡
• Period 6: Remote Repository \& Collaboration
  • 🎯 Learning Objectives
• Remote Storage: Local ↔ Server Relationship 🌐
  • Relationship Structure
  • Main Workflow
  • Key Points 💡
• git push \& git pull 🔄
  • git push
  • u Option
  • git pull
  • How pull Works ⚙️
  • Key Points 💡
• git clone 📥
  • Basic Command
  • Example
  • Commonly Used Options
• clone vs init ⚖️
  • git clone
  • git init
  • Comparison 📊
• git fetch vs git pull 🔄
• git fetch
  • What It Does
  • Workflow
  • 특징 💡
• git pull
  • What It Does
  • Internal Process
  • Workflow
  • 특징 💡
• Main Difference ⚖️
• When to Use Each 🛠️
  • Use fetch
  • Use pull
• Learning Objectives: Git Advanced \& AI 🎯
• git stash: Temporary Storage Management 🗄️⏳
  • 🚨 Typical Use Scenario: The Production Hotfix
  • ⌨️ Main Commands \& Operations
  • 🔄 Restoring and Purging the Stack
• Git Reset vs. Revert: Undoing Changes 🔄⚠️
  • ⏳ History Modification: git reset
  • The Three Reset Modes
  • 🛡️ Safe History Reversal: git revert
  • 📊 Summary: Reset vs. Revert
• File Tracking Exclusion: .gitignore Rules 🛡️🚫
  • 💡 Why Exclusion is Mandatory
  • Core Exclusion Categories:
  • ⌨️ Structural Syntax \& Pattern Rules
  • ⚠️ The Golden Rule of .gitignore
  • How to fix an already-tracked file:
• Git Commit Message Conventions 📝✨
  • 🏗️ The Standard 3-Part Structural Layout
  • 🏷️ Prefixes: Commit Classification Types
  • 📜 The 5 Golden Rules of Writing Effective Commits

Period 1: What is Shell & First Script

🎯 Learning Objectives

• Understand what the Linux shell is
• Learn the relationship between:
  • 👤 User
  • 💻 Shell
  • ⚙️ Kernel
• Explore common shells:
  • sh, bash, zsh, dash
• Understand what a shell script is
• Create and run a simple .sh script
• Learn basic command automation with shell scripting

Shell Basics 🐚

• A shell is a command interpreter in Linux
• It connects the 👤 user and ⚙️ Linux kernel
• Users enter commands through the shell
• The shell interprets commands and passes them to the kernel

Main Structure

👤 User → 🐚 Shell → ⚙️ Kernel

Common Shell Types

• sh : original UNIX shell
• bash : most common Linux shell
• zsh : advanced/customizable shell
• dash : lightweight and fast shell

Types of Shell at One Glance 🐚

Key Point 💡

Different shells provide different:

• 기능 (features)
• 성능 (performance)
• 사용자 경험 (user experience)

Shebang (#!) 📝

A shebang specifies which shell or interpreter should execute the script. It is written on the first line of a script file and helps ensure the script runs in the correct environment.

Example

#!/bin/bash

Purpose 🎯

• Ensures the script runs with the correct shell
• Improves script consistency across environments

Common Interpreters

• /bin/bash
• /bin/sh
• /usr/bin/python

Two Ways of Running a Script ▶️

Shell scripts can be executed in two main ways.

1. Run with Shell Command

This method explicitly runs the script using a shell interpreter.

bash script.sh

• No execute permission required
• Useful for testing scripts quickly

2. Run as Executable File

This method runs the script directly as a program.

./script.sh

Before execution, permission must be added:

chmod +x script.sh

• Requires execute permission
• Commonly used for actual script execution

Period 2: Variables & Input

🎯 Learning Objectives

• Understand how to declare and use variables in shell scripts
• Learn the difference between:
  • local variables
  • environment variables
• Receive user input using the read command
• Display variable values with echo
• Build simple interactive shell scripts

Variables 📦

Variables are used to store data in shell scripts. Values can be saved and reused later in the script.

Variable Declaration

name="Alice"

Using Variables

echo $name

Key Points 💡

• No spaces around =
• Access variables using $
• Variables help make scripts flexible and reusable

Environment Variable & export 🌎

Environment variables are variables shared across the system or child processes. They are commonly used to store system settings and configuration values.

Exporting a Variable

export NAME="Alice"

Checking Environment Variables

echo $NAME

Key Points 💡

• export makes a variable available to child shells/processes
• Environment variables can be accessed globally within the session
• Common examples:
  • PATH
  • HOME
  • USER

Special Variables ⚡

Special variables store important information automatically provided by the shell.

Common Special Variables

• $0 : script name
• $1, $2 … : command-line arguments
• $# : number of arguments
• $@ : all arguments
• $$ : current process ID
• $? : exit status of previous command

Example

echo $1

This prints the first command-line argument passed to the script.

read Command ⌨️

The read command is used to receive input from the user during script execution.

Basic Example

read name
echo $name

With Arguments

read -p "Enter your name: " name

Common Arguments

• p : display a prompt message
• s : hide user input (e.g. password)
• t : set time limit for input

Key Points 💡

• Stores user input into variables
• Useful for interactive scripts
• Often combined with echo

Period 3: Control Flow, Functions & Automation

🎯 Learning Objectives

• Understand conditional statements using if
• Learn repetition with loops:
  • for
  • while
• Create reusable functions in shell scripts
• Automate repetitive tasks using scripts
• Combine variables, input, and control flow to build practical shell programs

Conditional Statements: if / elif / else / fi 🔀

Conditional statements allow scripts to make decisions based on conditions.

Basic Structure

if [ condition ]; then
    command
elif [ condition ]; then
    command
else
    command
fi

Example

if [ $num -gt 0 ]; then
    echo "positive"
else
    echo "not positive"
fi

Key Points 💡

• if checks a condition
• elif adds additional conditions
• else runs when all conditions are false
• fi ends the conditional block

test Operator 🧪

The test operator is used to evaluate conditions in shell scripts. It is commonly written inside [ ].

if [ condition ]; then
    command
fi

Loop Statements 🔁

Loop statements repeatedly execute commands while a condition is satisfied.

for Loop

The for loop repeats commands for a list of values.

for i in 1 2 3
do
    echo $i
done

while Loop

The while loop repeats commands while a condition is true.

count=1

while [ $count -le 3 ]
do
    echo $count
    count=$((count+1))
done

Key Points 💡

• for is useful when the number of repetitions is known
• while is useful when repetition depends on a condition
• done ends the loop block

Function 🛠️

Functions are reusable blocks of commands in shell scripts. They help organize code and avoid repetition.

Defining a Function

	hello() {
    echo "Hello"
}

Calling a Function

hello

Example

greet() {
	echo "Hello, $1"
}

function add() {
	echo $(($1 + $2))
}

greet Lian # Hello, Lian
add 3 5 # 8

result=$(add 10 20)
echo "SUM: $result" # sum: 30

Key Points 💡

• Functions improve code reusability
• A function runs only when it is called
• Useful for automation and modular scripting

Debugging 🐞

Debugging helps identify and fix errors in shell scripts. Shell options can display execution details and stop scripts when problems occur.

Common Debugging Options

Example

bash -x script.sh
# run script in debug mode and print each command

bash -e script.sh
# stop script immediately when an error occurs

bash -u script.sh
# generate an error if an undefined variable is used

Key Points 💡

• Useful for finding script errors quickly
• Helps trace command execution step-by-step
• Improves script reliability and troubleshooting

Period 4: Working / Staging / Repository

🎯 Learning Objectives

• Understand the basic structure of Git
• Learn the difference between:
  • Working Directory
  • Staging Area
  • Repository
• Track file changes using Git
• Move files through the Git workflow:
  • edit → stage → commit
• Understand how version control manages project history

Why Version Management is Necessary 📂

Version management helps track and manage changes in files and projects over time. It is especially important when multiple people work on the same project.

Why It Is Needed

• Prevents file overwrite problems
• Makes collaboration easier
• Allows recovery of previous versions
• Tracks who changed what and when
• Helps manage project history systematically

Without Version Control ❌

• Multiple copied files:

    final_v1
    final_v2
    final_real_final
  

• Difficult to track changes
• High risk of mistakes

With Git ✅

• Organized change history
• Easy rollback and recovery
• Efficient team collaboration

3 Areas of Git: Working / Staging / Repository 🗂️

Git manages files through three main areas during version control.

1. Working Directory

The area where files are created and edited.

• Actual project files exist here
• Changes are not yet tracked by commit

2. Staging Area

A temporary area that prepares files before committing.

git add file.txt
# move file to staging area

• Selects which changes will be included in the commit
• Also called the “index”

3. Repository

The area where committed versions are permanently stored.

git commit -m "update file"
# save staged changes into repository

• Stores project history
• Allows version tracking and recovery

Git Workflow 🔄

Working Directory → Staging Area → Repository

git add & git commit 📌

git add and git commit are core Git commands used to save project changes.

git add

The git add command moves changes from the Working Directory to the Staging Area.

git add file.txt
# stage a specific file

git add .
# stage all changed files

git commit

The git commit command saves staged changes into the Repository.

git commit -m "update file"
# create a commit with a message

Key Points 💡

• git add prepares files for commit
• git commit permanently records changes
• Commit messages should clearly describe the change

Workflow 🔄

Working Directory → git add → Staging Area → git commit → Repository

git status git diff git log 🔍

These commands help check file changes and Git history.

git status

Shows the current state of files in the repository.

git status
# check modified, staged, or untracked files

git diff

Shows detailed differences between file versions.

git diff
# compare current changes with previous state

git log

Displays commit history.

git log
# show commit records and history

Key Points 💡

• status checks current repository state
• diff shows exact file changes
• log tracks commit history and previous work

Period 5: Branch / Merge / Conflict

🎯 Learning Objectives

• Understand the purpose of Git branches
• Create and switch between branches
• Merge changes from different branches
• Understand what merge conflicts are
• Learn basic conflict resolution during collaboration
• Use branching workflows for safer development and teamwork

Branch 🌿

A branch is an independent line of development in Git. It allows developers to work on new features or changes without affecting the main project.

Create a Branch

git branch feature
# create a new branch named "feature"

Switch Branch

git checkout feature
# move to the "feature" branch

Create and Switch at Once

git checkout -b feature
# create and immediately switch to branch

Key Points 💡

• Branches allow parallel development
• Changes in one branch do not affect others immediately
• Commonly used for:
  • new features
  • bug fixes
  • experiments

Branch Commands: branch switch checkout 🌿

These commands are used to create, view, and move between Git branches.

git branch

Creates or lists branches.

git branch
# show all branches

git branch feature
# create a new branch named "feature"

git branch -d feature
# delete branch named "feature"
# -D is force delete

git branch -m feature-image
# Rename current branch to "feature-image"

git switch

Moves to another branch.

git switch feature
# switch to the "feature" branch

git switch -c feature
# create a new branch named "feature" and switch to it.
# *** This is mostly used. ***

git checkout

Older command used for switching branches and restoring files.

git checkout feature
# switch to the "feature" branch

Key Points 💡

• branch manages branches
• switch is mainly for changing branches
• checkout is an older multifunction command
• switch is generally clearer and safer for branch switching

2 Ways of Merge: Fast-Forward vs 3-Way Merge 🔀

Git provides different merge methods depending on branch history.

Fast-Forward Merge

A fast-forward merge occurs when the target branch has no new commits, so Git simply moves the branch pointer forward.

git merge feature
# branch pointer moves forward directly

특징

• Simple and clean history
• No extra merge commit created
• Happens when histories do not diverge

3-Way Merge

A 3-way merge occurs when both branches have separate commits. Git creates a new merge commit to combine histories.

git merge feature
# create merge commit when histories diverged

특징

• Preserves branch history
• Creates an additional merge commit
• Used when branches changed independently

Comparison 📊

Why Conflicts Occur? ⚠️

A merge conflict occurs when Git cannot automatically combine changes from different branches.

Common Causes

• Two branches modify the same line of a file
• One branch deletes a file while another edits it
• Different developers make incompatible changes

Example Situation

Branch A → edits line 10
Branch B → also edits line 10

Git cannot determine which change should be kept automatically.

Conflict Example

<<<<<<< HEAD
Hello World
=======
Hello Git
>>>>>>> feature

Key Points 💡

• Conflicts usually happen during merge
• Developers must manually choose or combine changes

• After resolving conflicts:

    git add .
    git commit
  

Period 6: Remote Repository & Collaboration

🎯 Learning Objectives

• Understand the role of remote repositories
• Connect local repositories with remote repositories
• Learn basic collaboration workflow using Git
• Upload and download changes using:
  • push
  • pull
  • clone
• Collaborate with multiple developers through shared repositories
• Understand basic GitHub-based teamwork

Remote Storage: Local ↔ Server Relationship 🌐

A remote repository is a shared repository stored on a server such as GitHub. Developers synchronize local work with the remote repository for collaboration.

Relationship Structure

Local Repository ↔ Remote Repository(Server)

Main Workflow

• Upload local changes:

    git push
    # send local commits to remote repository
  

• Download remote changes:

    git pull
    # fetch and merge changes from remote repository
  

• Copy remote repository:

    git clone URL
    # create local copy of remote repository
  

Key Points 💡

• Local repository stores personal work
• Remote repository enables collaboration and backup
• Team members share code through the remote server

git push & git pull 🔄

git push and git pull are used to synchronize local and remote repositories.

git push

Uploads local commits to the remote repository.

git push -u origin main
# upload commits and set upstream branch

u Option

• u means -set-upstream
• Connects the local branch with the remote branch

• After setting upstream, shorter commands can be used:

    git push
    git pull
  

git pull

Downloads changes from the remote repository and merges them into the local repository.

git pull origin main
# fetch + merge remote changes

How pull Works ⚙️

git pull is a combination of:

git fetch
# download remote changes

git merge origin/master
# merge downloaded changes into current branch

Key Points 💡

• push uploads local work to the server
• pull updates the local repository
• pull = fetch + merge
• Used for synchronization and collaboration

git clone 📥

git clone creates a local copy of a remote repository. It automatically downloads the repository, including commit history and branches.

Basic Command

git clone <repository_url>
# copy remote repository to local machine

Example

git clone <https://github.com/user/project.git>
# clone GitHub repository

Commonly Used Options

git clone -b dev <repository_url>
# clone and switch to specific branch

git clone --depth=1 <repository_url>
# shallow clone with limited commit history

clone vs init ⚖️

git clone

Used when copying an existing remote repository.

git clone <repository_url>

• Downloads existing project
• Includes commit history and branches
• Automatically connects remote repository

git init

Used when creating a new local Git repository.

git init

• Starts a new empty repository
• No remote connection by default
• Used for new projects

Comparison 📊

git fetch vs git pull 🔄

Both commands retrieve changes from a remote repository, but they behave differently.

git fetch

git fetch downloads changes from the remote repository without modifying the current working branch.

git fetch origin
# download remote updates only

What It Does

• Downloads new commits and branch information
• Updates remote tracking branches
• Does NOT change local files automatically
• Allows developers to review changes safely before merging

Workflow

Remote Repository → Local Remote Tracking Branch

특징 💡

• Safe operation
• No automatic merge
• Useful before manual review

git pull

git pull downloads remote changes and immediately merges them into the current branch.

git pull origin main
# fetch + merge remote changes

What It Does

1. Fetch remote changes
2. Automatically merge into current branch

Internal Process

git fetch
git merge

Workflow

Remote Repository → Fetch → Merge → Current Branch

특징 💡

• Faster and more convenient
• Automatically updates local branch
• May immediately create merge conflicts

Main Difference ⚖️

When to Use Each 🛠️

Use fetch

• when checking remote changes first
• when working carefully in team projects
• before manual merge or rebase

Use pull

• when quickly syncing repositories
• when automatic merge is acceptable
• during routine collaboration updates

Learning Objectives: Git Advanced & AI 🎯

• 1. Temporary Storage (git stash) 🗄️⏳
  • Learn to temporarily shelve uncommitted work to quickly switch branches without forcing a commit.
• 2. Git Recovery & Exclusion (reset / revert / .gitignore) 🔄🛡Target
  • Contrast git reset (rewinding history) with git revert (safe history reversal via a new commit).
  • Configure a .gitignore file to exclude build artifacts and secrets from version tracking.
• 3. AI-Assisted Development 🤖🧪
  • Integrate AI coding assistants with explicit prompting.
  • Develop a validation-first mindset to test and review AI code instead of blindly trusting it.

git stash: Temporary Storage Management 🗄️⏳

🚨 Typical Use Scenario: The Production Hotfix

• The Problem: You are deep in the middle of developing a complex new feature on a branch. Your code is currently broken, experimental, and incomplete. Suddenly, a critical bug is discovered in production that requires an immediate hotfix on the main branch.
• The Conflict: Git will block you from switching branches (git checkout main) if your uncommitted local changes conflict with the target branch, and you do not want to run git commit because your feature code is unstable and half-written.
• The Solution: Running git stash safely lifts your modified, uncommitted work out of the directory and stores it on an internal stack. Your working tree becomes completely clean, letting you switch to main, apply the emergency patch, and then return later to seamlessly retrieve your feature draft.

⌨️ Main Commands & Operations

• git stash: Takes all current modifications in your working directory and staging area, moves them onto the stash stack, and resets the local directory back to a clean HEAD state.
• git stash push -m "name": The modern, explicit syntax used to save changes with a descriptive label. This custom identifier makes it much easier to distinguish between different saved states when managing a large stack.
• git stash list: Outputs a structured chronological list of all saved stash items currently stored on your stack (formatted as a zero-indexed tracking layout: stash@{0}, stash@{1}, etc.).
• git stash show -p: Generates a detailed, line-by-line patch comparison (p) showing the exact code changes hidden inside a specific stash entry.

🔄 Restoring and Purging the Stack

• git stash pop 🍿: Extracts the modifications from the top item (stash@{0}) or a specified index, applies them back into your working directory, and automatically deletes that entry from the stash stack.
• git stash apply 📋: Re-integrates the stashed changes back into your working workspace exactly like pop, but safely leaves the original copy intact on the stash stack for future use or cross-branch testing.
• git stash drop stash@{0} 🗑️: Permanently deletes a single, specific stash entry from the tracking list without applying any of its code modifications to your project directory.
• git stash clear 🧹: Wipes out the entire stash storage area simultaneously, permanently deleting all saved entries.

Git Reset vs. Revert: Undoing Changes 🔄⚠️

⏳ History Modification: git reset

git reset rewinds your current branch pointer to a previous commit, changing the timeline.

• The Collaboration Rule: Because git reset alters the commit history, it can cause sync issues for your team if applied to commits that are already pushed to a shared remote repository. Only use git reset for local, unpushed cleanup tasks.

The Three Reset Modes

The syntax relies on explicit flags to determine what happens to your pending changes in the Staging Area and Working Directory:

$ git reset [--mode] [Commit_Hash]

• -soft Mode (Keep Changes Staged) 🟢: Moves the history pointer back, but preserves all your code changes safely inside the Staging Area. Useful for squashing commits.
• -mixed Mode (Unstage Changes - Default) 🟡: Moves the history pointer back and resets the Staging Area, but leaves your files intact in the Working Directory. Changes become unstaged modifications.
• -hard Mode (Absolute Destruction) 🔴: Moves the history pointer back and wipes out both the Staging Area and Working Directory to match the target commit precisely. Uncommitted or reset changes are permanently erased.

🛡️ Safe History Reversal: git revert

git revert rolls back a commit’s changes by creating a new commit that does the opposite, leaving the past timeline intact.

$ git revert [Commit_Hash_To_Undo]

• How it Works: Instead of deleting anything from the timeline, git revert looks at the target commit, determines what lines were added or removed, and applies a new inversion commit that neutralizes those changes.
• Safe for Collaboration: Because it only appends a new commit to the end of the history, git revert is completely safe to use on public, shared remote branches. It resolves errors cleanly without causing history conflicts for other developers.

📊 Summary: Reset vs. Revert

File Tracking Exclusion: .gitignore Rules 🛡️🚫

💡 Why Exclusion is Mandatory

In a real software engineering workspace, not every file in your folder belongs in a shared source repository. Checking in everything clutters history, inflates directory sizes, and exposes vulnerabilities.

Core Exclusion Categories:

• Security Credentials & Secrets: Private API keys, database credentials, ssh configurations, and environment configuration values (e.g., .env).
• Local Workspace Layouts: IDE configurations or user preference settings (e.g., .vscode/, .idea/, .suo) that vary from programmer to programmer.
• Build Artifacts & Generated Files: Compiled binaries, build directories, or node dependency frameworks (e.g., node_modules/, target/, .exe, .log) that can easily be regenerated via build tools.

⌨️ Structural Syntax & Pattern Rules

The .gitignore engine uses an adaptive text-pattern syntax called globbing to map files:

# 1. Specific Single File Exclusion
secret_token.txt

# 2. Entire Directory Exclusion (trailing slash)
node_modules/
dist/

# 3. Extension Wildcard Pattern (any file ending with this extension)
*.log
*.tmp

# 4. Inversion / Exception Whitelisting (negation mark)
!important.log

• secret_token.txt: Completely hides a single, explicit file anywhere inside the workspace.
• node_modules/: Recursively targets and blocks an entire directory and all files nested inside it.
• .log: Uses the wild card asterisk () to target any file matching the specified extension, regardless of which subdirectory it lives in.
• !important.log: Uses an exclamation mark (!) to create a whitelist rule override. This forces Git to track important.log even if a previous rule (like .log) explicitly hidden it.

⚠️ The Golden Rule of .gitignore

”.gitignore only blocks untracked files!”

If a file has already been added and committed to the repository history in the past, adding its name to .gitignore later will do absolutely nothing. Git already tracks it, so it will continue monitoring adjustments.

How to fix an already-tracked file:

If you accidentally committed a secret file or massive cache folder before adding it to your ignore list, you must manually strip it from Git’s tracking engine using the cached removal flag before the ignore rules can apply:

# Untracks the file from the index while keeping your actual local copy safe
$ git rm --cached secret_token.txt

# Commit the removal to freeze tracking, then append to .gitignore
$ git commit -m "chore: untrack sensitive credential file"

Git Commit Message Conventions 📝✨

A commit message is more than just a random text block—it serves as the structural documentation of a repository’s evolution. Adhering to professional commit conventions ensures automated changelog generation, easy filtering with git log, and seamless code reviews across teams.

🏗️ The Standard 3-Part Structural Layout

A formal commit message follows a strict hierarchical layout composed of a Header, an optional Body, and an optional Footer:

type: Subject line summarizes changes in under 50 characters

[Optional Body]
Detailed explanation describing the conceptual "why" behind the change,
not the "what" (the code diff tells you the what). Wrap lines at 72 characters.

[Optional Footer]
Resolves: #128 (Issue tracker tracking references or breaking changes)

1. Header (Subject Line): A single concise phrase containing the prefix classification and short title.
2. Body: Used for substantial adjustments requiring context. It clarifies the engineering motive and logic.
3. Footer: Used to reference tracking tickets (e.g., Jira, GitHub issues) or call out breaking changes.

🏷️ Prefixes: Commit Classification Types

To achieve standard semantic versioning, every commit summary must begin with a standardized classification keyword detailing the precise nature of the change:

📜 The 5 Golden Rules of Writing Effective Commits

• Rule 1: Separate Subject from Body with a Blank Line Git’s parsing engines utilize the initial empty line break to cleanly distinguish the shorthand subject line header from the verbose body paragraph.
• Rule 2: Limit the Subject Line to 50 Characters Keep headers crisp and compact. This ensures messages do not get truncated or overflow when rendering in short-log repository summaries or UI interfaces.
• Rule 3: Do Not End the Subject Line with a Period A subject line acts as an active title card or command string. Eliminating trailing punctuation keeps lines clean.
• Rule 4: Use Imperative Mood in the Subject Line Write your subject line as a direct command stating what the commit does, not what it did.
  • ❌ Incorrect: fixed user session timeout bug or feat: adds verification
  • 🟢 Correct: fix: resolve user session timeout bug or feat: add verification
• Rule 5: Use the Body to Focus on “Why” and “How”, Not “What” The actual programmatic file diff inherently displays what lines changed. The commit body paragraph exists to preserve the developer’s architectural reasoning—explaining why a particular path was selected and how it fixes the underlying constraint.