Home

conventions

• To describe the location of branches, we use the abbreviation machine:gituser:branchname. Obviously, this is not git command syntax. Here are some examples:
  • local:alice:newfeature (alice's "newfeature" branch that is local to the repo cloned on her laptop/desktop, titan account home area, etc.)
  • github:bob:issue27 (the bob user's "issue27" branch that resides on github)
  • github:qmcpack:* (all branches in the 'qmcpack' organization's repository on github)
• Commands typed at the linux comman prompt will be in fixed-width font and start with '$'. Command representation follows the conventions of the git man pages: Optional arguments are enclosed in square brackets. User-supplied information is enclosed in angle brackets. An example ("branch" is a user-supplied branch name argument that is optional):
  • $ git checkout [<branch>]
• PR, PRs = "pull request," "pull requests"
• Under the fork and pull request model that QMCPACK uses, origin will refer to the user's own forked repository hosted on Github (e.g. github:alice:*), and upstream will refer to the public QMCPACK repository (i.e. github:qmcpack:*).

Daily development workflow examples

Setup

Fork a repository on Github for development and integration back to main codebase

TODO

Clone a repository from Github to a local development machine.

This downloads the repository somewhere that actual changes can take place. If changes will be made and submitted back to the main code base, this should always be done from a user's forked repository and never from the QMCPACK public repository because PRs should be submitted from the developer's own user account.

$ git clone https://[<github id>]@github.com/qmcpack/qmcpack.git

Setting up and verifying the origin and upstream repositories.

TODO

Create a private copy of the QMCPACK repository on Github.

TODO: explanation of when/why to use this

1. Under the QMCPACK/ namespace on Github, click the new repository button.

2. Pick a name (e.g. "newrepo"), and mark it as Public (this will change in step 6 below). Do not initialize with any README, .gitignore, license, or other files.

3. On your local machine, clone the repository old repo (e.g. "oldrepo") to be forked and cd into its top directory.

    $ git clone https://github.com/qmcpack/oldrepo.git
    $ cd oldrepo
   

4. "Mirror push" the old repo to the new repo that will become private

    $ git push --mirror https://[githubid]@github.com/qmcpack/newrepo.git
   

5. Now you can delete the clone of the old repo on the local machine

    $ cd ..
    $ rm -rf oldrepo
   

6. On the github website, go into the newrepo settings, and make it private

7. Clone a working copy of the now private newrepo

    $ git clone https://[githubid]@github.com/qmcpack/newrepo.git
   

Some common combined tasks

User 'bob' wants to develop a new feature and integrate it into the main code base.

1. First, bob makes sure that his local repo's develop branch is up-to-date: (see https://help.github.com/articles/syncing-a-fork/)

    $ git checkout develop
    $ git pull upstream/develop
   

2. Next, bob creates a new branch from local:bob:develop for his new feature development.

    $ git branch <newfeature>
   

3. Bob makes his branch available on Github for collaborating on the feature, and also for submitting the pull request

    $ git push origin <newfeature>
   

4. (Optional) Bob invites other developers to collaborate on this feature with him. Alice can start collaborating with Bob by pulling his new branch:

    $ FIXME
   

5. Development ensues (edit files, commit changes, repeat until finished)

6. Once bob wants to submit the code back to the main project, he opens a pull request:

Using the 'git flow' git extensions

TODO: see https://github.com/nvie/gitflow

Helpful configuration for developers

• .gitconfig settings
  • name and email address for commits
  • helpful aliases
• skip typing github username
• skip typing github password

Developers handling pull request code reviews

Maintainers handling pull request submissions and merging

outline

• PR comes in for 'develop'
• CI and github checks
  • if CI fails or not a clean merge, maintainer asks submitter to fix
• maintainer does sanity checks
  • patch is logically sized (one main 'topic' for the patch, hopefully < 1k lines)
  • code formatting
  • well commented/documented
• Submitter addresses comments from maintainer(s)
• If required, maintainer tags project developer(s) to review and comment
• Submitter addresses comments from developer(s)
• Once developers and maintainers give '+1', thumbsup, okay, whatever, maintainer merges PR into 'develop'

Transition todo

• Documentation — github wiki and/or qmcpack manual
  • general developer workflows (graham)
  • pull request handling for maintainers (graham)
  • code review checklist (graham)
  • release process
  • old wiki move - what to include?
  • issue processes - how to assign and close? e.g. issue fixer should not close, to force a doublecheck
• CI
  • infrastructure availability status (graham)
  • how to automate code formatting check/enforcing (graham)
    • based on style at https://sites.google.com/a/cmscc.org/qmcpack/developers-forum/coding-guides
    • checkout:
      • http://stackoverflow.com/questions/22866609/can-clang-format-tell-me-if-formatting-changes-are-necessary
      • http://www.labri.fr/perso/fleury/posts/programming/using-clang-tidy-and-clang-format.html
      • https://llvm.org/svn/llvm-project/cfe/trunk/tools/clang-format/git-clang-format
  • update scripts for new CI infrastructure
  • remove svn specifics from testing infrastructure and code
  • partition tests into PR, nightly, weekly
  • how to deal with nightly/weakly failures/regressions? - maintainer triages and assigns to right person?
• SVN to git repo conversion
  • authors file / translation svn to github emails - "best effort" (mark)
  • archive old issues (mark)
  • move open issues (mark)
    • how to deal with comment chains? cut/paste into main body of corresponding issue on github. use github API?