-
Notifications
You must be signed in to change notification settings - Fork 4
Development workflow
The following assumes you know git. I thought the official documentation/tutorials/cheatsheets linked from the official git site were pretty good for learning.
Recommended resource for clarifying and solidifying your understanding of git: Mark Lodato's Visual Git Reference.
You will make small changes (i.e., changes that you make over the course of a day rather than those that will be in development for > 1-2 days) in the eschol_prod branch, which is the default branch for our OJS instance (as opposed to the official PKP OJS repo from which our repo is branched.)
Check that you're on the the eschol_prod branch on your local machine:
git branch # make sure this is 'eschol_prod'
Bring your code up to date
git pull
In your local repo in the eschol_prod branch: hack, hack, hack...
cd to eschol_ojs/lib/pkp
You must switch to eschol_prod branch first!
git checkout eschol_prod
Make your changes, then do these steps, still within the submodule:
git commit -a -m "message" # stage and commit your changes
git pull # pull any updates from github. If there are any conflicts, resolve them...
git push # push your changes to github
Check the logs on github
Then cd to ../eschol_ojs and do a commit, pull and push from there.
Commit your change and push it to github by executing the following:
git commit -a -m "Type your clear and concise commit message here."
Rebase your local eschol_prod branch to latest version from github:
git pull
If there are conflicts: resolve, merge, commit.
Push your changes to the cdlib/eschol-ojs repo on github:
git push
Important Note: In the (fairly unlikely) event that you have made changes to the eschol-pkp-lib submodule (i.e. under eschol-ojs/lib/pkp/), make sure that y ou always commit your submodule changes first, and then commit changes in the base eschol-ojs repository. Since there is a somewhat complex relationship betwee n the "base" (i.e. eschol-ojs) module and the submodule that allows that allows them to be tracked together. For a thorough explanation of this, see the PKP Wik i entry on [How to deal with the /lib/pkp submodule entry when committing changes ](http://pkp.sfu.ca/wiki/index.ph/Frequent_git_use_cases#How_to_deal_with_the_ .2Flib.2Fpkp_submodule_entry_when_committing_changes)
Go to the ojs repository on the submit-dev machine.
cd apache/htdocs/ojs
Check that you're on the the eschol_prod branch:
git branch # make sure this is 'eschol_prod'
Pull your recent changes from github by executing:
git pull
git submodule update
Check your changes by going to the OJS dev website and/or verifying your changes directly on the machine. You can also check the git log by executing:
git log # your recent commit should appear at the top of the log
Repeat the above steps on the submit-stg machine.
When you're sure you're ready for your changes to appear on the live site, repeat the above steps on the submit prod machine.
Now dev, stage and production should all be in sync with the eschol-ojs repo (eschol_prod branch) on github.
This is the same as for smaller changes except that you'll create a development branch and then merge your changes into the eschol_prod branch when you're ready.
Start a new branch:
git branch # make sure this is 'eschol_prod'
git pull # bring your code up to date
git branch yourNewBranch # like mh_bigChanges_2012
git checkout yourNewBranch # switch to your new branch.
git branch # confirm you are on your new branch; it will have an "*" next to it
Work, work, work in your branch.
work work work
git add
git commit
work work
git add
git commit
git push origin yourBranch # "origin" is the name of our repository on github
git branch -r # this will display all of the remote branches and confirm that yours is there to checkout
git checkout yourBranch # switch to yourBranch. Changes can now be demoed and tested on the dev machine
When you're satisfied with the results on DEV (as in step 2.3) and are ready to put your work back into the mainline, do this:
git checkout eschol_prod
git pull
git merge yourNewBranch
git push
Assuming there are no conflicts, your work is now in the main branch. (No commit is necessary, as git merge does it for you).
To get your work onto the servers, do a "git pull" of the eschol_prod branch on each server.
You can also continue developing in your branch, and then repeat the above procedure with the next batch of changes.
When you're done with the branch, delete it:
git branch -d yourNewBranch # this removes it from your local development area
git push origin :some_branch # this removes it from github