Git Workflow Magento Way
Magento development isn’t typical software development. Rarely with Magento we have defined releases and often code must be deployed while in development for client to review and approve.
This is why I’ve tried to come up with Git workflow model that would be best for Magento development teams.
Git repository with two main branches (develop and master)
Typical Magento client needs constant monitoring of features developed, so we need to be able to separate live website code from development website code. This is why we use 2 main branches. Develop branch that would represent latest developed code and would also be testing point for clients. This branch will be set to auto deploy to development server ( staging server can also be auto deployed from this branch ). Master branch that would represent latest stable code and will be deployed to live website whenever we merge into it.
Five steps development phase
Magento development can be split up in development phases. Development phase can be: “building new Magento store from default Magento code”, “development of new theme for already running store”,… Things like that, generally multiple tasks grouped into one development phase where live website isn’t changed before all tasks inside that phase are fully completed. Sometimes we only have one development phase while other times we may have new development phases started every few months. It can greatly depend on project, client requirements and his business needs as well as website results.
Workflow
Each development phase consist of these five steps:
- Phase Start
Both develop and master branches will be initiated with most recent code from live website, or with vanilla Magento if client doesn’t have live website at that point. If this is not first development phase on your project you can skip this step. Just make sure all other branches except develop and master branch are deleted at this point.# Clone your repository git clone https://github.com/username/Hello-World.git # Add initial code to master branch # This is either current live website state or vanilla Magento installation git add --all . git commit -am "initial code for phase 1" git push origin master # Create develop branch from master and push to remote git checkout -b develop master git push origin develop
- Pre Launch
Each task is branched out from develop branch, and when done, –no-ff merged back to develop branch only. Task branches can be local or pushed to remote if multiple developers have to work on same task. Tasks branches can be deleted both from local and remote after task is completed.# Create new task branch git checkout -b newTask develop # Work on newTask and push to remote git add --all . git commit -am "newTask changes" # Next line may not be needed if only one developer will work on newTask git push origin newTask # Merge changes with develop branch and push to remote for client to review # --no-ff is used to reflect all commits from newTask branch into develop branch git checkout develop git merge --no-ff newTask git push origin develop # Delete newTask branch, from local and remote, when all work is done and approved git branch -d newTask # next line should be executed only if you've created remote branch earlier git push origin --delete newTask
- Launch Day
On launch day, we will branch out current code state from develop branch, tag it, and –no-ff merge into master branch. Launching branch can be deleted after merging.# Make sure you have latest code from develop branch git checkout develop git pull origin develop # Branch out from develop git checkout -b launchTask develop # Merge into master branch and push to remote ( publish on live website ) git checkout master git merge --no-ff launchTask git tag -a launch-1.0 git push origin master # Delete launch task git branch -d launchTask
- Post Launch
Each task is branched out from master branch. When we finish some part of work on these tasks, and when we need to show progress to client, task branch is –no-ff merged into develop branch. We may need to do this few times for some tasks, before client approves changes and is ready to apply changes to live website. When all task related changes are done, tested and approved by client, we will –no-ff merge task branch into master branch. Tasks branch can be deleted after merging into master.
This process will enable us to start multiple tasks, and have different progress speed on each tasks, and most important we can apply only tasks related changes to live website.# Make sure you have latest code from master branch git checkout master git pull origin master # Create new post launch task branch git checkout -b newPostLaunchTask master # OR if you are working on already created task git checkout newPostLaunchTask # Work on newPostLaunchTask and push to remote git add --all . git commit -am "newPostLaunchTask changes" git push origin newPostLaunchTask # When client needs to review, merge with develop branch git checkout develop git pull origin develop git merge --no-ff newPostLaunchTask git push origin develop # At this point client may require some changes. In that case we will keep repeating last 2 steps ( work and merge to develop ) until client is happy with changes and is ready to publish them on live website # When all changes are done and approved by client, merge with master branch ( publish on live website ) git checkout master git pull origin master git merge --no-ff newPostLaunchTask git push origin master # Delete newPostLaunchTask branch from local and remote git branch -d newPostLaunchTask git push origin --delete newPostLaunchTask
- Phase End
When client doesn’t have any more requirements or when we have enough new requirements to build new development phase, our current phase is finished and we may start new development phase. At this point, repository will contain only two main branches, all other branches will be deleted before new phase is started.