Skip to content

Developing against WMCore

Jump to bottom
Eric Vaandering edited this page Sep 16, 2015 · 20 revisions

Setting up your git repositories

We use a workflow very similar to the one explained here: https://github.com/sevntu-checkstyle/sevntu.checkstyle/wiki/Development-workflow-with-Git:-Fork,-Branching,-Commits,-and-Pull-Request

  1. Create a GitHub account and ask to be made a part of the DMWM Contributors team
  2. Fork the WMCore repository (visit https://github.com/dmwm/WMCore and click fork on the upper right side)
  3. Clone the WMCore repository: git clone https://github.com/USERNAME/WMCore.git (You can find the URL in the text box on your page.
  4. Configure the DMWM version of the code as your first remote:
  • cd WMCore
  • git remote add upstream https://github.com/dmwm/WMCore.git (you don't need to call it upstream, but this is convention) (you can also add any user there if you want to follow what others are doing)

Starting a new development

It's always best to start development against the latest master tag if you can. Follow these steps

  1. Update your local and personal GitHub code to the latest master. You can do this any time, not just when you start development
  • git checkout master
  • git fetch upstream - this gets all the references from the DMWM branch but doesn't change anything about what you have locally
  • git merge upstream/master - this merges the changes in DMWM into your local repository
  • git push origin master - this completes the triangle so that DMWM, your GitHub, and your local all have the same master
  1. Begin a new development branch

  • git checkout master - you probably are already here, but in case not...

  • git checkout -b my_feature - this creates a new branch where you will fix something

  • Hack away to your heart's content

  • git add for each file you change

  • git commit -m "This patch fixes all the bugs and is awesome"

  • git push origin my_feature

  • Go immediately to https://github.com/dmwm/WMCore and you should see a button to make a new pull request (PR). Click it and tell us why we should include this code.

  • Some will say each PR should be one commit. I don't agree with this. Each commit should be self contained, but a PR should sometimes have more than one. For instance, if you are making logical changes and then cleaning up code, make them separate. Then we can understand the logical changes you are making and the quickly verify "Yup, all they did in the 2nd commit was change a bunch of spaces"

  • Jenkins will check your code and the unit tests. If nothing needs to be changed, go back and start your next development. Otherwise, continue development on your branch with:

    -git checkout my_feature

    • Hack away to your heart's content
    • git add for each file you change
    • git commit -m "This patch REALLY fixes all the bugs and is awesome"
    • git push origin my_feature
    • No need to make another PR, GitHub already knows you updated your branch. Jenkins will run again.
Clone this wiki locally