Improving Git workflow and optimization for PHP
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.
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.
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.
The GIT Workflow has been derived after being influenced by different workflows suggested over the internet and uses chunks of http://nvie.com/posts/a-successful-git-branching-model/ and Proper Way To Use Git/GitHub – PHP System with Dev/Testing/Production servers along with others but also includes the commands which I think is consistent with this model.
0] setting up new GIT project locally
- git clone [path_to_repo] -b [branch_name] [local_dir]
- path_to_repo can be either remote repository or branch bundle (repo.bundle)
1] Setting the remote path in case of bundle import
- git remote set-url origin [path_to_repo]
- path_to_repo is the remote repository
2] Create a new feature branch based on the tasks assigned.
- git checkout -b [branch_name] // create new branch and switch to it
- git push origin [branch_name]
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.
- daily routine
- git checkout [branch_name] // switch to the branch
- git pull // pull latest changes from remote (e.g. in the morning before we start working)
- make changes in files
- git add . or git add [folder] // prepare list of files to be committed or file/folder
- git commit // commit changes to local branch
- git pull // pre-push sync at the end of the day to become aware of any conflicts
- git push // push changes to remote branch at the end of the day
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.
- git checkout staging // if already exist switch to it
- git merge [remote_branch_to_merge_to_master]
- git push
5] if the Client confirms the remote branch to be working fine and ready to be deployed to live server, merge into master
- merging to the master
- git checkout [master_branch_name] // switch to master
- git pull origin/master
- git merge [remote_branch_name_to_merge_to_master] // merge into master
- git push
Master to Production is done through deployhq manually by the Sys Admins.
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.
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.
One Solution collect form web for “Improving Git workflow and optimization for PHP”
One of the ways to do it:
There are three main branches: master (development), staging and production. Staging and dev are deployed automatically via git post-receive hook and some bash scripts, production is deployed by tech lead manually running deploy script.
Work is done on master, without pushing until feature is complete (unless feature is a very complex and drastically changes a lot of things). Developer tests feature on dev site (build script is launched after every push), sends feature to QA department (if you have one), after QA people are done coder sends work to a code review to a tech lead, client approves work on dev.
Once in x days master is merged in staging, QA runs thru staging, client confirms features second time.
After all issues are confirmed in staging, staging is merged in production and production branch is deployed live.
P.S: All three environments are hosted on different machines, staging and production have exact same configuration, dev doesn’t have to strictly follow every live server config tweak – so you can have one machine for all dev sites.
Important P.P.S: In order to have all work in one branch you need to use some issue tracking system and specify an issue number in every related commit.
P.P.P.S: Using pull –rebase instead of pull keeps git history cleaner and easier to read.