Difference between revisions of "Github"

From WeBWorK_wiki
Jump to navigation Jump to search
Line 34: Line 34:
   
 
* clone the remote repo
 
* clone the remote repo
 
 
*git checkout -b my_new_feature
 
*git checkout -b my_new_feature
 
 
*..work and commit some stuff
 
*..work and commit some stuff
 
  +
*git pull origin master (pull changes from the upstream github repository into your master copy)
*git rebase master
 
  +
*git rebase master (apply updates to your my_new_feature branch so that it looks like it branched from the updated master copy)
 
 
*..work and commit some stuff
 
*..work and commit some stuff
 
  +
*git pull origin master
 
*git rebase master
 
*git rebase master
 
 
*..finish the feature
 
*..finish the feature
 
 
*git checkout master
 
*git checkout master
 
 
*git merge my_new_feature
 
*git merge my_new_feature
  +
*git push origin master (publish your current changes to your github account)
  +
* Issue pull request to openwebwork
   
 
Individual developers for webwork also have their own sites (analogous to the branches in SVN, but more easily accessible)
 
Individual developers for webwork also have their own sites (analogous to the branches in SVN, but more easily accessible)

Revision as of 12:49, 6 March 2012

Warning : This page is still under construction use with caution


GitHub

Overview

Git is the name of a distributed version control system. It plays the role of the CVS or SVN control systems that WeBWorK has used in the past but the details of how it works are somewhat different. For obtaining up-to-date copies of software there is not much difference between git and previous VCS. Developers however should read closely since git has a different conceptualization of how version control should be handled. The difference allows considerably more flexibility for collaborative development. Consolidation no longer depends on a single site or single administrator. Updates are also more modular and therefore easier to check and repair or remove if they cause trouble.


Git has many capabilities and can be used in many different ways. This page outlines a subset of git commands and workflows that seems to work well for WeBWorK.


Github.com is a site which facilitates the collaborative development of open source projects. These sites are open (read-only) to the world. WeBWorK has a master site at https://www.github.com/openwebwork where accepted modifications are being consolidated. The following repositories are available at that site.

  • webwork2 -- the course management face of WeBWorK
  • pg -- the macros that help render the PG questions
  • NationalProblemLibrary -- collection of questions (not yet implemented -- for now Jason Grout's repository at:
  • wwmoodle -- plugins that connect moodle and webwork
  • ww_question_server -- another plugin project connecting moodle question types to the WeBWorK webservice
  • admintools -- a collection of command line scripts used by larger sites serving WeBWorK

Contributing to WeBWorK

Workflow

On your local git repository the following workflow seems to minimize clashes with work being done elsewhere.

  • clone the remote repo
  • git checkout -b my_new_feature
  • ..work and commit some stuff
  • git pull origin master (pull changes from the upstream github repository into your master copy)
  • git rebase master (apply updates to your my_new_feature branch so that it looks like it branched from the updated master copy)
  • ..work and commit some stuff
  • git pull origin master
  • git rebase master
  • ..finish the feature
  • git checkout master
  • git merge my_new_feature
  • git push origin master (publish your current changes to your github account)
  • Issue pull request to openwebwork

Individual developers for webwork also have their own sites (analogous to the branches in SVN, but more easily accessible)

References for GitHub and Git

(unreviewed at the moment -- YMVV)


Version_Control