This new requirement to create new branches is terrible and is making my testing and platform development practically impossible.
The old pull/publish workflow was infinitely better and worked perfectly well.
I use v0 every single day, and just this month alone I’ve already spent over $450 on v0. However, with this new approach, I won’t be able to continue and will have to migrate to another platform.
This new update is awful.
support you bro, impossible to work with github after new update
I agree. Im in the same boat. Changes are pushed. it doenst detect deploynet errors like multiple dynamic url slugs. It cost me 4 hours of headaches and $125 in tokens.. this new git update is sooo bad and wasting time. How can we go back to the old publish method. I like when i can choose when to create a new branch and not require it on all publsih
How can i upvote this comment a million times. I am about to jump ship off v0 if this goes forward.
After PR is created, I cannot push new changes to the existing PR. I don’t know why they came up with this new workflow. Terrible.
I thought it’s just me. I even told v0 I don’t want to publish/merge, because then I need to start a new branch and explain everything over again. It said: you CAN continue in this chat…
the new system is just flat terrible.
Vercel Alum
Thank you all for your feedback
I'd love to dig deeper here - what exactly about the Git workflow doesn't work for you right now?
I want to go back to the old workflow:
edit → verify → manually push → sync to GitHub
not auto-sync on every single change.
I totally agree with the others. I want to work continually on a project and push to main branch on Git.
Manually when ready to test. No sophisticated pseudo mechanisms.
In addition I would have loved to continue the original thread for knowledge and documentation purposes.
Commiting and merging branches has forced to create new threads where I started almost from zero with the sequent prompts.
Gained knowledge and instructions regarding working habits and methods were gone. In my world this is unprofessional.
I also dislike this new integration. Making a new chat/constant forking, being forced to push to github, unable to just simply deploy when I want to from the v0 sandbox- all of it is terrible. You can’t even revert versions anymore in previous chats- that ability is gone.
reply to #14
Hello Pauline,
Thank you for the update about the upcoming UX improvements. I really appreciated the previous workflow where I could simply press “Publish,” so I wanted to clarify how the new branching process works before proceeding further.
I’m a bit concerned that creating a new branch may cause me to lose the work I’ve already done or require me to re-explain or reconfigure the entire project. This site has been live for a couple of months now, and I’ve been working on it daily for several months, so I want to be very careful before taking any irreversible steps.
I did complete the recent update successfully, but prior to fully understanding the new workflow, I clicked the button in the top-right corner. I'm curious, after the chat did its thing after asking to implement the changes, did this automatically push the changes? (was this the intention, once confirmed updates will push?) The update appears to have gone through, however I’m now being prompted to create a new branch, and I’m unsure whether doing so will require me to start over — including re-entering environment variables and other configurations.
If creating a new branch will preserve all existing work and settings, I’m happy to proceed. I just want to be absolutely certain before moving forward, as redoing the entire project would be extremely disruptive.
Thank you so much for your help and clarification — I really appreciate it.
Best,
J
I actually think I will learn to like this update, after implementing changes automatically, the more I read, the more it makes sense.
I may have overreacted and I apologize .
I didn’t realize after saying “implement” it automatically went live so I pressed pull request where publish once WAS and got confused. I am reading more currently. Just trying to understand the next steps. I think, if im right, this new branch is like a testing ground but all my env vars remain, and once I make the next “update” AFTER pressing “new branch” the project will be ok and project will remain intact. No re-entering of env vars etc.
Thanks again!
reply to #11
Hello, I just logged into v0 to work on my product i’ve been building for 3 months. When I hit publish, it opens up the new publish pull request, when I hit that button it says “unexpected error occurred” and shows no other information, so I can’t publish any of my updates. Is there anyway to choose to use the old publishing method? This is honestly terrible, i’m exporting my .zip and won’t be able to use v0 until this is fixed. I’ve spent $1000+ with v0 and I’m disappointed.
100% in the same boat, it won’t even let me publish a pull request at all.
reply to #14
Thanks for the info. But:
Never try to improve something that has proven to be a step in the wrong direction. Roll back instead!
New in-chat GitHub panel to connect, see sync status, branches and commits. (Obsolete)
Vercel Alum
Hey there! Just checking in to see if you still need help with the pull/publish workflow issue we discussed. Have you found a solution or any updates on your end? Excited to help!
reply to #17
Hey — I was stressed for absolutely no reason. The issue? I didn’t understand the new workflow. Why? Because I didn’t read. Shame on me 😅
Once I actually took the time to read, understand, and do some simple research and verification (AI is very helpful here, by the way—breaking things down, checking updates, and explaining them in plain English), it clicked. This new update is actually better.
It compartmentalizes the workflow. Instead of one super long chat conversation—which can easily lead to confusion, errors, and frustration—you can work in focused, isolated chunks.
For example, you can say:
“Continue from main.
The site is live and working with the latest merged changes.
Environment variables are already configured and should not be modified unless explicitly requested.
Please analyze the existing codebase and project files to understand the current structure and data flow before making changes. Do not rely on prior chat history.
Provide your data sources if you have any. Determine your rules, and continue.”
The problem with one massive chat is that if you’re trying to fix a small issue from several steps back, it becomes much harder. With smaller, isolated changes merged into the main repo, you can localize the issue, work directly off that specific change, fix it, and—voilà—you’re back in business.
Another thing I’ve found helpful: before publishing, confirm the work. Have the AI explain what was accomplished. If something’s off, fix it, ask again, and move forward. You can even add something like:
“After implementing, tell me what was done, how it works, and confirm any rules or assumptions.”
Overall, I’m genuinely really happy with this workflow. It’s clearer, more controlled, and way less stressful once you actually understand how to use it.
IF ANYONE has questions, before freaking out, just ask — I have been through plenty of… unnecessary headache, due to a lack of understanding on my part.
PRACTICE MAKES PERFECT.
-J
reply to #14
Thank you so much Pauline for giving us the option to use this workflow! Truthfully it just works better for me as I’m testing two live applications and it just made sense, easier to deploy and check post deployment changes. Making a new chat even for small commits to go live causes serious issues for my project version serialization! All jokes aside, I love v0 and I am a very satisfied customer. Again, thank you for a graceful solution that benefits everyone on both camps! Cheers.