Skip to main content

UCLA Git Walkthrough (for Moodle)

Very basic guide how to get GIT set up on Windows or OSX.

Documentation:

Setting up the Environment

Configure Line Endings

  • In order to avoid issues with line endings when cloning on to Windows machines, follow the directions here: Dealing with line endings

Setting up Git global configs

Before making commits, it is useful to add your name and email:

  • git config --global user.name "Your Name"
  • git config --global user.email "Your email address"

Set these git config settings

  • @git config —global push.default current // only push current branch to remote@
  • git config --system core.ignorecase false // makes sure that git is case sensitive

If you want to connect to github without SSH you need a token:

Setting up your Github repository:

Clone the repository

Set up your workflow

  • ! You only need to do this if you are a lead developer and have not set up your GitHub repository. !
  • Execute the following commands:
    • git checkout master
    • git branch development
    • git push origin development
  • This only needs to be done once. This will update the Github repository and all clones of your fork will now be able to pull these new branches from Github.

Work on a new feature/task

Name your git branch using our naming convention:

  • type/jira ticket-short description
  • The type, for now, should either be:
    • feature (something that has never existed before or an improvement to a current feature)
    • patch (a bug fix, can either come from internal or external sources)
    • tests (For Behat or PHPunit only branches)
    • update (reserved for core Moodle version and external plugin updates)
  1. git checkout master
  2. git pull origin master
  3. git checkout -b feature/CCLE-<JIRA ticket number>-<feature-name>
  4. Repeat the following steps as necessary:
    • - change file(s) -
    • git commit -a -m "CCLE-#### - A useful short comment summarizing what you did."
  5. git push -u origin <branch_name>
  6. Merge task onto TEST
    1. git checkout development
    2. git pull origin development
    3. git merge --no-ff <branch_name>
    4. git push origin development

Creating rc branches

  1. git checkout master
  2. git checkout -b <release_number>-rc
  3. Now merge in several branches with fixes/features that passed review
    1. git merge --no-ff feature/<feature_name>
    2. git push -u origin <release_number>-rc
  4. If one or more branches failed testing, then create another rc branch with the number incremented merge in the fixes/branches that work

-Start- TEST machine ONLY

At this point, there could be more than one feature that is being tested!

  1. git checkout -b <release_number>-rc origin/<release_number>-rc
  2. Once rc passes testing on TEST, merge it into master so it can go to stage
  3. git checkout master
  4. git merge --no-ff <release_number>-rc -m "Description of what was in this release/use JIRA version description"
  5. git push origin master
    -End- On TEST machine ONLY

-Start- On STAGE machine ONLY

  1. git pull origin master

-End- On STAGE machine ONLY

Once the feature(s) has been successfully test on STAGE and is ready for PROD:

  1. git checkout master
  2. git pull origin master
  3. git tag M.m.v.rr-gm -m "Description of what was in this release/use JIRA version description"
    • The numbers M.m.v.rr should be the same as the numbers for the RC branch.
  4. git push origin M.m.v.rr-gm

-Start- On PROD machine ONLY

  1. git fetch
  2. git checkout `git tag | grep "\-gm\$" | sort -r | head -1`
  3. Validate things are working…
  4. Finished with release cycle!

-End- On PROD machine ONLY

Push a bug fix/hot fix — Note: This no longer is needed, you should be able to cleanly expedite the regular workflow for urgent fixes.

  1. git checkout `git tag | grep "\-gm\$" | sort -r | head -1`
  2. git checkout -b bugfix/CCLE-####
  3. Repeat until you have the bug fixed in your working instance:
    1. - change file(s) -
    2. git commit -a -m "CCLE-#### - Description of bug fix."
  4. Once the bug has passed code and administrative review you can make a HF tag (or merge the branch directly)
    1. git tag M.m.v.rr-hf -m "CCLE-####: Description of bug fix."
    2. git push origin M.m.v.rr-hf
  5. Push it to STAGE
    1. git checkout master
    2. git merge --no-ff M.m.v.rr-hf
    3. git push origin master
  6. Update the STAGE machine
    1. git pull origin master
  7. Once tested on STAGE, make a GM tag.
    1. git tag M.m.v.rr-gm -m "CCLE-####: Description of bug fix."
    2. git push origin M.m.v.rr-gm
  8. Update the PROD machine
    1. git fetch
    2. git checkout `git tag | grep "\-gm\$" | sort -r | head -1`
  9. We need to back-push our hot-fix into our development tract
    1. git checkout development
    2. git merge --no-ff M.m.v.rr-hf
    3. git push origin development
  10. Each feature branch can merge the back-pushed tag if desired.

Pulling from a version from Moodle.org

  1. git checkout -b update/M.m.v
  2. git remote add core https://github.com/moodle/moodle.git
  3. git fetch core
  4. git merge -Xtheirs -m "CCLE-<ticket> - Upgrade Moodle to version X.Y" <version tag> (hopefully there will be a JIRA ticket relating to this.
  5. Resolve conflicts
    1. git add <conflicted_file>
    2. If needed, continue the merge
  6. Finish the pull.
    • Push to development, test on TEST, push to STAGE then release on PROD.
  7. Be sure to notate the new RC and GM tags with the updated Moodle version M.m.v.00
  8. To upgrade to a major release of Moodle, follow the instructions in this guide: http://tjhunt.blogspot.com/2014/01/moving-ou-moodle-code-to-moodle-261.html
Back to top