Author: @ValerasNarbutas · Tags: git productivity · Reading time: ~5 min

Git is the one tool that every developer touches every day, yet most only use 10% of it. These are the tips that actually matter.

1. Amend Without Opening an Editor

Made a typo in your last commit message? One flag fixes it:

git commit --amend --no-edit

Add --no-edit to reuse the existing message. Great for adding a forgotten file to the last commit.

git add forgotten-file.ts
git commit --amend --no-edit

⚠️ Only do this on commits you haven’t pushed yet.

2. Stash with a Message

git stash is commonly used but rarely named. Named stashes are much easier to work with later:

git stash push -m "WIP: refactor auth middleware"

List all stashes:

git stash list
# stash@{0}: On feature/auth: WIP: refactor auth middleware
# stash@{1}: On main: hotfix idea

Apply a specific stash without dropping it:

git stash apply stash@{1}

3. Interactive Rebase to Clean Up History

Before merging a feature branch, clean up your commit history with interactive rebase:

git rebase -i HEAD~5   # rewrite last 5 commits

In the editor, use:

• pick — keep as-is
• squash / s — merge into the previous commit
• reword / r — change commit message
• fixup / f — like squash, but discard this commit’s message
• drop / d — delete the commit entirely

Clean history makes code review easier and git blame more useful.

4. Find the Commit That Introduced a Bug

git bisect does a binary search through your commit history:

git bisect start
git bisect bad                  # current commit is broken
git bisect good v2.1.0          # this tag was working

# Git checks out a midpoint commit — test it, then:
git bisect good   # or: git bisect bad

# Repeat until Git identifies the culprit commit
git bisect reset  # when done

This finds bugs in large histories in ~log₂(n) steps.

5. Use --patch for Surgical Staging

Don’t commit everything in a file — stage only the hunks you want:

git add --patch
# or shorthand:
git add -p

Git shows each changed hunk and asks what to do: y (stage), n (skip), s (split), e (edit manually).

Pair this with git diff --staged to review exactly what you’re about to commit.

6. Useful Aliases Worth Adding

# ~/.gitconfig
[alias]
  st   = status -sb
  lg   = log --oneline --graph --decorate --all
  undo = reset HEAD~1 --soft
  wip  = commit -am "WIP"
  unwip = reset HEAD~1 --soft

git lg gives a compact visual branch graph. git undo rolls back the last commit while keeping your changes staged.

7. Don’t Fear reflog

git reflog is your undo history for Git operations. Even after a bad rebase or accidental branch deletion, you can recover:

git reflog
# HEAD@{0}: rebase: finish
# HEAD@{1}: commit: add login form
# HEAD@{2}: checkout: moving from main to feature/login
# ...

git checkout HEAD@{2}   # go back to any state

Your local reflog is kept for 90 days by default. It has saved many developers from disaster.

Summary

Git rewards investment. The more you learn it, the less time you spend fighting it.

← Back to homepage

Author: @ValerasNarbutas · Tags: tools dx 2026 · Reading time: ~7 min

The tools you use shape how you think. After years of trying every editor plugin, CLI utility, and AI assistant out there, here’s what’s actually stuck in 2026.

🤖 AI-Assisted Development

GitHub Copilot CLI

The terminal is the real developer interface. Copilot CLI brings natural-language help directly to your shell — ask it how to do something, get the command, run it. The iteration loop is fast.

# Example: ask before you run
gh copilot suggest "undo last git commit but keep the changes"

Best for: Command lookup, shell scripting, one-off transformations.

Cursor / Continue.dev

Full IDE AI integration has matured. Cursor still leads for those who want an opinionated setup; Continue.dev is the open-source pick if you want to bring your own model (including local ones via Ollama).

Best for: Code generation, refactoring, explaining unfamiliar codebases.

🔧 Terminal & Shell

Warp Terminal

Warp treats terminal output as structured blocks rather than a raw stream. Copy a command’s output, re-run just one block, get AI suggestions inline. On macOS it’s a clear winner; Linux support is solid now too.

zoxide

cd replacement that learns your habits. After a few days of use you’ll never type full paths again.

z proj   # jumps to ~/dev/projects/my-project or wherever you go most

fd + ripgrep

find and grep replacements that are faster and have sane defaults:

fd "*.ts" src/           # find TypeScript files under src/
rg "useState" --type ts  # search in TypeScript files only

📦 Version Management

mise (formerly rtx)

One tool to manage all your runtime versions — Node, Python, Ruby, Go, Rust. Drop a .mise.toml in any project and the right version activates automatically.

# .mise.toml
[tools]
node = "22"
python = "3.12"

Replaces: nvm, pyenv, rbenv, asdf.

🌐 API & Network

Bruno

An open-source, offline-first API client. Collections are stored as plain files in your repo — no cloud sync needed, no account required, git-friendly by design.

Replaces: Postman (for most use cases).

HTTPie Desktop

For quick exploratory requests, HTTPie’s syntax is friendlier than curl:

http POST api.example.com/users name="Ada" email="ada@example.com"

🗃️ Data & Databases

Beekeeper Studio (Community)

A cross-platform SQL editor that doesn’t look awful. Free tier is genuinely useful. Works with Postgres, MySQL, SQLite, and more.

DuckDB

An in-process analytical database — think SQLite but for data analysis. Query CSV/Parquet files directly, or use it as an embedded engine in your app.

SELECT month, SUM(revenue)
FROM read_csv('sales.csv')
GROUP BY month;

✅ The Short List

The best tool is the one you actually use consistently. Pick a few from this list, get comfortable with them, then add more.

Next: 🔧 Git Tips Every Developer Should Know

← Back to homepage

Author: @ValerasNarbutas · Tags: meta intro · Reading time: ~2 min

Hello, builder! 👷

Welcome to Technical Creators Club (Lithuanian: Tech Kūrėjų Klubas) — a community blog about technology, written in Git.

Kūrėjų is Lithuanian for creators. That’s the spirit here: practical knowledge for people who actually build things, shared by the community, for the community.

Why a Git Blog?

Most blogs are owned by platforms. Posts live on servers someone else controls, behind dashboards that change, get acquired, or disappear.

A Git blog is different:

• Your content, your repo — posts are Markdown files, versioned like code
• No CMS, no database — just files and commits
• Forkable and diffable — anyone can see the history of every post
• Stays simple — no build pipeline to maintain

What to Expect

Articles here will be practical and direct. Topics include:

• Git workflows and version control techniques
• Developer tooling that actually improves your workflow
• Architecture and design patterns
• AI tools and automation
• Open source culture and contribution

No SEO-bloated intros. No padding. Just the useful part.

How Posts Are Published

Each post is a Markdown file in the _posts/ directory, named YYYY-MM-DD-slug.md.

Want to contribute your own post? See CONTRIBUTING.md.

Next up: ⚡ Top Developer Tools in 2026