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

Windows

Mac OSX

Install Git for OSX:

  • Standalone package:
    • Grab the latest git installer for your version of osx from Git for OSX
    • Run the contained pkg
    • If you want git to be accessible via the PATH and MANPATH variables for non-terminal programs, run the included shell script.
  • MacPorts:
    • sudo port install git-core

Generate an SSH Key:

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 “yourmail@domain.tld”

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

Setting up your Github repository:

Once you’ve set up your repository on Github, you need to create a clone of the repository in each instance of Moodle you want running.

Clone the repository

  • With Github Token
  • With SSH RSA-key
    • git clone gitgithub.com:ucla/moodle.git ./YOUR_LOCAL_MOODLE_FOLDER/@

Now that you have a working clone of the repository in your working area, you can execute one of the following directives:

Set up your workflow

  • 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

  1. git checkout `git tag | grep "\-rc\$" | sort -r | head -1`
  2. git checkout -b feature/<feature_name>
  3. Repeat the following steps as necessary:
    • - change file(s) -
    • git commit -a -m "CCLE-#### - A useful short comment summarizing what you did."
  4. git push origin <feature_name>
  5. This should be done whenever there is a new RC tag available:
    • git merge `git tag | grep "\-rc\$" | sort -r | head -1`

Once the feature has passed code and administrative review

  1. git checkout development
  2. git merge --no-ff feature/<feature_name>
  3. git push origin development

-Start- TEST machine ONLY

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

  1. git pull origin development

-End- On TEST machine ONLY

Once the feature(s) has been successfully tested and passed:

  1. git tag M.m.v.rr-rc -m "CCLE-####: Description (and more as needed)"
    • M.m.v.rr-rc is [Moodle Major Version].[Moodle Minor Version].[Moodle Incremental Version].[Internal Version]-rc, where ‘rc’ stands for ‘release candiate’.
  2. git push origin M.m.v.rr-rc
  3. git checkout master
  4. git merge --no-ff M.m.v.rr-rc
  5. git push origin master

-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 "CCLE-####: Description (and more as needed)"
    • The numbers M.m.v.rr should be the same as the numbers for the RC tag.
  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

  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. Decide to pull up as a hot-fix or as a feature
    • As a hot-fix:
      • git checkout `git tag | grep "\-gm\$" | sort -r | head -1`
    • As a feature:
      • git checkout `git tag | grep "\-rc\$" | sort -r | head -1`
  2. git checkout -b merge/M.m.v
  3. git remote add upstream https://github.com/moodle/moodle.git
  4. git fetch upstream
  5. git merge -m "Upgrading Moodle to version X.Y" <commit_hash> (hopefully there will be a JIRA ticket relating to this.
  6. Resolve conflicts
    1. git add <conflicted_file>
    2. git commit -m "upgrading Moodle to version X.Y"
    3. If needed, continue the merge
  7. Finish the pull up as a hot-fix or a feature.
    • As a hotfix:
      • Test and push to STAGE, release on PROD, then back push to development.
    • As a feature:
      • Push to development, test on TEST, push to STAGE then release on PROD.
    • Be sure to notate the new RC and GM tags with the updated Moodle version M.m.v.00
Back to top