docs(blog): 12차 배치 팁 포스트 5개 추가 (3개 언어)

Author: realcoding2003

_posts/2026-03-14-git-worktree-multiple-branch-management-en.md

@@ -0,0 +1,69 @@
+---
+layout: post
+title: "git worktree: Work on Multiple Branches Without Switching"
+date: 2026-03-14 09:00:00 +0900
+categories: [Development, Tips]
+tags: [Git, git-worktree, CLI, Version-Control]
+author: "Kevin Park"
+lang: en
+slug: git-worktree-multiple-branch-management
+permalink: /en/:year/:month/:day/:title/
+redirect_from:
+  - /en/2026/03/14/git-worktree-multiple-branch-management-en/
+  - /2026/03/14/git-worktree-multiple-branch-management-en/
+excerpt: "Use git worktree to open multiple branches in separate directories simultaneously. No more stash-checkout-pop cycles."
+---
+
+## Problem
+
+You're deep in a feature branch when a hotfix request comes in. Stash changes, checkout main, create a hotfix branch, fix the bug, push, then switch back and pop the stash. Repeat this several times a day and it gets old fast.
+
+## Solution
+
+`git worktree` lets you check out multiple branches into separate directories from a single repo.
+
+```bash
+# Open main branch in a separate directory
+git worktree add ../project-main main
+
+# Create a new branch with a worktree
+git worktree add ../project-hotfix -b hotfix/login-bug
+
+# Open an existing branch
+git worktree add ../project-review feature/api-v2
+```
+
+Now work in each directory independently. No branch switching needed.
+
+```bash
+# Open multiple editor windows for simultaneous work
+code ../project-main      # main branch
+code ../project-hotfix    # hotfix branch
+code .                    # current feature branch
+```
+
+Managing worktrees is straightforward:
+
+```bash
+# List all worktrees
+git worktree list
+# /home/user/project              abc1234 [feature/auth]
+# /home/user/project-main         def5678 [main]
+# /home/user/project-hotfix       ghi9012 [hotfix/login-bug]
+
+# Remove a finished worktree
+git worktree remove ../project-hotfix
+
+# Clean up manually deleted worktree directories
+git worktree prune
+```
+
+Worktrees share `.git` data, so they use far less disk space than a full `git clone`. Commit history is shared across all worktrees.
+
+## Key Points
+
+- `git worktree add <path> <branch>` opens a branch in a separate directory
+- Work on multiple branches simultaneously without `checkout`
+- Shares `.git` data — much lighter than cloning
+- Clean up with `git worktree remove` when done
+- The same branch cannot be checked out in two worktrees at once

_posts/2026-03-14-git-worktree-multiple-branch-management-ja.md

@@ -0,0 +1,69 @@
+---
+layout: post
+title: "git worktreeでブランチ切り替えなしに複数ブランチを同時作業する方法"
+date: 2026-03-14 09:00:00 +0900
+categories: [Development, Tips]
+tags: [Git, git-worktree, CLI, バージョン管理]
+author: "Kevin Park"
+lang: ja
+slug: git-worktree-multiple-branch-management
+permalink: /ja/:year/:month/:day/:title/
+redirect_from:
+  - /ja/2026/03/14/git-worktree-multiple-branch-management-ja/
+  - /2026/03/14/git-worktree-multiple-branch-management-ja/
+excerpt: "git worktreeで一つのリポジトリから複数のブランチを別ディレクトリで同時に開いて作業する方法を解説します。"
+---
+
+## 問題
+
+featureブランチで作業中に突然ホットフィックスの依頼が来ることがあります。`git stash`して`git checkout main`してホットフィックスブランチを作って...終わったら元のブランチに戻って`git stash pop`。これが一日に何回も繰り返されると、かなりストレスです。
+
+## 解決方法
+
+`git worktree`を使えば、一つのリポジトリから複数のブランチを別々のディレクトリに同時に開くことができます。
+
+```bash
+# mainブランチを../project-mainディレクトリに開く
+git worktree add ../project-main main
+
+# 新しいブランチを作りながらworktreeを作成
+git worktree add ../project-hotfix -b hotfix/login-bug
+
+# 既存のブランチを開く
+git worktree add ../project-review feature/api-v2
+```
+
+あとは各ディレクトリで独立して作業するだけです。ブランチの切り替えは不要です。
+
+```bash
+# エディタで複数ウィンドウを開いて同時作業
+code ../project-main      # mainブランチ
+code ../project-hotfix    # ホットフィックスブランチ
+code .                    # 現在のfeatureブランチ
+```
+
+worktreeの一覧確認と整理も簡単です。
+
+```bash
+# 現在のworktree一覧
+git worktree list
+# /home/user/project              abc1234 [feature/auth]
+# /home/user/project-main         def5678 [main]
+# /home/user/project-hotfix       ghi9012 [hotfix/login-bug]
+
+# 作業が終わったworktreeを削除
+git worktree remove ../project-hotfix
+
+# すでにディレクトリを手動削除した場合
+git worktree prune
+```
+
+`.git`データを共有するため、`git clone`よりディスク使用量がはるかに少ないです。コミット履歴も当然共有されます。
+
+## ポイント
+
+- `git worktree add <パス> <ブランチ>`でブランチを別ディレクトリに開けます
+- ブランチ切り替え（`checkout`）なしで複数ブランチの同時作業が可能です
+- `.git`データを共有するのでcloneより軽量です
+- 作業が終わったら`git worktree remove`で整理します
+- 同じブランチを2つのworktreeで同時に開くことはできません

