Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Git Migration Workflows: Difference between revisions

From MoodleDocs
mNo edit summary
m (Undoing all my recent work - it is at a separate page)
Line 1: Line 1:
= Workflows for Migrating to Git =
Quite a number of developers are now familiar with git and are enthusiastic about the power and flexibility it brings to the development process. It is not clear how workflows in the current development process will transfer if a switch to git is made.  
Quite a number of developers are now familiar with git and are enthusiastic about the power and flexibility it brings to the development process. It is not clear how workflows in the current development process will transfer if a switch to git is made.  


Line 5: Line 7:
Please edit this page to add your suggested workflows or questions for a workflow to do something.
Please edit this page to add your suggested workflows or questions for a workflow to do something.


= Preparing the environment =
== General Model for Commiting to HEAD ==
 
[[Image:moodle-git-cvs-servers.png|frame]]
 
In the examples at this page, you are expected to use the following environment. Check the diagram. At the moment, there are two source code repositories you can use: the main Moodle CVS server cvs.moodle.org and its git mirror at git.moodle.org. While the CVS contains both Moodle core code and the contributed code, the git mirrors the core code only yet (this may be changed in the near future). We also expect you have some server (called nostromo at the diagram) that you and your team members use and that you do the actual developing at the localhost machines.
 
* <code>git clone</code> can be used to create a mirror of the git.moodle.org repository at your server nostromo
* <code>git pull</code> can be used regularly to fetch and merge the upstream changes
* <code>git cvsimport</code> can be used to create your own git mirror of a contributed code (we do not do this yet for you)
* <code>git push</code> can be used to backup your own work and to share it with your friend before you send it upstream (and you will, right? ;-)
* <code>git cvsexportcommit</code> can be used to send your commits for the upstream
 
= General Model for Commiting to HEAD =


'''Summary''': How do developers 'commit' to the canonical repository?
'''Summary''': How do developers 'commit' to the canonical repository?
Line 25: Line 15:
* Others/hybrid approaches?
* Others/hybrid approaches?


= Commiting to STABLE branches =
== Commiting to STABLE branches ==
'''Summary''': How do developers commit to the stable branches? How do we ensure changes have been merged into head?
'''Summary''': How do developers commit to the stable branches? How do we ensure changes have been merged into head?
= Customizing a CONTRIB plugin =
'''Summary''': This suggested workflow can be used by developers who are working on a customization or a fix of a contributed Moodle plugin. You want to keep the track of your local changes and eventually send some of you changes back to the upstream.
== Prepare a git mirror of the CONTRIB module ==


[[Category:Git]]
[[Category:Git]]
[[Category:Developer tools|Git]]
[[Category:Developer tools|Git]]

Revision as of 11:44, 26 October 2009

Workflows for Migrating to Git

Quite a number of developers are now familiar with git and are enthusiastic about the power and flexibility it brings to the development process. It is not clear how workflows in the current development process will transfer if a switch to git is made.

Git doesn't place constraints to one model of development which is both a feature and a hindrance for people understanding how the development process takes place. A number of workflows need to be developed in order that developers can understand how git would fit into moodle development.

Please edit this page to add your suggested workflows or questions for a workflow to do something.

General Model for Commiting to HEAD

Summary: How do developers 'commit' to the canonical repository?

  • Developers 'push' to a central repository as happens with CVS now. Commit access is granted via ssh. (But external contributors can publish their git repository branches to developers with commit access for inclusion to the mainline)
  • Developers push to their personal repository and an integrator/gatekeeper approves and merges changes (e.g. linus kernel branch)
  • Others/hybrid approaches?

Commiting to STABLE branches

Summary: How do developers commit to the stable branches? How do we ensure changes have been merged into head?

Retrieved from "https://docs.moodle.org/dev/index.php?title=Git_Migration_Workflows&oldid=13678"
Powered by MediaWiki