We are still cooking the magic in the way!
Git & GitHub
Basic Git Workflow
Basic Git Workflow
Now that you understand Git's architecture, it's time to put that knowledge into practice. In this lesson, we'll learn the fundamental Git workflow: creating repositories, understanding the three-stage process, and making your first commits.
Creating a New Repository
There are two ways to start working with Git: creating a new repository or cloning an existing one.
Method 1: git init - Create a New Repository
# Create a new project directory
mkdir my-project
cd my-project
# Initialize Git repository
git init
Output:
Initialized empty Git repository in /path/to/my-project/.git/
What happened?
Git created a .git directory containing:
• All necessary Git structure
• Configuration files
• Object database
• References (branches)
Your directory is now a Git repository!
Tip: You can initialize Git in an existing project with files. Git won't automatically track them until you explicitly add them.
Method 2: git clone - Copy an Existing Repository
# Clone a repository from a URL
git clone https://github.com/username/repository.git
# Clone with a different directory name
git clone https://github.com/username/repository.git my-folder
# Clone specific branch
git clone -b branch-name https://github.com/username/repository.git
What git clone does:
1. Creates a new directory
2. Initializes a .git directory inside
3. Downloads all repository data
4. Checks out the default branch
5. Sets up remote tracking
Result: You have a complete copy of the repository with full history.
The Three-Stage Workflow
Understanding Git's three-stage workflow is crucial for effective version control:
Stage 1: Working Directory (Modified)
Your actual project files where you make changes.
Stage 2: Staging Area (Staged)
A holding area where you prepare changes for commit.
Stage 3: Repository (Committed)
Permanent storage of snapshots in .git directory.
The Flow:
[Working Directory] --add--> [Staging Area] --commit--> [Repository]
The Basic Workflow in Action
Let's walk through a complete example:
Step 1: Create and Modify Files
# Initialize repository
git init my-website
cd my-website
# Create a new file
echo "<h1>Welcome to My Website</h1>" > index.html
# Check status
git status
Output:
On branch main
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
index.html
nothing added to commit but untracked files present
Understanding "Untracked": Git sees the file but isn't tracking its changes yet. You need to explicitly tell Git to track it.
Step 2: Stage Changes
# Add file to staging area
git add index.html
# Check status again
git status
Output:
On branch main
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: index.html
What git add does:
1. Takes a snapshot of the file content
2. Stores it as a blob object in .git/objects
3. Adds the file to the staging area (index)
4. Marks it as "ready to commit"
The file is now staged but not yet committed.
Step 3: Commit Changes
# Commit staged changes
git commit -m "Add homepage with welcome message"
Output:
[main (root-commit) a1b2c3d] Add homepage with welcome message
1 file changed, 1 insertion(+)
create mode 100644 index.html
What git commit does:
1. Creates a tree object representing the project structure
2. Creates a commit object with:
• Reference to the tree
• Author and committer info
• Commit message
• Parent commit (if not first commit)
3. Updates the current branch to point to new commit
4. Updates HEAD to point to the branch
Your changes are now permanently saved in Git history!
Multiple Files Workflow
# Create multiple files
echo "body { font-family: Arial; }" > style.css
echo "console.log('Hello');" > script.js
mkdir images
# Check status
git status
Output:
Untracked files:
script.js
style.css
# Add specific files
git add style.css script.js
# Or add all files in current directory
git add .
# Or add all modified and new files in entire repository
git add -A
# Commit
git commit -m "Add CSS and JavaScript files"
Be Careful with git add .: This adds everything in the current directory, which might include files you don't want to track (like passwords, API keys, or large binary files). Always review what you're adding!
Best Practices for Commits
1. Atomic Commits
What are Atomic Commits?
Each commit should represent ONE logical change.
❌ Bad: One commit with 10 unrelated changes
"Fix bug, add feature, update docs, refactor code"
✓ Good: Four separate commits
Commit 1: "Fix login validation bug"
Commit 2: "Add password reset feature"
Commit 3: "Update API documentation"
Commit 4: "Refactor authentication module"
Benefits:
• Easier to understand what changed
• Easier to revert specific changes
• Better code review
• Clearer project history
2. When to Commit
Commit When You:
✓ Complete a logical unit of work
✓ Fix a bug
✓ Add a new feature (even if incomplete)
✓ Reach a stable state
✓ Before switching tasks
✓ Before trying something risky
Don't Commit When:
❌ Code doesn't compile/run
❌ Tests are failing (unless documenting the failure)
❌ Half-finished changes that break functionality
❌ You're not sure what you changed
Rule of Thumb:
Commit early, commit often - but keep commits logical!
3. Commit Frequency
Too Few Commits:
❌ Lose granular history
❌ Hard to identify when bugs were introduced
❌ Difficult to revert specific changes
Too Many Commits:
❌ Cluttered history
❌ "Fixed typo" commits everywhere
❌ Hard to see the big picture
Just Right:
✓ Each commit represents completed work
✓ Clear progression of changes
✓ Easy to understand project evolution
Example Good Commit Frequency:
Morning: "Implement user authentication"
Afternoon: "Add email verification"
Evening: "Write authentication tests"
Not: Every 5 minutes with "WIP" commits
Writing Good Commit Messages
Commit messages are crucial for understanding project history:
Anatomy of a Good Commit Message:
Subject line (50 characters or less)
|
v
Add user authentication with JWT tokens
Blank line separator
Detailed description (wrap at 72 characters)
- Implement login and registration endpoints
- Add JWT token generation and validation
- Include refresh token functionality
- Add password hashing with bcrypt
Breaking changes or additional context here
Subject Line Guidelines
Good Subject Lines:
✓ "Fix memory leak in image processing"
✓ "Add user profile page"
✓ "Update dependencies to latest versions"
✓ "Refactor database connection logic"
Bad Subject Lines:
❌ "Fixed stuff"
❌ "Update"
❌ "asdfasdf"
❌ "Final version"
❌ "Changes"
Rules:
1. Use imperative mood: "Add feature" not "Added feature"
2. Start with capital letter
3. No period at the end
4. Be specific and descriptive
5. Keep it under 50 characters
Why Imperative Mood?
Think of commits as instructions:
✓ "Add login form" = If applied, this commit will ADD LOGIN FORM
✓ "Fix validation bug" = If applied, this commit will FIX VALIDATION BUG
✓ "Remove deprecated code" = If applied, this commit will REMOVE DEPRECATED CODE
This matches Git's own messages:
• "Merge branch 'feature'"
• "Revert 'Add broken feature'"
Consistency makes history easier to read!
When to Add Detailed Description
Add Details When:
• The change is complex
• You need to explain WHY (not just WHAT)
• There are breaking changes
• Multiple files are affected
• Context is needed for future developers
Example:
git commit -m "Refactor authentication system
Replace custom auth with JWT tokens for better security.
This change affects:
- Login endpoint (/api/auth/login)
- Registration endpoint (/api/auth/register)
- All protected routes now require Bearer token
Breaking change: Old session-based auth no longer supported.
Update clients to use Authorization header.
Related to issue #42"
Practical Workflow Example
Here's a complete real-world example:
# Day 1: Start new feature
git init blog-project
cd blog-project
# Create initial files
echo "# My Blog" > README.md
echo "<h1>Blog</h1>" > index.html
git add .
git commit -m "Initial commit with README and homepage"
# Add styling
echo "body { margin: 0; }" > style.css
git add style.css
git commit -m "Add basic CSS reset"
# Create blog post structure
mkdir posts
echo "<article>First post</article>" > posts/post1.html
git add posts/
git commit -m "Add blog post template structure"
# View history
git log --oneline
Output:
c3d4e5f Add blog post template structure
b2c3d4e Add basic CSS reset
a1b2c3d Initial commit with README and homepage
Common Workflow Commands Summary
# Initialize new repository
git init
# Clone existing repository
git clone <url>
# Check status
git status
# Stage files
git add <file> # Specific file
git add . # Current directory
git add -A # All changes
# Commit staged changes
git commit -m "message"
# Stage and commit in one step (tracked files only)
git commit -am "message"
# View commit history
git log
git log --oneline # Compact view
git log --graph # Visual branch structure
Hands-On Exercise:
Create your first Git project:
- Create a new directory called "my-portfolio"
- Initialize it as a Git repository
- Create an index.html file with your name
- Stage and commit the file with message "Add homepage"
- Create a style.css file with basic styling
- Stage and commit with message "Add stylesheet"
- View your commit history
Commands:
mkdir my-portfolio && cd my-portfolio
git init
echo "<h1>Your Name</h1>" > index.html
git add index.html
git commit -m "Add homepage"
echo "h1 { color: blue; }" > style.css
git add style.css
git commit -m "Add stylesheet"
git log --oneline
Summary
In this lesson, you learned:
- How to create repositories with git init and git clone
- The three-stage workflow: Working Directory → Staging → Repository
- How to stage changes with git add
- How to commit changes with git commit
- Best practices for atomic commits
- When to commit and how often
- How to write effective commit messages
- Complete workflow from creation to commit
Next Up: In the next lesson, we'll dive deeper into tracking changes, understanding git status output, and using .gitignore to exclude files!