_posts/2026-03-14-git-worktree-multiple-branch-management.md

@@ -0,0 +1,64 @@
+---
+layout: post
+title: "git worktree로 브랜치 전환 없이 여러 브랜치 동시 작업하기"
+date: 2026-03-14 09:00:00 +0900
+categories: [Development, Tips]
+tags: [Git, git-worktree, CLI, 버전관리]
+author: "Kevin Park"
+lang: ko
+excerpt: "git worktree로 한 레포에서 여러 브랜치를 동시에 열어서 작업하는 방법. 브랜치 전환 스트레스가 사라진다."
+---
+
+## 문제
+
+feature 브랜치에서 작업 중인데 갑자기 핫픽스 요청이 들어왔다. `git stash` 하고 `git checkout main` 하고 핫픽스 브랜치 만들고... 끝나면 다시 원래 브랜치로 돌아와서 `git stash pop`. 이 과정이 하루에 몇 번씩 반복되면 진짜 짜증난다.
+
+## 해결
+
+`git worktree`를 쓰면 하나의 레포에서 여러 브랜치를 별도 디렉토리에 동시에 열 수 있다.
+
+```bash
+# main 브랜치를 ../project-main 디렉토리에 열기
+git worktree add ../project-main main
+
+# 새 브랜치를 만들면서 worktree 생성
+git worktree add ../project-hotfix -b hotfix/login-bug
+
+# 기존 브랜치를 열기
+git worktree add ../project-review feature/api-v2
+```
+
+이제 각 디렉토리에서 독립적으로 작업하면 된다. 브랜치 전환이 필요 없다.
+
+```bash
+# 에디터에서 여러 창으로 동시 작업
+code ../project-main      # main 브랜치
+code ../project-hotfix    # 핫픽스 브랜치
+code .                    # 현재 feature 브랜치
+```
+
+worktree 목록 확인과 정리도 간단하다.
+
+```bash
+# 현재 worktree 목록
+git worktree list
+# /home/user/project              abc1234 [feature/auth]
+# /home/user/project-main         def5678 [main]
+# /home/user/project-hotfix       ghi9012 [hotfix/login-bug]
+
+# 작업 끝난 worktree 삭제
+git worktree remove ../project-hotfix
+
+# 이미 디렉토리를 수동 삭제한 경우
+git worktree prune
+```
+
+`.git` 데이터를 공유하기 때문에 `git clone`보다 디스크를 훨씬 적게 쓴다. 커밋 히스토리도 당연히 공유된다.
+
+## 핵심 포인트
+
+- `git worktree add <경로> <브랜치>`로 브랜치를 별도 디렉토리에 열 수 있다
+- 브랜치 전환(`checkout`) 없이 여러 브랜치를 동시에 작업 가능
+- `.git` 데이터를 공유하므로 clone보다 가볍다
+- 작업 끝나면 `git worktree remove`로 정리
+- 같은 브랜치를 두 개의 worktree에서 동시에 열 수는 없다

_posts/2026-03-15-docker-compose-watch-hot-reload-en.md

