ตัวอย่างบทเรียน

Final Project: Simulating Real Team Development

Apply everything you've learned in a cohesive scenario: you're a developer in a small team that needs to add a new feature, fix a bug, and release an update. We'll walk through the complete cycle step by step: creating a repository, working in branches, pull requests, intentionally created conflicts and their resolution, rebasing to clean up history, and final release tagging. By the end, you'll have a real repository that you can showcase to potential employers.

Complete Git workflow Team development Release cycle

คุณจะเรียนรู้อะไรในบทเรียนนี้

You'll be able to independently manage a full feature development cycle in Git – from creating a branch to merging into main.
You'll understand what real team workflow looks like and be ready for it from day one on the job.
You'll have a complete repository with meaningful commit history that can be added to your portfolio and discussed in job interviews.

จุดเริ่มต้นของบทเรียน

Initialising a Portfolio Repository

Create a new project folder
Initialise an empty Git repository
Add .gitignore to exclude unnecessary files
Check the working directory status

Open your terminal and create a new folder for the project using the command 'mkdir portfolio-project'. Navigate into it and run 'git init' - this will create a hidden .git folder where Git will store all the change history. Now add a .gitignore file containing 'node_modules/' and '.env' to exclude dependencies and confidential data from version control. Check the current status with 'git status' - you should see the new file listed as untracked. This is the foundation of your professional project. Make sure all files are created correctly and are in the right locations.

#!/bin/bash
# Create project folder
mkdir portfolio-project

# Navigate to project folder
cd portfolio-project

# Initialise Git repository
git init

# Create .gitignore file
cat > .gitignore << EOL
node_modules/
.env
EOL

# Check repository status
git status

Structuring the Project to Standards

Create standard folders: src, docs, tests
Add README with project description
Stage all changes for commit
Check status before committing

A clean project structure is like a tidy desk: everything in its place. Create three main folders: 'src' for source code, 'docs' for documentation, and 'tests' for tests. Add a README.md file with a brief project description. Now run 'git add .' to add all files to the staging area. Check 'git status' again - now all new files should be listed under changes ready to be committed. This is the first step towards professional codebase organisation. Ensure the structure meets industry standards.

#!/bin/bash
# Create standard folders
mkdir src docs tests

# Create README with description
cat > README.md << EOL
# Portfolio Project

This project demonstrates Git workflow skills.
EOL

# Add all files to staging area
git add .

# Check repository status
git status

First Meaningful Commit

Create first commit with a clear message
Use 'chore' prefix for maintenance changes
Check commit history
Verify all changes are committed

It's time to record the initial project state. Write 'git commit -m 'chore: initialise project structure''. Note the 'chore' prefix — it indicates maintenance changes. After committing, run git log — you'll see a record of your first commit with its hash, author, and message. This is the foundation upon which the entire change history will be built. A good first commit is like a clean canvas for an artist. Make sure the message is clear and informative.

#!/bin/bash
# Create first commit
git commit -m 'chore: initialize project structure'

# Check commit history
git log --oneline

บทเรียนฉบับเต็มใช้ได้เมื่อสมัครสมาชิก

ฉบับเต็มมีสไลด์เพิ่มอีก 31 สไลด์

วิดีโอ สไลด์ทั้งหมด โน้ต แบบทดสอบ AI ติวเตอร์ และการสัมภาษณ์จะเปิดหลังเข้าสู่ระบบและสมัครสมาชิก

เข้าสู่ระบบหรือลงทะเบียน สมัครสมาชิก

เนื้อหาบทเรียน

Initialising a Portfolio Repository
Structuring the Project to Standards
First Meaningful Commit
Publishing the Project on GitHub
Starting a New Feature: Creating a Branch
Atomic Commits: Writing a Change History
Pre-Merge Checklist
Preparing for a Pull Request
Preparing the Final Project for Review
Creating a Pull Request on GitHub
Addressing Review Feedback
Completing the Review Process
Urgent Production Bug: What to Do?
Creating a Hotfix Branch Correctly
Quick Fix and Verification
Urgent Merge and Deployment
Updating Feature Branch Before Merging
Resolving Code Conflicts
Completing Rebase and Push
Why Rebase Before Merging
Interactive Rebase in Action
Final Step: Clean History Merge
Publishing the Completed Feature
Merging Changes with Squash and Merge
Post-Merge Cleanup
Final Result and What to Show in Interviews
Pre-release Checklist: Verifying Code Readiness
Creating Version Tag v1.0.0
Publishing the Release on GitHub
Reviewing the Result and Preparing for Development
Analysing Project History
Evaluating Commit Readability
Commit History as Your Professional Portfolio
Finale: Your First Release is Ready!