version-control

Version Control & Git Workflows

Back to Software Development Index

Git Fundamentals

Hash Functions

Git จะเก็บ commit โดยใช้ Hash function

Characteristics:

• ใช้ same input → same output แต่ละครั้ง
• ไม่สามารถ reverse กลับได้ (one-way function)
• อินพุตที่ต่างกันจะได้เอาต์พุตที่ต่างกัน (collision resistance)

Git’s Usage:

• สร้าง unique identifier สำหรับแต่ละ commit
• ใช้ SHA-1 (40 character hexadecimal)
• แต่ละ commit มี parent commit (ยกเว้น initial commit)

Basic Git Configuration

# Set user information
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"
 
# Check configuration
git config --list
 
# Set default editor
git config --global core.editor "code --wait"
 
# Set default branch name
git config --global init.defaultBranch main

Branching Strategies

มีหลากหลายรูปแบบในการจัดการ branch ใน git ซึ่งแต่ละรูปแบบจะมีข้อดีข้อเสียที่แตกต่างกัน

1. Git Workflow (Git Flow)

รูปแบบ workflow ที่เหมาะกับโปรเจ็คขนาดใหญ่ มีการ release แบบ schedule

Main Branches:

• main/master - Production code (stable)
• develop - Development branch (integration)

Supporting Branches:

• feature/* - New features (from develop)
• release/* - Prepare for release (from develop)
• hotfix/* - Emergency fixes (from main)

Workflow:

main ──────●─────────────●──────────●────
           │ hotfix      │ release  │ hotfix
develop ───●──●──●───────●──────────●────
              │  │ feature branches

When to Use:

• Large teams
• Scheduled releases
• Multiple versions in production
• Need for strict release management

Pros: ✅

• Clear separation of concerns
• Supports multiple versions
• Organized release process

Cons: ❌

• Complex for small teams
• Overhead for continuous deployment
• Merge conflicts can be frequent

2. GitHub Flow

รูปแบบที่เรียบง่าย เหมาะกับการ deploy บ่อยๆ (continuous deployment)

Structure:

• main - Always deployable
• feature/* - All new work

Workflow:

1. Create feature branch from main
2. Make commits
3. Open Pull Request
4. Review and discuss
5. Deploy to test from branch
6. Merge to main
7. Deploy main to production

main ───●─────●────●────●────●────
         \   / \  /    /    /
          \ /   \/    /    /
           ●    ●    ●    ● feature branches

When to Use:

• Small to medium teams
• Web applications with continuous deployment
• SaaS products
• Teams practicing CI/CD

Pros: ✅

• Simple and easy to learn
• Fast iteration
• Continuous deployment friendly

Cons: ❌

• No release branch
• Difficult for scheduled releases
• Not suitable for multiple versions

3. GitLab Flow

รูปแบบที่ผสมผสานความดีของ Git Flow และ GitHub Flow

Structure:

• main - Development
• pre-production - Staging
• production - Production

Workflow:

1. Feature branches from main
2. Merge to main after review
3. Cherry-pick or merge to pre-production
4. Test in staging
5. Merge to production when ready

main ──────●──●──●──●──────────
            \  \  \  \
pre-prod ────●──●──●──●────────
                  \  \  \
production ────────●──●──●────

Alternative: Environment Branches

main ───────●──●──●──────
             \  \  \
staging ──────●──●──●────
                   \  \
production ─────────●──●

When to Use:

• Multiple environments
• Need for testing before production
• Regulated industries
• Both continuous and scheduled releases

Pros: ✅

• Flexible for different release strategies
• Clear environment progression
• Supports feature flags

Cons: ❌

• More complex than GitHub Flow
• Can be confusing for new team members

Workflow Comparison

Feature	Git Flow	GitHub Flow	GitLab Flow
Complexity	High	Low	Medium
Branches	Multiple	Minimal	Medium
Release	Scheduled	Continuous	Both
Team Size	Large	Small-Medium	Any
Learning Curve	Steep	Easy	Moderate
Best For	Enterprise	Web Apps	Multi-env

Conventional Commits

มาตรฐานในการเขียน commit message ที่ชัดเจน อ่านง่าย และสามารถ automate changelog ได้

Structure

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Commit Types

Type	Description	Example
feat	New feature	feat: add user authentication
fix	Bug fix	fix: resolve login error
test	Add or update tests	test: add unit tests for auth
build	Build system changes	build: update webpack config
refactor	Code refactoring	refactor: simplify auth logic
perf	Performance improvements	perf: optimize database queries
ci	CI/CD changes	ci: add github actions workflow
docs	Documentation	docs: update API documentation
style	Code style/formatting	style: fix indentation
chore	Maintenance tasks	chore: update dependencies

Emoji Convention 🎨

เพิ่ม emoji เพื่อให้ commit message อ่านง่ายขึ้น:

✨ feat: New feature
🐛 fix: Bug fix
🧪 test: Testing
🏗️ build: Build system
♻️ refactor: Refactoring
⚡ perf: Performance
👷 ci: CI/CD
📝 docs: Documentation
💄 style: Styling
🔧 chore: Maintenance

Examples

Basic:

git commit -m "feat: add user profile page"
git commit -m "fix: resolve null pointer exception in auth"
git commit -m "docs: update installation instructions"

With Scope:

git commit -m "feat(auth): implement JWT token refresh"
git commit -m "fix(api): handle timeout errors"
git commit -m "test(user): add integration tests"

With Body and Footer:

git commit -m "feat: add payment gateway integration
 
Integrate Stripe payment gateway for processing
credit card payments. Includes webhook handling
for payment status updates.
 
BREAKING CHANGE: Payment API now requires API key
Closes #123"

With Emoji:

git commit -m "✨ feat: add dark mode support"
git commit -m "🐛 fix: resolve memory leak in cache"
git commit -m "📝 docs: add API examples"

Benefits of Conventional Commits

1. Automated Changelog - Generate changelog from commits
2. Semantic Versioning - Determine version bumps automatically
3. Better Communication - Clear commit history
4. Easier Navigation - Find specific changes quickly
5. CI/CD Integration - Trigger workflows based on type

Breaking Changes

สำหรับการเปลี่ยนแปลงที่ทำให้ backward compatibility แตก:

# Option 1: Use ! after type
git commit -m "feat!: change API response format"
 
# Option 2: Use BREAKING CHANGE in footer
git commit -m "feat: update authentication
 
BREAKING CHANGE: API now requires Bearer token
instead of Basic auth"

Git Best Practices

DO ✅

• Commit early and often
• Write meaningful commit messages
• Use branches for features
• Review code before merging
• Keep commits atomic (one logical change)
• Pull before pushing
• Use .gitignore properly

DON’T ❌

• Commit directly to main/master
• Mix multiple changes in one commit
• Commit commented-out code
• Commit sensitive data (passwords, keys)
• Rewrite public history
• Force push to shared branches

Merge Request Workflow

1. Create feature branch
   git checkout -b feature/new-feature

2. Make changes and commit
   git add .
   git commit -m "feat: implement new feature"

3. Push to remote
   git push origin feature/new-feature

4. Create Merge/Pull Request
   - Add description
   - Request reviewers
   - Link related issues

5. Code Review
   - Address feedback
   - Make additional commits

6. Merge
   - Squash and merge (clean history)
   - Merge commit (preserve commits)
   - Rebase and merge (linear history)

7. Delete branch
   git branch -d feature/new-feature

---

Related:

• Microservices Architecture
• Testing Strategies
• Software Architecture

References:

• Conventional Commits
• Git Flow
• GitHub Flow
• GitLab Flow