@@ -0,0 +1,77 @@
+---
+layout: post
+title: "Docker Compose Watch: Hot Reload for Containerized Development"
+date: 2026-03-15 09:00:00 +0900
+categories: [Development, Tips]
+tags: [Docker, docker-compose, hot-reload, Dev-Environment]
+author: "Kevin Park"
+lang: en
+slug: docker-compose-watch-hot-reload
+permalink: /en/:year/:month/:day/:title/
+redirect_from:
+  - /en/2026/03/15/docker-compose-watch-hot-reload-en/
+  - /2026/03/15/docker-compose-watch-hot-reload-en/
+excerpt: "Use docker compose watch to auto-sync code changes into containers. Cleaner than volume mounts."
+---
+
+## Problem
+
+Rebuilding with `docker compose up --build` after every code change is painful. Volume mounts work but introduce `node_modules` conflicts and cross-OS file watching issues.
+
+## Solution
+
+Docker Compose 2.22+ introduced `watch`. Add a `develop.watch` section to your `compose.yaml`:
+
+```yaml
+services:
+  web:
+    build: .
+    ports:
+      - "3000:3000"
+    develop:
+      watch:
+        # Source code changes → auto-sync to container
+        - action: sync
+          path: ./src
+          target: /app/src
+
+        # package.json changes → rebuild image
+        - action: rebuild
+          path: ./package.json
+
+        # Config changes → sync and restart
+        - action: sync+restart
+          path: ./config
+          target: /app/config
+```
+
+Run it with:
+
+```bash
+docker compose watch
+```
+
+Three actions are available:
+
+- **sync**: Copies files directly into the container. Best for source code changes.
+- **rebuild**: Rebuilds the image and replaces the container. Best for dependency changes.
+- **sync+restart**: Copies files then restarts the container. Best for config changes.
+
+Exclude specific files with `ignore`:
+
+```yaml
+        - action: sync
+          path: ./src
+          target: /app/src
+          ignore:
+            - "**/*.test.ts"
+            - "**/__snapshots__"
+```
+
+## Key Points
+
+- `docker compose watch` detects file changes and auto-syncs/rebuilds/restarts
+- No `node_modules` conflicts unlike volume mounts
+- Three actions (`sync`, `rebuild`, `sync+restart`) for different change types
+- `ignore` filters out unnecessary file changes
+- Requires Docker Compose 2.22+ (Docker Desktop 4.24+)

_posts/2026-03-15-docker-compose-watch-hot-reload-ja.md

@@ -0,0 +1,77 @@
+---
+layout: post
+title: "Docker Compose Watchで開発環境のホットリロードを設定する方法"
+date: 2026-03-15 09:00:00 +0900
+categories: [Development, Tips]
+tags: [Docker, docker-compose, hot-reload, 開発環境]
+author: "Kevin Park"
+lang: ja
+slug: docker-compose-watch-hot-reload
+permalink: /ja/:year/:month/:day/:title/
+redirect_from:
+  - /ja/2026/03/15/docker-compose-watch-hot-reload-ja/
+  - /2026/03/15/docker-compose-watch-hot-reload-ja/
+excerpt: "docker compose watchでコード変更時に自動でコンテナに反映する方法。ボリュームマウントよりスマートです。"
+---
+
+## 問題
+
+Dockerで開発する際、コードを変更するたびに`docker compose up --build`を実行するのは非効率です。ボリュームマウント（`volumes`）を使う方法もありますが、`node_modules`の競合やOS間のファイル監視の問題が発生します。
+
+## 解決方法
+
+Docker Compose 2.22以降、`watch`機能が追加されました。`compose.yaml`に`develop.watch`セクションを追加します。
+
+```yaml
+services:
+  web:
+    build: .
+    ports:
+      - "3000:3000"
+    develop:
+      watch:
+        # ソースコード変更 → コンテナに自動同期
+        - action: sync
+          path: ./src
+          target: /app/src
+
+        # package.json変更 → イメージリビルド
+        - action: rebuild
+          path: ./package.json
+
+        # 設定ファイル変更 → コンテナ再起動
+        - action: sync+restart
+          path: ./config
+          target: /app/config
+```
+
+実行方法はこちらです。
+
+```bash
+docker compose watch
+```
+
+3つのアクションがあります。
+
+- **sync**: ファイルをコンテナに直接コピーします。ソースコードの変更に適しています
+- **rebuild**: イメージを再ビルドしてコンテナを置き換えます。依存関係の変更に適しています
+- **sync+restart**: ファイルをコピーしてからコンテナを再起動します。設定ファイルの変更に適しています
+
+特定のファイルを除外したい場合は`ignore`を使います。
+
+```yaml
+        - action: sync
+          path: ./src
+          target: /app/src
+          ignore:
+            - "**/*.test.ts"
+            - "**/__snapshots__"
+```
+
+## ポイント
+
+- `docker compose watch`はファイル変更を検知して自動で同期/リビルド/再起動します
+- ボリュームマウントと違い`node_modules`の競合がありません
+- `sync`、`rebuild`、`sync+restart`の3つのアクションで変更タイプに応じた対応が可能です
+- `ignore`で不要なファイル変更をフィルタリングできます
+- Docker Compose 2.22+が必要です（Docker Desktop 4.24+）