I've been seeing a lot of people on LinkedIn especially who are vibe coding and deploying straight to their live website or application.
Big mistake. Huge.
Of the people who are using repositories ("repos"), a great many are essentially using them as off-site backups or google drive folders. This is better than not using them, but you are missing an opportunity and making life harder for yourself.
How many times have you been using your "helpful programming robot" tool of choice and they get really stuck. Sometimes they get stuck because you have been doing so much inter-related stuff they run out of "context window".
You have two choices at this point, roll back everything that they have done recently (if even they can figure that out), or plow ahead and hope the digital gods are feeling kind.
Sometimes plowing ahead "works", in that the code compiles again, but now includes all of the failed attempts, duplication, stupid algorithms, backdoor opportunities, and general slop now littering your codebase. There might be some silent but deadly cowpats in your meadow lurking along with your fresh feature daisies.
Another occasion that frustrates developers, bot assisted or not, is heading off down a rabbit hole and then deciding you know what? It was better before.
Even when you have something working, did you document all the little fixes/patches/installations/configurations that got you there? Are you sure deploying live won't bork something really badly?
All of this can be avoided by keeping a pristine copy of your project with only the good stuff, and as the name suggests, branching off when you are about to diverge from that working state.
Don't get me wrong, while I have been benefitting from this (and similar) workflows for a long time, I'm not in any way a git expert or even particularly super-organised, so don't hold back - if you have any tips, rants, or corrections for me, I am all-ears.
TL;DR:
Don't Ever Deploy Changes Directly to Live, even if it feels really urgent.
Rather than keep everything all in one repository timeline, it is a lot safer and less stressful to create a new branch for any additional changes or to add a new feature.
Safe: Your new work is isolated
Experimental: Test changes without affecting stable code or active users
Reversible: Easy to undo if needed
Trackable: Clear history of what changed when (and by whom)
Collaborative: Can queue features/improvements/fixes for review
Flexible: Can switch back and forth with git checkout ______
# Switch to staging
git checkout staging
# Switch back to feature branch
git checkout Feature/feature-42
# List all branches
git branch -a
Another advantage to this kind of approach is making it clear what a piece of work is for. Your "OMG there is a channel tunnel sized security hole" needs more urgency than "I fixed a typo in doc 12348".
- feature/feature-name
- bugfix/bug-ticket
- hotfix/security-issue
- release/v1.42
- docs/deployment.md
First step is creating that new branch.
cd /Users/chrisg/github/example.com
git status # Ensure working tree is clean
git branch # Confirm you're on the right base branch
You might find the people you work with have a different policy, for example basing your branch on the latest release, but if working on your own project then using staging as your source is fine.
Replace staging with your integration branch name if different.
Eg. In many projects, develop or main might be used instead.
# If on staging already
git pull origin staging
# If on another branch, switch first
git checkout staging
git pull origin staging
Create & switch in one command
git checkout -b Feature/feature-name
Option 2: Git 2.23+
git switch -c Feature/feature-name
Option 3: Two-steps
git branch Feature/feature-name
git checkout Feature/feature-name
git branch # Shows all local branches, * indicates current
git status # Confirms you're on the new branch
Git creates a new branch pointing at your current commit
Your working directory switches to the new branch
All future commits go to this new branch
The base branch (staging) remains unchanged
New branch includes all updates from the base branch
After making your first commit on the new branch:
git add .
git commit -m "My amazing codes are ready to test boss!"
git push -u origin Feature/feature-name
(The -u flag sets up tracking so future pushes only need git pushand future pulls use git pull)
# Ensure staging is current
git checkout staging
git pull origin staging
# Create and switch to new branch
git checkout -b Feature/feature-name
# Verify
git status
# Make changes, then...
git add .
git commit -m "Describe Your Changes"
git push -u origin Feature/feature-name
Once you are happy with how your project looks locally on your development environment, the next test is to see if it works works, or just "works for me on my machine!".
cd /Users/chrisg/github/example.com
git status # Check what's changed
git add .
git commit -m "new example.com pages + performance optimisations"
This saves your work on the feature branch
git push origin Feature/feature-name
Pushes up your feature branch to remote
git checkout staging
git pull origin staging
Gets any updates others may have pushed to staging
git merge Feature/feature-name
Merges your changes into the rest of the updated code in staging
git push origin staging
Deploys your changes to the staging branch and possibly the staging environment too depending on your automation setup.
CONFLICT (content): Merge conflict in app/example.php
The main worry folks have about this workflow is what happens when my code rushes headlong into someone else's changes?
Not to worry! We got this ...
How to fix:
Open the conflicted file(s)
Look for conflict markers: <<<<<<<, =======, >>>>>>>
Edit to keep the correct code
Remove the conflict markers
Run:
git add .
git commit -m "Resolve merge conflicts"
**NB.** git merge --abort is an option if you want to back out of the merge entirely.
What it looks like:
error: Your local changes to the following files would be overwritten by checkout
How to fix: Go back to Step 1 and commit your changes first
What it looks like:
! [rejected] staging -> staging (fetch first)
How to fix: Someone else pushed to staging while you were merging:
git pull origin staging
# Resolve any conflicts
git push origin staging
# Navigate to project
cd /Users/chrisg/github/example.com
# Commit current work
git add .
git commit -m "Add feature to pages with performance optimisations"
# Push feature branch
git push origin Feature/feature-name
# Switch to staging
git checkout staging
# Pull latest staging
git pull origin staging
# Merge feature into staging
git merge Feature/feature-name
# Push to staging
git push origin staging
There are two aspects to using a staging server. First, the staging environment should be as close to possible to the live as you can get it, so you are simulating your changes without your test-test-test-v4-definitely-final-this-time files.
Also, if it crashes and burns your staging environment on deploy, that is a lot easier to deal with than the live site/app going weird while people or your boss/client are using it.
Check staging site is working: https://staging.example.com
Test feature-name page
Verify page load times are acceptable
Check images are displaying correctly
Verify inputs work
If the staging site breaks after merge:
# Switch to staging
git checkout staging
# Find the last good commit
git log --oneline
# Reset to previous commit (replace COMMIT_HASH with actual hash)
git reset --hard COMMIT_HASH
# Force push to staging (ONLY use on staging, NEVER on main branch!)
git push origin staging --force
git reset --hard discards local uncommitted changes permanently.
For remote repos with multiple contributors, git revert is usually safer than a forced push.
Next, notify/apologise to colleagues/client!