Hey Shubham, what I’m doing may not be the intended workflow so I wouldn’t expect there to be formal documentation around it. Nor would I expect what I’m describing to continue to work this way in the future.
With that said, if it helps all I’m doing is using standard git commands to navigate a fairly standard development workflow.
There’s essentially three repository instances:
local -> fly <- phoenix_new
Your local repository and the Phoenix.new IDE repository both connect to the same fly repository. That’s the bridge between the two development environments.
As an added bonus, the Phoenix.new instance is smart and pushes changes made in Phoenix.new to the fly repository automatically. So there’s even less you have to manage yourself!
Pushing changes from local to Phoenix.new
If I haven’t done it already, the first step I have to do is clone the repository locally. I use the standard command provided by the Phoenix.new interface to do that. This only has to be done one time.
Once it’s cloned, I cd into the repository. I make my local code changes and commit them. Then it’s time to push those changes into the fly repository.
Connections with the fly repository use tokens that expire quickly (which is a good thing). But it does mean you have to remove and re-add the remote repository often. I do that by running git remote rm fly.
With the git remote cleared, you can use the standard command provided by the Phoenix.new interface to push your changes. At the time of writing, all that command does is a git remote add fly ... && git push fly main.
Once the changes are in the fly repo, the last step is to get them into the Phoenix.new repo. To do that, I open the command line in the Phoenix.new Web UI. Then I do a standard git fetch fly and git merge fly main.
Pulling down changes from Phoenix.new
Since changes are automatically synced from Phoenix.new to the fly repository, there’s nothing you have to do manually on that side. The only thing you have to worry about is pulling down the latest changes from fly to your local repository.
There’s two ways to do that.
One way to do this would be to just clone the repository again using the command provided in the Phoenix.new web UI.
A second way to do it is to manually manage the remote fly repo definition. This is essentially the same commands as above, just in reverse. Clear your existing remote git remote rm fly and then add it back using the git remote add fly ... && git push fly main provided in the Phoenix.new web UI.
Conclusion
The good news as at the time of writing, it’s all just git. And Phoenix.new provides you plenty of help in generating the additional information needed. It’s just a matter of slowing down, thinking through what you’re given, and then doing some commands to wire it all together.
I was being thoughtful about usage, but couldn’t gauge how close I actually was. Watching the agent get stuck in a debug loop a few times and burning resources wasn’t the funnest. Even so, hitting the end was a surprise!
I have a potential workaround for the git issues, see the next reply for details.
