Note that there are some explanatory texts on larger screens.

plurals
  1. POImproving Git workflow and optimization for PHP [magento]
    text
    copied!<p>Background information </p> <p>We are working to shift from using SVN to GIT, we work mainly on magento stores and have a staging server and production server for every project. </p> <p>The process in simple terms: the code is first developed on the local machine with the project setup on every dev machine, this is then committed to staging repo and tested by client and QA and then to master where it goes to production and final testing by QA.</p> <p>We use codebase/github repositories and deployment to staging is automatic using deployhq and deployment from master to production is done by the sys admins using deployhq.</p> <p>The GIT Workflow has been derived after being influenced by different workflows suggested over the internet and uses chunks of <a href="http://nvie.com/posts/a-successful-git-branching-model/" rel="nofollow noreferrer">http://nvie.com/posts/a-successful-git-branching-model/</a> and <a href="https://stackoverflow.com/questions/7575363/proper-way-to-use-git-github-php-system-with-dev-testing-production-servers">Proper Way To Use Git/GitHub - PHP System with Dev/Testing/Production servers</a> along with others but also includes the commands which I think is consistent with this model.</p> <p>GIT Workflow</p> <p>0] setting up new GIT project locally</p> <ul> <li>git clone [path_to_repo] -b [branch_name] [local_dir]</li> <li>path_to_repo can be either remote repository or branch bundle (repo.bundle) </li> </ul> <p>1] Setting the remote path in case of bundle import</p> <ul> <li>git remote set-url origin [path_to_repo]</li> <li>path_to_repo is the remote repository</li> </ul> <p>2] Create a new feature branch based on the tasks assigned.</p> <ul> <li>git checkout -b [branch_name] // create new branch and switch to it</li> <li>git push origin [branch_name]</li> </ul> <p>3] All changes done locally in the local branch and pushed to remote branch periodically (in batches, not single change!) If someone wants to work on same branch, he needs to pull data from same remote branch not from master.</p> <ul> <li>daily routine</li> <li>git checkout [branch_name] // switch to the branch</li> <li>git pull // pull latest changes from remote (e.g. in the morning before we start working)</li> <li>make changes in files</li> <li>git add . or git add [folder] // prepare list of files to be committed or file/folder </li> <li>git commit // commit changes to local branch</li> <li>git pull // pre-push sync at the end of the day to become aware of any conflicts</li> <li>git push // push changes to remote branch at the end of the day</li> </ul> <p>4] Once the changes in the remote/local branch are working and need to be reviewed on staging server the local branch will be merged into remote staging branch. </p> <ul> <li>git checkout staging // if already exist switch to it</li> <li>git merge [remote_branch_to_merge_to_master] </li> <li>git push</li> </ul> <p>5] if the Client confirms the remote branch to be working fine and ready to be deployed to live server, merge into master</p> <ul> <li>merging to the master</li> <li>git checkout [master_branch_name] // switch to master</li> <li>git pull origin/master</li> <li>git merge [remote_branch_name_to_merge_to_master] // merge into master</li> <li>git push</li> </ul> <p>Master to Production is done through deployhq manually by the Sys Admins.</p> <p>Q] Should there be another branch production which will be based on master and get only the changes from master that are going live right away i.e. always the most stable code or is this redundant.</p> <p>We are looking for suggestions on reducing the number of steps and if the workflow is consistent with the best practices in GIT including the commands mentioned with it.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload