Git Patch & Git Apply: Instant Code Sharing Without Messing Up the Commit Log – ITFROMZERO

Table of Contents

The Tale of “Junk Branches” and the Push/Pull Obsession

While deep in coding, a teammate messages you: “Hey, send me that logic snippet; my local build is old and I can’t test it.” If you were to commit your unfinished code, riddled with syntax errors, and push it to the shared branch, the Git history would look like a battlefield filled with “temp commits” or “fix bug 1, 2, 3″… It looks incredibly unprofessional.

I’ve felt the pain of losing code due to a force push to the wrong branch. Since then, I’ve become highly averse to push --force or uploading incomplete work to the server. After six months of integrating Git Patch into real-world project workflows, I’ve realized it’s the ultimate secret weapon for smooth teamwork, especially when you need a quick review or to move code between machines without going through a remote repository.

Why Should We Avoid Pushing Unfinished Work?

In reality, Git is quite “picky” about history management. Every time you push, you’re leaving a permanent mark on the project’s timeline. If the project has CI/CD, indiscriminate pushing also wastes resources by triggering dozens of useless pipelines.

Dirty Commit Logs: Temporary commits make git log a nightmare for anyone following your work later.
Pointless Conflicts: Pushing half-baked code can cause colleagues to pull in errors, wasting unnecessary time on fixes.
Leaking Secrets: Sometimes you’re debugging and add console.log lines or temporary environment variables. You definitely don’t want those appearing on GitHub.
Network Issues: On days when the internet is down or the company VPN is crawling, waiting for push/pull just to send a few lines of code is a nightmare.

Common Manual Workarounds

Before discovering Patch, I often saw developers managing with some rather cumbersome methods:

Copy-pasting via Slack: Only works for short snippets. If changes span 10 different files, you’re stuck. Not to mention, code formatting often breaks.
Zipping folders for Email: A zip file containing node_modules can be up to 200MB, while the actual changes are just a few KB. What a waste!
Using Git Stash: git stash only works locally on your machine. There’s no direct way to easily “move” that stash to a colleague’s computer.

Git Patch – The Professional Workflow Pro-Tip

Simply put, a Patch file is a “score” containing all the changes (diff) between files. It’s lightweight, human-readable, and it’s a native language that Git loves.

Method 1: Git Diff (Quick fix for uncommitted code)

If you haven’t committed anything yet and just want to send your current changes immediately, use git diff.

# Create a patch file from current changes
git diff > my_changes.patch

# Include newly created files (untracked files)
git add -N . 
git diff > full_changes.patch

This my_changes.patch file is usually only a few KB. You can toss it over Telegram or Slack in an instant. The recipient only needs a single command to get your code exactly as it is.

Method 2: Git Format-Patch (Preserving commit history)

I typically use this method when I’ve already committed a few things locally and want to share the author’s name and commit timestamps. format-patch exports separate .patch files for each commit.

# Create a patch for the most recent commit
git format-patch -1 HEAD

# Create a patch comparing two branches
git format-patch main..feature-branch

The result is a file named something like 0001-fix-bug-logic.patch. This file is “premium” because it contains full metadata, allowing the recipient to know exactly who wrote the code.

How to Apply Patches to a Project

Depending on how the patch file was created, there are different ways to “absorb” it into the codebase.

Using Git Apply (For files from git diff)

This command applies changes to the current source code without creating a new commit.

# Check for conflicts before applying
git apply --check my_changes.patch

# If everything looks good, proceed with the apply
git apply my_changes.patch

If you encounter errors because the current code has diverged too much, use --reject. Git will try to apply the non-conflicting parts and output .rej files for you to manually handle the conflicts.

Using Git AM (For files from format-patch)

AM stands for “Apply Mailbox.” This command is incredibly powerful because it automatically creates commits for you with the exact same information as the original machine.

# Apply the patch and create a commit automatically
git am < 0001-fix-bug-logic.patch

# If you happen to encounter conflicts:
# After fixing the files, run:
git add .
git am --continue

Hard-Won Lessons to Avoid Trouble

After six months of using Patch consistently, I’ve gathered a few tips for a smoother experience:

Don’t Forget Binary Files: By default, Patch only understands text. If you’ve changed images or zip files, remember to add the --binary flag when creating the patch.
Always Run –check First: Never apply blindly. A check command takes less than a second but can save you from hours of undoing code.
Lifesaver for Hotfixes: Once, a production server had an error, but I didn’t have direct Git access. I created a patch locally and sent it to the Ops team to apply directly to the server. It took 2 minutes instead of waiting 15 minutes for the pipeline to build.
Offline Code Review: Instead of looking at a web interface, I prefer reading patch files in my IDE. This allows me to test the code immediately to verify logic.

In short, if you just need to move code quickly, stick with git diff. If you want to preserve the value of each commit, git format-patch is the way to go. Give it a try today; your workflow will definitely become more professional and flexible.