"Got hit with a 'fatal: the remote end hung up unexpectedly' error while pushing to GitHub? Here is a step-by-step guide to undoing your commit without losing work, finding files over 50MB, and fixing your configuration."
tags: "git, github, tutorial, beginners, productivity"
We have all been there. You have been coding away, everything is working perfectly, and you group your awesome progress into a clean commit. You type out git push, hit enter, and watch the progress counter climb... only to get slapped with a frustrating network termination:
Enumerating objects: 596, done. Counting objects: 100% (596/596), done. Delta compression using up to 8 threads Connection to github.com closed by remote host. send-pack: unexpected disconnect while reading sideband packet Compressing objects: 100% (589/589), done. fatal: the remote end hung up unexpectedly When this happens, your local Git client is usually trying to upload a payload that is simply too large for GitHub's default HTTP buffer settings or your current network stability.
If you are stuck in this loop, do not panic and do not delete your repository. You can easily peel back your last commit, keep all your modified files intact, hunt down the oversized files causing the issue, and push your code successfully.
Here is a detailed, step-by-step walkthrough on how to fix it.
Step 1: Undo the Bloated Commit (Without Losing Your Changes)
Your first instinct might be to fear that your hard work is locked away or that you need to manually copy your code elsewhere. Git has a built-in time machine for this exact scenario: the soft reset.
Run this command in your project terminal:
git reset --soft HEAD~1 Why this works:
A --soft reset tells Git to roll back your repository history by exactly one commit (HEAD~1), but it leaves your actual workspace entirely alone.
Your files will not be changed or deleted. Instead, they will instantly return to your staged area (they will show up as green modifications when you run git status), ready for you to adjust, split up, or re-commit.
Step 2: Track Down the Culprit Files (> 50MB)
GitHub has a strict limit on file sizes. It will throw a warning for any file over 50MB and completely reject pushes containing files over 100MB. Since you are pushing hundreds of objects, there is a high probability a heavy asset, database file, or unignored package folder accidentally slipped into your staging area.
Let’s find exactly which file is blowing up your payload. Run the command that matches your operating system:
For macOS & Linux Users
Open your terminal and run this command to scan your directory while ignoring the internal .git folder:
find . -type f -size +50M ! -path '*/.git/*' For Windows (PowerShell) Users
Open PowerShell inside your project directory and execute this script to print a clean list of files over 50MB along with their formatted sizes:
Get-ChildItem -Recurse | Where-Object { $_.Length -gt 50MB -and $_.FullName -notlike '*\.git\*' } | Select-Object FullName, @{Name="SizeMB";Expression={"{0:N2}" -f ($_.Length / 1MB)}} Option C: Check Only What You Staged
If you want to focus exclusively on the files that were included in the commit that just failed, you can run this command to list your staged files ordered by size:
git diff --cached --name-only | xargs -I {} du -sh "{}" | grep -E '^[0-9.]*[MG]' Step 3: Handle the Large Files
Once you have identified the files crossing the 50MB threshold, you have two primary ways to proceed depending on whether those files actually belong on your remote repository.
Scenario A: The files shouldn't be on GitHub
If the oversized file is a local database, log file, build artifact, or a dependency directory (like node_modules), you should exclude it.
- Unstage the large file so Git stops trying to commit it:
git rm --cached <path/to/your/large/file> - Add it to your .gitignore file so you don't accidentally stage it again in the future:
# Open your .gitignore file and add the path or extension: path/to/your/large/file Scenario B: You absolutely need these files on GitHub
If the files are critical assets (like video files, datasets, or graphics) that your team needs access to, standard Git won't cut it. You need to use Git Large File Storage (LFS).
- Install Git LFS on your machine (if you haven't already) and initialize it in your project:
git lfs install - Tell Git LFS to track your large file type (e.g., .psd, .zip, .mp4):
git lfs track "*.mp4" - Make sure your .gitattributes file is staged alongside your work:
git add .gitattributes Step 4: Optimize Git Configuration & Push Again
Even after removing or tracking large files, pushing 500+ objects simultaneously can still stress a standard network connection. Let's optimize your local Git environment to handle larger transfers before you attempt your next push.
- Boost the HTTP Post Buffer
By default, Git’s HTTP buffer size can be too small for massive initial pushes. Increase it to 500MB by running:
git config --global http.postBuffer 524288000 - Prevent Low-Speed Timeouts
If your internet speed fluctuates or drops momentarily during the upload, GitHub might cut the line. You can eliminate the low-speed threshold timeout with these configurations:
git config --global http.lowSpeedLimit 0 git config --global http.lowSpeedTime 999999 - Re-commit and Push
With your files cleaned up and your network buffers expanded, you are ready to try again. Create a fresh commit and push your code:
git add . git commit -m "chore: optimize assets and clear heavy payloads" git push origin <your-branch-name> Alternative: Push in Smaller Batches
If your network continues to drop the connection even after updating your settings, your network architecture or proxy might still be struggling with a single giant push. You can bypass this by tricking Git into pushing chunks of your commits sequentially rather than all 596 objects at once.
- Review your commit log history to find sequential milestones:
git log --oneline - Manually push up to a specific older commit hash first:
git push origin <COMMIT_SHA>:<BRANCH_NAME> - Once that chunk successfully reaches GitHub, push the next batch, or push the rest normally with a standard git push.
Wrapping Up
Getting disconnected mid-push can feel like hitting a brick wall, but it's almost always a combination of hidden large files and restrictive HTTP buffer defaults. By running a git reset --soft, hunting down your massive files, and updating your http.postBuffer, you can take control of your repository state without risking a single line of your code.
Have you encountered this specific Git error before?
Did increasing your buffer size solve it, or did you find a massive untracked file lurking in your directory?
Let's discuss in the comments below!
