This is an old revision of the document!

Cloud Scheduler Collaboration Workflow with Github

  • This document assumes that you are already familiar with Git. If you need a lookup on Git, there is a nice once-page Git tutorial for you.
  • Also, you should already have a Github account and did some basic functions such as creating a repository and pushing changes to Github. If not, head over to more Github tutorials on that.
  • If you experienced any problems with any step in this document, please contact Joanna and she will update them here.

Repository Fork

  • An organisation has been created for CoEPP on Github to simplify management of group-owned repositories:
  • The upstream Cloud Scheduler repository on hep-gc has been forked to CoEPP organization:

Initial Setup

Join the Team

  • Before you start your work on development, please provide your Github username to Joanna for CoEPP group membership and git push permission.


  • Checkout the source code from the forked cloud-scheduler repository in CoEPP.
  • To clone the forked cloud-scheduler repository from CoEPP, use the following command with your own Github username instead:
    $ git clone https://<username>

Start Coding!

Developers please read the following items before starting coding.
  • All work should be done in dev branch:
    $ git checkout dev
    Branch dev set up to track remote branch dev from origin.
    Switched to a new branch 'dev'
    ### Now you can start do your own work in dev branch... ###
  • Test your codes as much as you can before commit.
  • Give enough information in commit message for tracking changes and updates, especially for code integration in a pull request.
  • Commit your changes early and commit often.
  • Before you push commits back in Github, please always do a git pull and a git status before git push.
  • You may encounter merge conflict after introducing a git pull and see similar message like the following:
    $ git pull
    Auto-merging <filename>
    CONFLICT (content): Merge conflict in <filename>
    Automatic merge failed; fix conflicts and then commit the result.

    Please fix all merge conflicts and then use git add and git commit to update with your fixes. You can use git status to check on which files merge conflicts happened.

  • Once you have no complanation from git pull then you are pretty safe to git push all of your commits.
  • If you need to create your own branch from dev, use the following commands for it:
    # Create your own new branch
    $ git checkout -b newbranchname oldbranchname
    # Push your new local branch to remote Git repository
    $ git push -u origin newbranchname
  • To rename your branch:
    # Rename your local branch
    $ git branch -m old_branch_name new_brach_name
    # Remove the branch name you want to change on GitHub
    $ git push origin :old_branch_name
    # Push the new local branch name to GitHub
    $ git push origin new_brach_name

Keeping Fork Codebase Updated with Upstream Repository

1. Joanna will be the one regularly rebase the dev branch with the latest updates from upstream repository.
2. Any developer in CoEPP group is expected to do git pull before git push for fetching updates from other developers in UVic and CoEPP.

Git Rebasing

  • We will use Git rebasing as a way to constantly integrate changes from dev branch in upstream cloud-scheduler repository into the one in CoEPP.
  • The dev branch in CoEPP would be eventually integrated into upstream repo by Git pull request.
  • Try to keep local dev branch up-to-date with the upstream repository at a fairly regular interval.
  • Do not rebase commits that you have pushed to a public repository for this reason.
  • Do not pull changes from fork repo before rebasing then git push them back to fork repo.
    • It would introduce the existing new commits in fork repo twice after git push. See an example.
    • When you rebase stuff, you’re abandoning existing commits and creating new ones that are similar but different (different SHA-1 hashes but introduce the same work and have the same commit message).
  • More information about git rebasing:


  • You only need to do this once right after clone.
  • Track changes/updates in remote upstream repository in hep-gc.
  • Add a remote called upstream pointing to cloud-scheduler repository in hep-gc:
    $ cd cloud-scheduler
    $ git remote add upstream git://


  • Make sure that you're on your dev branch:
    $ git checkout dev
  • Each time when you want to rebase the dev branch onto the upstream dev branch, especially before you start coding:
    $ git fetch upstream
    $ git rebase upstream/dev

    Don't apply rebasing if there is no update in upstream dev branch.

  • If you have made some changes in your local dev branch, you would see the following message when trying to rebase upstream/dev:
    $ git rebase upstream/dev
    Cannot rebase: You have unstaged changes.
    Please commit or stash them.

    Please commit your changes before integrating changes from upstream repository.

  • During rebase procedure, you might get merge conflicts since it failed to merge in the changes. In this case, the git rebase output would report the file name in where merge conflict happened.
  • Go through all the files and fix all merge conflict before continuing rebase procedure, then you can do:
    $ git rebase --continue
  • Once rebase is successfully run and finished, commit every single change again.
  • You are now able to git push your commits back to remote repo.

Daily Fast-forwarded Rebasing

  • Check branch:
    $ git branch
    * dev
  • Fetch new commits from upstream repo:
    $ git fetch upstream
    remote: Counting objects: 5, done.
    remote: Compressing objects: 100% (2/2), done.
    remote: Total 3 (delta 1), reused 3 (delta 1)
    Unpacking objects: 100% (3/3), done.
    From git://<username>/<reponame>
       3883a4b..3bb0e2f  dev        -> upstream/dev

    Stop at the step if there is no new commit.

  • Check local change:
    $ git status
    # On branch dev
    nothing to commit (working directory clean)

    If there is any local change, commit them or create a backup branch for keeping them for future merge after rebasing.

  • Check origin repo:
    $ git fetch origin
    $ git diff dev origin/dev

    If you need to undo git pull, see this example.

  • If there is no local change, no remote new commit in origin, then you are ready to go for a fast-forwarding rebasing.
  • Rebase local dev branch onto upstream one:
    $ git rebase upstream/dev
    First, rewinding head to replay your work on top of it...
    Fast-forwarded dev to upstream/dev.
  • Check local status after rebasing:
    $ git status
    # On branch dev
    # Your branch is ahead of 'origin/dev' by 2 commits.
    nothing to commit (working directory clean)
  • Push updates from upstream dev branch to origin one:
    $ git push
    To https://<username><username>/<reponame>.git
       01d5058..3bb0e2f  dev -> dev

Check & Test Your Changes

  • There are two testbeds with Torque or Condor batch system installed for testing your codes:
    • Torque+CS: contact Joanna for its access details.
    • Condor+CS: contact Joanna for its access details.
  • The forked cloud-scheduler in CoEPP will be cloned onto the testbeds for testing.
  • You need a git pull on /root/cloud-scheduler to update the local dev branch with latest changes.
  • To reinstall CS on the testbeds, please see:
  • Remember to backup the original working CS's config files before re-install CS on the testbeds.
  • See Condor testing for more information about testing.

Merge Our Work Back to Upstream Repository

  • Once we are happy with all new changes/features and test outcome, then we can ask for a pull request to push changes back to upstream repository.
  • It should be much more straightfoward and much less painfull than merging a pull request if we've done rebase properly.
  • More information about Github pull request please see:
cloud/cs_github_workflow.1375231340.txt.gz · Last modified: 2013/07/31 10:42 by joannah
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki