History

OMF Main Page ยป

Repository

1. Read-only access for users

To obtain the OMF source code, you may access our public (read-only) git repository. To check out the latest development code (master):

git clone git://git.mytestbed.net/omf.git

For release 5.3:

git clone git://git.mytestbed.net/omf.git -b release-5.3

For release 5.2:

git clone git://git.mytestbed.net/omf.git -b release-5.2

You can browse the repository contents under the "Repository" tab above. Feel free to submit patches via our mailing lists. Contact us if you require "push" permissions.

2. Read/Write access for developers

If you are a developer and have submitted your SSH public key to us, you can check out using

git clone :omf.git

Note: if you are using multiple SSH keys, you may have to set your SSH config file to use the proper key for 'mytestbed.net' (e.g. by setting the IdentityFile option in your SSH config)

3. Git best practices

https://wiki.duraspace.org/display/FCREPO/Git+Guidelines+and+Best+Practices

4. Developer rules for using git

  • Release development and bug fixes happen on the release branch. Release branches always branch off the master and regularly merge back to the master.
  • At the end of a working day, all changes to the release branch are committed, pushed and then merged to the master immediately (e.g. "git checkout master; git pull; git merge release-x.x; git push"). Git will fast-forward the master, so no cherry-picking is necessary.
  • Master-only commits should be limited to the phase between releases (stable release is finished, next release is about to be branched off)
  • Any features that should not go into an immediate release are implemented on feature branches. The same applies to anything that "breaks" stuff or causes an incompatibility with the current release. Feature branches are merged to the master only when they are ready for release (i.e. don't break things). This is done only "in between releases" - just before a new release branch is created off the master.
  • Feature branches may be deleted after they are complete and have been merged to master
  • Features that break compatibility with released versions of OMF require a new release with increased version number. It would be wise to keep those features in their feature branches until we are preparing the next major release.
  • Consider using 'rebase' to keep tracking changes from remote master branch. However DON'T rebase after the branch has been made public. i.e. pushed to remote repo.
    Refer this for more details http://progit.org/book/ch3-6.html