Skip to content

Home

Jump to bottom
Graham Lopez edited this page Dec 14, 2016 · 27 revisions

conventions

  • To describe the location of branches, we use the abbreviation machine:gituser:repo:branchname. Obviously, this is not git command syntax. Here are some examples:
    • local:alice:qmcpack:newfeature (alice's "newfeature" branch in a "qmcpack" respository that is local to the repo cloned on her laptop/desktop, titan account home area, etc.)
    • github:bob:qmcpack:issue27 (the bob user's "issue27" branch that resides in his "qmcpack" repo on github)
    • github:qmcpack:qmcpack:* (all branches in the "qmcpack" organization's "qmcpack" 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"

Daily development workflow examples

Develop a new feature and integrate it back into the main public repository

  1. Fork A Repo

    This page describes how to

    1. create (fork) github:alice:qmcpack:* from the existing github:qmcpack:qmcpack:* by clicking the "Fork" button in the top right corner on Github.
    2. create (clone) local:alice:qmcpack:* from the github:qmcpack:qmcpack:* repo just created in "1.i."
    3. configure "upstream" to point to the original github:qmcpack:qmcpack:*. This is needed for keeping the forked repo up-to-date with the original.

  2. Create a topic branch for the new feature

  3. Develop new feature, adding commits

  4. Bring in new development from upstream (cf. Syncing a fork)

    1. bring changes from github:qmcpack:qmcpack:develop into local:alice:qmcpack:develop

       $ git fetch upstream  (this will fetch changes from all branches  `github:qmcpack:qmcpack:*` but not merge them)
 $ git checkout develop
 $ git merge upstream/develop

      Note that the Syncing a fork Github documentation describes the process for updating master. The $ git fetch upstream will get updates for all branches, so that this only needs to be done once to update multiple local branches from upstream (using $ git checkout ... $ git merge).

    2. now bring new development into your working feature branch:

       $ git checkout feature_branch
 $ git merge develop

    Now local:alice:qmcpack:develop is synced with github:qmcpack:qmcpack:develop(4.i), and possibly those changes have also been brought into local:alice:qmcpack:feature_branch (4.ii). A $ git push after 4.ii will update github:alice:qmcpack:feature_branch since that is the current branch. github:alice:qmcpack:develop will need to be pushed to separately to get it in sync as well.

    (Advanced: github:alice:qmcpack:develop doesn't really need to stay in sync, and in fact local:alice:qmcpack:develop could be set to track github:qmcpack:qmcpack:develop instead)

  5. About pull requests.

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

Clone this wiki locally