CODEWITHSUNDEEP
gitgit-svnmagento
Kevin Katzke
Kevin Katzke

Reputation: 3771

Basic git workflow understanding

I have some basic git questions, which i do not understand yet I hope someone can help me. Lets say I'm working on a Magento project, I run it local but i want to bring it online. So i push my shop to my server using git. Everything works fine until Magento provides an update. So here is my question:

I make any changes in my local directory and git add + git commit them, but when i update my Magento Shop through Magento Connect from 1.7 to 1.7.1 I will have a different setup on my server then I have on my local computer, right?

So what do I have to do, do make them equal? Do I have to make a checkout from the version runed on my server and replace it with my local magento?

Upvotes: 1

Views: 444

Answers (2)

Krista K
Krista K

Reputation: 21871

I (am attempting to) use this workflow with my Magento installation and upgrade. IMHO, there is no way to seamlessly upgrade a Magento live site. At some point, downtime is needed to stop orders coming in while the DB rebuilds to the newer version.

The closest I get is to set up another cloud instance with the new version running and nuke the database once all the bugs are worked out. Then import the current live DB and let the new magento host churn on that for a while.

Then decide whether to disable your old site requiring manual data entry once the upgrade is finished.

Then once new Magento host is working, switch the domain to point to the new instance.

Upvotes: 0

Tim Hofman
Tim Hofman

Reputation: 1068

From a version control point of view you do not want to have your development environment and live environment on the same branch. For example you could use the master branch for your development and then have your live environment on a stable branch. There are also branch structures with multiple feature, release and hotfix branches. But lets keep it simple for now.

Regarding updates. You never want to run them on a live environment directly. It's nearly impossible to do a rollback of the related DB changes. So always update and push your work upstream from dev to live instead of the other way around.

So always do upgrades on your dev environment (thus master branch), and after testing commit them to your repository. Afterwards you can either merge or cherry-pick to the other branch. Afterwards update the live branch (i.e git pull or git fetch, git rebase) to deploy the upgrade.

Upvotes: 1

Related Questions