Quick Guide: Convert Bash Script to Alias

1. Make Script Executable

chmod +x ~/scripts/myscript.sh

2. Add Alias to Shell Config

Edit your shell config file (~/.bashrc, ~/.zshrc, etc.):

alias myalias="~/scripts/myscript.sh"

3. Apply Changes

source ~/.bashrc  # or ~/.zshrc

4. Use It!

Now run:

myalias

4. Django – Run Tests for a Specific App

To test only one app (e.g., blog), run:

python manage.py test blog

You can also run a specific test case or method:

python manage.py test blog.tests.MyTestCase
python manage.py test blog.tests.MyTestCase.test_example

Speeds up testing by skipping unrelated apps.

Why I Use Git Rebase to Keep My Commit History Clean

I use rebase to keep my work history clean. I don't like ending up with a log that looks like this: Feature name description Fix bug query Fix bug final Fix Javier's comment Merge commit with master

Instead, I want my history to look like this: Feature name description

One commit. Clean. That's the whole point.

Git Merge

Combines two branches by creating a new "merge commit."

git checkout main
git merge feature-branch

• Keeps original commits untouched
• Safe on shared branches
• Adds extra merge commits to the log — which is exactly the noise I'm trying to avoid

Git Rebase

Takes your branch's commits and replays them on top of another branch, one by one.

git checkout feature-branch
git rebase main

• Rewrites commit history (new hashes)
• Produces a clean, linear log — no merge commits
• Never rebase a branch others are working on — it breaks their history

How I Actually Use It

If I have review comments or bugs to fix after opening a PR, I don't add new "fix" commits on top. I use rebase to go back and work directly on the commit that needs the change.

Same thing if I have, say, 10 commits and need to fix something in the 5th one — I rebase, edit that commit, and move on. No "fix bug query," no "fix Javier's comment," no trail of patches. Just the final, clean commit as if I'd gotten it right the first time.

git rebase -i HEAD~10

Mark the commit you need to fix as edit, make your change, then:

git add .
git commit --amend
git rebase --continue

Why Bother With Rebase? (Clean History)

• Easier to read git log
• Easier to use git bisect when hunting bugs
• Easier code review — one commit per logical change instead of "wip," "fix," "fix again"

Cleaning Up Commits: Interactive Rebase

git rebase -i HEAD~5

Lets you edit the last 5 commits:

• squash — merge into previous commit
• reword — change the commit message
• drop — delete a commit

Great for turning messy commits into one clean one before opening a PR.

Git Worktrees: Work on Multiple Branches at the Same Time

This week I learned how to use git worktrees. It might sound simple, but it's a genuinely useful feature.

The core idea: work on more than one feature or bug fix at the same time, in the same repo, without them stepping on each other.

With my friend Claudio this gets even more interesting. While I'm fixing a bug in one worktree, I can have Claude building a bigger feature in another, with zero version conflicts between them. I just set it up to spin up a set of containers tied to my project, and the workflow already feels smoother.

What Is a Git Worktree?

Normally, a Git repo has one working directory tied to one branch at a time. If you want to switch branches, you checkout, and your files change to match. If you have uncommitted work, you have to stash it first.

A worktree lets you check out a second branch into a second folder, both pointing at the same repo and the same .git history. No stashing, no switching. Each folder just sits on its own branch, at the same time. my-project/ → main my-project-bugfix/ → bugfix-branch my-project-feature/ → feature-branch

Three folders. One repo. Three branches, all checked out simultaneously.

Why Bother?

• No more stashing. Stop what you're doing on one branch, mid-change, and go work on something else in a different folder — nothing gets stashed or lost.
• Real parallel work. Fix a bug in one worktree while a bigger feature builds in another.
• Isolated environments per branch. Each worktree can run its own dev server, its own dependencies, its own containers — nothing collides.
• Great for AI-assisted coding. Point one agent (or yourself) at one worktree and another agent at a different one. Since each worktree is a separate folder with its own checked-out branch, there's no risk of one process's changes bleeding into another's.

How to Use Git Worktrees

Create a new worktree

git worktree add ../my-project-bugfix bugfix-branch

This creates a new folder (../my-project-bugfix) checked out on bugfix-branch. If the branch doesn't exist yet, create it in the same step:

git worktree add -b bugfix-branch ../my-project-bugfix

List your worktrees

git worktree list

/path/my-project abc1234 [main] /path/my-project-bugfix def5678 [bugfix-branch] /path/my-project-feature ghi9012 [feature-branch]

Work as usual

Each folder behaves like a normal, independent checkout. cd into it, run your editor, run your build, run your tests — completely separate from what's happening in the other worktrees.

Remove a worktree when you're done

git worktree remove ../my-project-bugfix

If you deleted the folder manually instead, clean up Git's records with:

git worktree prune

A Practical Setup

This is close to how I've been using it:

# main repo, untouched
cd my-project

# spin up a worktree for a quick bugfix
git worktree add -b fix/login-error ../my-project-fix

# spin up another for a bigger feature (let Claude run in here)
git worktree add -b feature/new-dashboard ../my-project-feature

Now I can jump into my-project-fix to knock out the bug, while my-project-feature keeps building in the background — each with its own container, its own dependencies, and no risk of one interfering with the other.